The Gap Between Alerts and Campaigns

Tuesday morning, three alerts in the queue

It's 09:30 and your SOC queue has three open alerts from the last twelve hours. Different systems, different severities, different rule categories. You triage them in order.

The first alert fired at 09:14. A Sigma rule for suspicious PowerShell execution triggered on DESKTOP-NGE042, Tom Ashworth's workstation. The command line shows Invoke-WebRequest downloading a file from a cloud storage URL. You check the URL against threat intel feeds. Clean. Tom's role is IT administrator. You check whether he's run similar commands before. He has, twice this month, both for legitimate admin scripts. You close the alert as a false positive with a note: "Admin script download, matches prior pattern."

The second alert fired at 11:47. An unusual sign-in location for t.ashworth@northgateeng.com. The authentication came from an IP address in the same country but not from the office or Tom's home network. Successful authentication, MFA satisfied, no risk flags from Entra ID Protection. You check whether Tom is traveling. His calendar shows he's in the office. The IP could be a mobile hotspot or a VPN provider. Low severity. You close it as likely benign: "Possible VPN or mobile network. No suspicious post-sign-in activity."

The third alert fired at 14:22. A new scheduled task created on SRV-NGE-APP01, one of Northgate Engineering's application servers. The task name is WindowsUpdateCleanup and it runs a PowerShell script from C:\ProgramData\. You check the server's patch schedule. Patching ran over the weekend. Two similar tasks exist from previous cycles. Low severity. You close it as operational: "Post-patching cleanup task. Consistent with maintenance schedule."

Three alerts. Three reasonable dispositions. Every one of them defensible in a peer review.

What actually happened

The same three events, read as a campaign instead of as isolated alerts.

The PowerShell alert on Tom's workstation wasn't an admin script. It was the execution stage of a targeted spearphishing attack. The Invoke-WebRequest command downloaded an in-memory loader that harvested Tom's credentials from the LSASS process and exfiltrated them to attacker infrastructure. The URL was clean on threat intel because the attacker used the same legitimate cloud storage service Tom uses for admin work, which is why the command matched his prior pattern.

The unusual sign-in at 11:47 wasn't Tom. It was the attacker replaying Tom's stolen access token from their own infrastructure. The sign-in appeared to satisfy MFA because the token was captured post-authentication. The attacker intercepted the session after Tom completed his MFA challenge, so the token carried the MFA claim. The source IP was an anonymizing proxy in the same country, deliberately chosen to avoid the "impossible travel" analytics rule.

The scheduled task on the application server wasn't from patching. It was the attacker's persistence mechanism, installed using Tom's domain admin credentials harvested three hours earlier. The task name WindowsUpdateCleanup was selected to mimic legitimate Windows maintenance. The PowerShell script in C:\ProgramData\ was a reverse shell beaconing to attacker C2 infrastructure every four hours.

One campaign. Three phases: credential harvest at 09:14, access replay at 11:47, persistence installation at 14:22. Each phase produced an alert. Each alert was triaged correctly in isolation. The campaign was never identified.

09:14  [Endpoint]  DESKTOP-NGE042   PowerShell Invoke-WebRequest to cloud storage
                                     In-memory loader executes, LSASS credential harvest
                                     Triage: closed as FP, "admin script, matches prior pattern"
11:47  [Identity]  t.ashworth       Sign-in from unfamiliar IP, MFA claim present
                                     Attacker replaying stolen session token via AiTM proxy
                                     Triage: closed as benign, "possible VPN, no post-sign-in activity"
14:22  [Server]    SRV-NGE-APP01    Scheduled task WindowsUpdateCleanup created
                                     C2 reverse shell in C:\ProgramData\, 4-hour beacon interval
                                     Triage: closed as operational, "consistent with patch cycle"
14:22+ [Persist]   SRV-NGE-APP01    Attacker has stable persistence on application server
                                     Dwell time: 14 days before discovery

Why the triage was correct and the outcome was wrong

Every disposition was defensible. The PowerShell execution matched Tom's prior pattern. The sign-in was from the same country. The scheduled task looked like a patching artifact. No individual alert was severe enough to trigger escalation. The triage framework worked exactly as designed for isolated events.

It failed because the framework never asks: "Are these events related?"

Relating them requires a specific kind of knowledge. You need to know that an attacker who harvests credentials will replay them within hours, not days. You need to recognize that token replay from a different IP is the expected follow-on to credential theft, not a coincidence. You need to understand that persistence installation on a high-value server within the same operational window as credential theft and token replay is the completion of an access chain, not a maintenance task.

That knowledge doesn't come from better detection rules. Your rules fired correctly, and all three alerts generated. It comes from understanding how offensive operations work: why attackers chain these specific activities in this specific sequence, on this specific timeline.

