Attack chains and multi-event correlation
On this page
Single-event detection misses sophisticated intrusions. Attack-chain correlation links discrete events into sequences that reveal adversary intent across hours or days.
How far to go in Alert
In Alert, chain thinking is a question with a stopping point: one pivot on the account’s last 7 days of alerts and changes. If that pivot links the alert to other steps, the chain becomes a lead in the Alert handoff, because Uncover owns chain reconstruction. The fast-path depth ladder sets how much a given alert needs, and the Alert transition lists what to hand off.
The strategy: think in sequences, not moments
Most attacks are not a single dramatic action. They are a sequence of small actions that together describe a progression: reconnaissance, then initial access Initial Access The ATT&CK tactic covering how attackers first gain a foothold inside the environment: phishing, exploited edge devices and public-facing applications, valid or stolen credentials, and exposed remote services. Reconnaissance and Resource Development come before it. , then privilege escalation Privilege Escalation The ATT&CK tactic for gaining higher permissions: on the endpoint, standard user to admin to SYSTEM; in the directory or cloud, a regular account to domain admin or a privileged cloud role. , then lateral movement Lateral Movement Moving from the initial foothold to other hosts, identities or tenants to find sensitive data or reach higher-value targets (ATT&CK tactic TA0008). It usually rides legitimate remote-access protocols (RDP, SMB, WinRM, SSH) with stolen credentials, or replays a stolen session into a cloud or SaaS tenant, so the signal is an account authenticating where it does not normally go. Each hop widens the blast radius, and confirmed lateral movement is an escalation criterion. , then exfiltration Exfiltration The unauthorized transfer of data out of the environment (ATT&CK TA0010): over the C2 channel, to cloud storage or a file-sharing service, by email, or through DNS. Triage signals are volume and destination: outbound bytes far above the host's baseline, a first-seen upload destination, and staging (archives appearing in temporary folders) shortly before the transfer. Confirmed exfiltration is an escalation criterion, and when the data is regulated it can start notification clocks. . Real chains skip and repeat steps: a stolen SaaS session can go straight from initial access to collection, with no escalation or lateral movement to find. Multi-event correlation Event Correlation Linking events from different sources through shared entities and time to see one chain of activity: a phishing click, a sign-in from a new ASN, a new mailbox rule. It depends on normalized fields and synchronized clocks. In ASSURED, Uncover correlates evidence into one timeline per case. See Correlation and the timeline. is the validation strategy designed to catch that shape, not just the single suspicious moment in the middle.
As a validation strategy, chain thinking is a question the analyst asks of every alert: is this event one step in a sequence? Answering it means pivoting outward from the alert (same host, same account, adjacent time windows, related techniques) far enough to know whether a sequence exists; assembling the full timeline is Uncover’s work. When a platform has already assembled the sequence, the result arrives as a behavioral alert and the analyst’s job is to confirm the narrative. This page is about the same thinking applied by the analyst directly, especially for the chains no engine has a pattern or a window for.
The four pivot axes
Whether an engine assembles the chain or the analyst does, it links events along four pivot axes: time, assets, technique, and targeting. During validation, pivot along each. A useful chain typically involves at least two of them.
Time
Events grouped within a window. The window can be minutes for fast attacks like ransomware staging, or hours to days for low-and-slow intrusions. Search in both directions: the alert in front of you may be the first, middle, or last visible step.
Assets
Events that touch the same host, account, segment, or service. Pivot on the entities the events share, so a lateral movement chain shows the host and account hops in order.
Technique
Events whose ATT&CK mappings form a plausible progression across tactics (for example Discovery, then Persistence, then Collection, then Exfiltration), or the same technique repeating across several hosts or accounts. A progression shows intent and where the chain may have gaps to search; repetition shows spread. Overlap with a known campaign’s techniques is a lead, not attribution.
Targeting
Events that focus on a department, a data type, or a class of user. Helps the analyst recognize when a chain is an opportunistic intrusion versus a targeted one.
Representative platforms: Microsoft Sentinel Microsoft Sentinel Microsoft's cloud SIEM/SOAR (formerly Azure Sentinel), built on Log Analytics and queried with KQL; playbooks run on Azure Logic Apps. Built-in UEBA and an optional lower-cost data lake tier. Now runs in the unified Microsoft Defender portal; Azure portal support ends 31 March 2027. analytics rules (in the Defender portal, where the Defender XDR correlation engine groups alerts into incidents), Google Security Operations Google Security Operations (formerly Chronicle) Cloud-native security analytics platform from Google Cloud; high-speed search and threat detection at petabyte scale. Chronicle was folded into the Google Security Operations (Google SecOps) brand in 2024. (formerly Chronicle), Splunk Enterprise Security Splunk Enterprise Security SIEM application on the Splunk platform: correlation searches, risk-based alerting, and prebuilt content for SOC workflows. , the Exabeam Exabeam SIEM and user and entity behavior analytics (UEBA) vendor: risk-scored user and entity timelines and automated investigation. Merged with LogRhythm in July 2024; sells the cloud New-Scale platform and the self-hosted LogRhythm SIEM. New-Scale platform (and the self-hosted LogRhythm SIEM it now sells), Palo Alto Networks Cortex XSIAM, and IBM QRadar SIEM IBM QRadar Enterprise SIEM with real-time correlation, ML-assisted prioritization, and broad ecosystem integration. IBM sold its QRadar SaaS business to Palo Alto Networks (deal closed August 31, 2024); SaaS customers are offered migration to Cortex XSIAM, while QRadar on-premises deployments continue to receive IBM features and support. (on-premises). For chains too slow for any correlation window, the engineering answer is risk-based alerting (for example Splunk ES RBA) and UEBA entity risk scoring.
Correlation's sibling: grouping and dedup
One underlying activity rarely produces one alert. A single malicious download can fire the EDR’s signature engine, the proxy’s reputation check, the IDS rule, and the SIEM correlation built on top of all three. Before chaining events into a sequence, group the alerts that are the same event seen by different sensors: same entity, same artifact, overlapping timestamps. Counting one activity four times inflates severity, and investigating it four times wastes three analysts. The case, not the alert, is the unit of work: grouped alerts (same entity and window, or a vendor incident ID) form one case, the case’s depth level is set by its riskiest member, and a grouped case never closes at Level 0 if any member fails the eligibility gate. Most SIEM/SOAR stacks do first-pass grouping automatically; the analyst owns the final judgment on what is a duplicate versus a genuinely new observation.
Example: a chain no single rule catches
The fast version of chain detection is already covered: the rule example shows a single rule catching an Office-to-PowerShell chain because both steps land on one host within 60 seconds. This example is the other kind: a chain no rule in this SOC assembled.
A week of quiet steps on one account
None of these events produced a high-severity alert. Two were logged without alerting at all. The chain only exists if someone assembles it.
What happened around the account j.moreau over eight days:
Day 1 09:14 VPN login from a residential ISP in a new city
Low-severity geo alert, auto-closed by playbook
Day 3 22:47 SMB share enumeration across two file servers
Logged by EDR; below alerting threshold
Day 6 21:03 New service account created: svc-backup-2
Change-audit event; no ticket referenced
Day 8 02:19 svc-backup-2 compresses 4 GB from a finance share
and uploads it to a personal cloud-storage domain
Medium-severity DLP alert on the upload onlyThe Day 8 DLP Data Loss Prevention (DLP) Controls that inspect data in motion, at rest or in use, and alert on or block sensitive content leaving approved channels: email, web uploads, removable media, cloud sync. A DLP alert names a policy match, not intent; triage asks what the data was, where it went, and whether the destination was sanctioned. alert is the only thing in front of the analyst. Validated in isolation, it reads like a misconfigured backup job pointed at a new cloud destination: a ticket for the platform team, not an intrusion.
The chain is what changes the reading. Pivoting on the service account, and then on the account that created it, connects four events that no rule linked: they span eight days (longer than any correlation window configured in the SIEM), four data sources (VPN, EDR, change audit, DLP), and two identities. Promoting the Day 1 geo alert or the Day 3 enumeration to analyst-reviewed alerts on their own would drown the SOC in benign alerts, and a rule tuned to the whole eight-day sequence would be too specific to fire again. The Day 6 step is different: a service-account creation with no change ticket is low-volume and deserved its own alert. That it was only logged is a detection gap to feed back to detection engineering.
In this case the chain was caught because an analyst asked what sequence the alert in front of them belonged to. The engineering answer is risk-based alerting or entity risk scoring: low-fidelity observations add risk to an entity over days instead of raising alerts. That would have counted the auto-closed Day 1 login and the unalerted Day 3 and Day 6 events against j.moreau, provided the account-creation event attributes risk to both the creator and svc-backup-2.
This is the question asked in Alert and answered in Uncover. The Alert-phase pivot (svc-backup-2’s last 7 days, which surface its creation by j.moreau on Day 6 with no ticket) is enough to stop treating the upload as a misconfiguration and to hand off a chain lead. The checks below are the full reconstruction, and they belong to Uncover.
What the full reconstruction checks:
- The initial access. Was the Day 1 VPN login protected by MFA, and did it come from a device the user had used before? The authentication logs answer whether the account was already compromised before anything else happened.
- The enumeration scope. Which shares did the Day 3 activity touch? If the Day 8 upload came from a share enumerated on Day 3, coincidence becomes sequence.
- The service-account creation. Who authorized svc-backup-2? An unreferenced change that stages data two days later is the strongest link in the chain, and it pivots the investigation onto a second identity.
- The destination. Domain registration data (RDAP, which replaced WHOIS WHOIS / RDAP Domain-registration lookup. For gTLDs, RDAP (RFC 9082/9083) replaced WHOIS as the authoritative source on 28 January 2025; many ccTLDs and .com still answer WHOIS. Registrant identity is usually redacted, so the useful triage fields are creation date, registrar, name servers and status, not the owner. for generic TLDs in January 2025; some country-code TLDs still answer only WHOIS), DNS prevalence, and threat-intelligence Threat Intelligence Evidence-based knowledge about existing or emerging threats, including context, mechanisms, indicators, implications, and actionable advice (after Gartner's widely cited definition). It is consumed at strategic, operational, and tactical levels. Before acting on it, weigh the source's reliability, the information's credibility (the Admiralty code is one common scheme), and its age. overlap for the cloud-storage domain, plus one wider question: has any other account in the environment sent data there?
What makes the chain stronger than the parts
Each event in the example had a plausible legitimate explanation on its own: people travel, admins enumerate shares, service accounts get created, backup jobs get repointed. The chain is stronger than the sum of the parts because the combination (new-location access, then enumeration, then unauthorized account creation, then staging and egress, all traceable to one identity) describes a progression with intent. Correlation, whether an engine runs it inside a window or an analyst runs it across a week, is the strategy that surfaces these combinations without a hand-crafted rule for every permutation.
What this means for triage
- Search both directions in time. The alert in front of you may be the first, middle, or last visible step; pivot before and after it.
- Check retention before concluding a step did not happen. An eight-day chain needs at least eight days of searchable, consistently normalized data from every source in it. Endpoint telemetry often keeps far less.
- Hand off the chain, not just the alert. A linked step is a lead for Uncover, recorded with its source and timestamp, even when you stop pivoting.
For detection engineering and platform owners
- Tune and validate correlation rules on a regular cadence. A correlation rule that worked well last quarter may fire on legitimate activity this quarter as the environment shifts.
- Keep long-term retention and consistent normalization Normalization Converting logs and events from different sources into a common field schema, such as OCSF, ECS, Splunk CIM, Microsoft Sentinel ASIM or Google SecOps UDM, so a username, IP, or timestamp means the same thing regardless of which tool recorded it. SIEM correlation rules and cross-source queries depend on it; fields that were never normalized are where searches silently miss. to support multi-step analysis. Size retention to realistic attacker dwell time and the longest chain you expect to investigate, not to your correlation window.
- Integrate endpoint, network, and identity telemetry Telemetry The event streams that endpoints, network sensors, identity providers, SaaS apps and cloud control planes emit about what happened on them. Triage can only see what was collected: when telemetry is missing for a host or time window, record it as a gap (unknown is not Low), not as clean. . Correlation lives at the seams between data sources. A chain that crosses three sources is far more informative than one within a single source.
- Feed auto-closed alerts into entity risk. A playbook close removes an alert from the queue, not from the entity’s history.
- Provide real-time processing capacity. Batch-only correlation misses the speed window during which response is most effective.
- Close the loop with triage. Triage and detection engineering covers the tuning request, the routing for each verdict, and the per-rule numbers both teams share.
Key takeaway
Attack-chain correlation is the strategy that catches the attacks no single event would catch. Platforms assemble the chains they have patterns and windows for; the analyst assembles the rest by pivoting on time, assets, technique, and targeting. Used well, it turns validation from “is this one event bad?” into “what sequence is this event part of?”, the question most intrusions cannot survive.
Next up
Back to alert validation
In Alert, chain thinking is one pivot with a stopping point. Return to the validation strategies and the handoff.
Back to validationTechnical details verified . Product names, defaults and retention change; check your own tenant.