Twelve tickets, one story
When an attacker gets onto a machine, they rarely do one thing. They look around, find out who they are and what the machine can reach, and then start gathering what they came for. Each of those steps can trip a different detection rule, so one intrusion can arrive as a dozen separate alerts. Read one at a time, each may look minor. Read together, they are an attack.
That is the everyday problem campaign joining solves. Alert queues are organised by alert, because that is how detection rules produce them. Attacks are organised by intent, because that is how attackers work. Somebody has to bridge the two, and in most teams that somebody is a tired analyst who happens to remember seeing the same host name an hour earlier.
This post follows a real example from our own lab, not from a customer. Twelve alerts from five rules fired on a single Linux machine. armor360 joined them into one campaign, ran from discovery to collection, and showed it to a person as one picture rather than twelve tickets.
What ran in our lab
Our test lab has a handful of Linux machines watched by Elastic Security. We use MITRE Caldera, an open adversary-simulation tool, to behave like an attacker on them. On a machine called linux04, a Caldera agent ran a series of commands that a real intruder might run after getting in.
One of the first alerts was “Burst of reconnaissance commands”. armor360 investigated it the way an analyst would. It asked 13 questions, read 4 data sources and kept 22 records as evidence. Among them, it found a process called “caldera-agent” calling out over HTTP every five minutes, and regular python3 runs under a back-office user that matched the reconnaissance. Its verdict was Real attack, at 90% confidence, in 5 minutes 35 seconds.
That investigation answered the question “is this alert real?”. The campaign answers a bigger one: “what is this attacker doing on our machine, and how far have they got?”.
A lab is a good place to test this because we know the truth. We know which commands Caldera ran and when, so we can check whether the alerts were joined correctly and whether anything unrelated was pulled in. In production that certainty is rare, which is why we test here first.
The point of this post is not the numbers. It is how a set of scattered alerts becomes one account of what an attacker did, and why that account is so much easier for a person to act on.
How alerts become one campaign
Joining alerts is the work an experienced analyst does in their head when they notice that the same machine keeps coming up. The clues are the ones you would expect: the same machine, the same accounts, processes started by the same parent, and activity close together in time. When the clues line up, the alerts are treated as one attack rather than a coincidence.
Each alert is then placed on the attacker’s path using MITRE ATT&CK tactics, the public framework that names the stages of an intrusion. On linux04, the twelve alerts ran from discovery, where an attacker learns about the system and its users, to collection, where they gather data of interest. Seeing that the activity had reached collection matters: it says the attacker had moved past looking around and had started gathering what they came for.
The joining does not depend on any one rule being perfect. Five different rules fired, written for different behaviours. None of them was written to describe “an attack on linux04”, yet together they did.
Joining also has to avoid the opposite mistake: pulling unrelated alerts into the same story because they share a busy machine. A server that runs many jobs will raise alerts for many reasons. That is why the clues are weighed together rather than one at a time, and why a person can still look at each alert in the campaign and see why it is there.
Time matters as well. Activity on the same machine spread over weeks may be two separate events. Activity within the same few hours, by the same account, through the same chain of processes, almost never is. In our lab the twelve alerts sat close together on one machine, tied to the agent’s regular beacon.
What the one picture shows
The campaign page puts the whole attack on one screen. A person reading it does not have to open twelve alerts and assemble the story; it is already assembled, with each alert still there to open if they want the detail.
In our lab the picture told a clear story. The agent arrived, called home on a regular schedule, looked around the machine and its users, and moved on to gathering data. A person could see in one read that this was not an administrator having a busy afternoon. The regular five-minute beacon, the back-office account running python3 and the progression across ATT&CK stages together make a pattern that no single alert shows.
- The stages in order, from the first to the latest, mapped to ATT&CK tactics.
- The machines and accounts the activity touched.
- How long the activity has been running.
- Which business processes it puts at risk, from the context given at set-up.
- One coordinated plan, where each step waits for a person’s approval.
Why one picture beats twelve tickets
Twelve tickets invite twelve separate decisions, possibly by different people on different shifts. One of them might close a low-severity discovery alert as routine admin work while another is still looking at the collection alert. Nobody is wrong on their own ticket, and the attack is missed between them.
The severity of an attack is also more than the sum of its alerts. A single command that lists users is ordinary. The same command, followed by a scheduled beacon and then data gathering on the same machine, is not. Only the joined view shows that progression.
Finally, the response has to be coordinated. If one person resets an account while the attacker’s agent is still running on the machine, the attacker may simply carry on, or notice and change approach. One plan for the whole campaign, approved step by step, avoids people working against each other.
It also changes the conversation with the rest of the business. “We had twelve alerts on linux04” means little to anyone outside security. “An attacker reached a machine that serves the back office, looked around and had started gathering data; here is the plan, step by step, for your approval” is a sentence a manager can act on.
Where armor360 fits
This was a controlled simulation in our lab with a known attacker, so it shows how campaign joining works rather than how it performs everywhere. Real environments are noisier, which is why a person reviews every campaign and verdict.
armor360 joins alerts that belong to the same attack into one campaign and recommends a plan. It takes no response actions; people approve each step and carry it out.