The numbers behind the gap

Mandiant's M-Trends 2026 report, based on over 500,000 hours of incident response investigations, measured the global median dwell time at 14 days in 2025, up from 11 days the previous year. Espionage operations and DPRK-linked IT worker schemes pushed certain categories to 122 days median dwell, roughly four months of undetected access. The dwell time is climbing in specific categories because attackers are deliberately optimizing for persistence rather than speed, and the detection stacks built to catch fast-moving ransomware operations are structurally blind to slow, patient adversaries.

The same report documents a collapse in handoff timing. The median time between initial access and handoff to a secondary threat group fell to 22 seconds in 2025, down from over 8 hours in 2022. Initial access brokers are automating the transition. The moment they confirm a foothold, the payload or credentials transfer to the operator within seconds. Defenders who built response workflows around multi-day investigation windows are now operating on a timeline the attacker has already compressed past their response capacity.

Exploits led initial infection vectors at 32%. Voice phishing climbed to 11%, making it the second most common entry point, displacing email phishing. The shift matters operationally. Interactive social engineering requires a live human operator and resists the automated technical controls organizations built to filter email campaigns. An attacker who calls the help desk and convinces them to reset MFA produces the same credential access as a successful phishing email, but the event appears in the telephony and ticketing system rather than the email security logs. Different telemetry source, same campaign outcome, different detection requirement.

The MITRE ATT&CK Evaluations Enterprise 2025 identified three core detection challenges: visibility gaps where telemetry is missing entirely, logic gaps where products ingest the data but cannot interpret its meaning, and correlation gaps where tools detect individual steps but fail to connect them into an attack narrative. The third category is the campaign-correlation gap. Multiple leading XDR platforms scored 100% technique-level detection in the evaluation and still handed the correlated incident to a human analyst who had to reconstruct the campaign narrative manually.

The technology detects techniques. The analyst needs the operational knowledge to connect them.

The retrospective correlation method

You can apply this to your closed-alert queue today. No new tools, no new detections. A different question applied to data you already have.

Step 1: Shared attributes. Given a set of alerts from the same day, list what they share: same user identity, same credential, same time window, same target environment, logical sequence from one to the next. In the NE example, the shared attributes are the user identity (t.ashworth), escalating privilege across systems (workstation to cloud identity to server), and a five-hour operational window. Identity is the strongest linking attribute. A user who appears in three alerts across three systems within hours is either having an unusual day or being operated against.

Step 2: Hypothesized chain. For each alert, ask: "If this were a campaign phase, what would have preceded it and what would follow it?" The PowerShell execution as credential theft means the next step would be credential replay from a different source. The unusual sign-in as credential replay means the next step would be lateral movement or persistence. The scheduled task as persistence means the preceding step would be privileged access to the server. This step requires offensive operational knowledge, which is what this course teaches. Without it, the analyst has no framework for generating the hypothesis.

Step 3: Sequence validation. Check whether the hypothesized chain matches the observed alert sequence and timing. Credential theft at 09:14, credential replay at 11:47 (2.5 hours later, within expected operational tempo for a hands-on-keyboard attacker), persistence at 14:22 (2.5 hours after replay, consistent with an operator establishing stable access before moving to the next objective). The sequence matches. The timing matches. The logical progression matches.

If the timing is wrong, with persistence appearing before credential theft or a gap of weeks between phases that typically happen within hours, the correlation may be coincidental. Not every set of alerts sharing a user identity represents a campaign. Some users genuinely trigger multiple unrelated rules through their normal work. The method gives you a structured way to distinguish campaigns from coincidence, and the reasoning survives peer review because each step is documented.

The analyst decision above is what the triage outcome should have looked like. The individual alert dispositions weren't wrong. The investigation stopped too early. Applying the retrospective correlation method after the first close would have surfaced the connection within minutes.

Why this course exists

The campaign-correlation gap is not a technology problem. Your SIEM correlates events. Sentinel builds multi-stage analytics rules. XDR platforms score 100% on technique detection in controlled evaluations. The technology to detect campaigns exists in every modern security stack.

The gap is knowledge. To build campaign-level detections, you need to know what campaigns look like. To triage alerts as campaign components, you need to understand the operational logic that connects individual techniques into coordinated operations. To anticipate the attacker's next step during an investigation, you need to understand how offensive operations are planned and executed.

Detection Engineering teaches you to detect individual techniques. Purple Teaming teaches you to validate those detections by firing the techniques and confirming the alerts appear. This course teaches the operational logic that connects techniques into campaigns — so you can build the correlation rules, ask the correlation questions during triage, and predict the attacker's next move from partial evidence.