In this section
Multi-Environment Attack Triage: Why Attacks Cross Environments
Six modules, one attacker
This course taught triage one environment at a time, because that is how you learn to read evidence: identity in TR2, applications in TR3, endpoints in TR4, cloud and hybrid in TR5, network in TR6. The modules are boundaries you imposed to learn. The attacker imposed none of them. A real intrusion is one continuous operation that moves through whichever environments get it closer to its goal: phish a credential, replay the token, land on an endpoint, harvest more credentials, pivot to the cloud, register a backdoor, exfiltrate over the network. The attacker does not think "now I am doing the endpoint phase"; they think "I need the next thing," and the next thing is wherever it lives. The layer boundaries are yours, not theirs.
That mismatch is the whole problem this module addresses, and it is the reason multi-environment attacks succeed so reliably. Your tooling is organised by layer, the SIEM tables, the EDR console, the identity logs, the firewall, each a separate surface. Your teams are organised by layer, identity, endpoint, network, often different people, sometimes different shifts. And your triage, as you have practised it, is organised by layer. So a single attack that crosses four environments arrives as four separate signals, in four surfaces, to four readers, each of whom sees a fragment that looks complete on its own and closes it. The attack runs straight through the seams between your defences, and those seams are the boundaries the course taught in. This module is about reading across them.
Per-layer triage under-scopes by design
The failure is not that analysts are careless; it is structural. Each layer's evidence looks like a whole incident in isolation. The endpoint team sees a credential-theft alert on a laptop, contains the host, and closes a complete-looking endpoint incident. The identity team sees an anomalous service-principal sign-in, resets it, and closes a complete-looking identity incident. Neither is wrong about their fragment, and neither has any prompt to look at the other layer, because their tooling does not span it and their fragment did not feel incomplete. The result is that the multi-environment attack is consistently under-scoped: every team contains its piece, the attacker keeps the pieces nobody owned, and the incident is declared resolved while the chain is still live in the gaps between the closed tickets.
You saw the two-layer version of this in TR6: the network ticket and the identity ticket were one chain, and closing either alone left the other half live. Multi-environment triage is that lesson generalised to every layer at once. The same attack can leave evidence in the endpoint logs, the on-prem directory, the cloud audit trail, the sign-in logs, and the firewall, and each of those is a separate surface watched by a separate process. The more environments the attack crosses, the more fragments it shatters into, and the more certain it is that no single reader sees the whole. Under-scoping is the default outcome of per-layer triage against a cross-layer attacker, and avoiding it requires deliberately doing what the silos do not: looking across them.
The boundaries are yours. The attacker crosses them, and your siloed surfaces each catch one piece. Under-scoping is not a mistake here; it is the design working as built.
The fix is a method, not more tools
It is tempting to think the answer is a better platform, one console that shows everything, and a unified surface helps. But the deeper fix is a method you can apply regardless of tooling, because even with everything in one SIEM the evidence still arrives as separate events in separate tables that no query joins for you by default. The method has two moves, and the rest of this module is them. First, pivot on shared entities: the indicators that appear in more than one layer, an IP, an account, a host, a device, a time window, are the threads that connect the fragments, and following a shared entity from one layer's evidence into another's is how you discover that two incidents are one. Second, build a unified timeline: put every layer's evidence on a single time axis so the multi-stage sequence becomes a story you can read top to bottom, rather than four fragments you hold in your head and hope to connect.
Those two moves are not new; you did both by hand in TR6, pivoting on the attacker IP from the network logs into the identity logs and laying the two on one timeline. Multi-environment triage is that exact technique applied deliberately and at scale, to every layer an attack might cross. The skill is not knowing a new tool; it is refusing to accept a layer's fragment as the whole incident, and doing the cross-layer work the silos will not do for you. The attacker's advantage is that your defences are organised by boundary; your counter is to read across the boundary on purpose.
The counter to a boundary-crossing attacker is to cross the boundaries on purpose: thread the fragments on a shared entity, then lay them on one timeline.
The common mistake
Treating each layer's alert as a self-contained incident because it looks complete and the tooling does not prompt otherwise. The endpoint alert has a host, a process, a credential-theft artifact, everything an endpoint incident needs, so it gets contained and closed; the cloud sign-in alert has an account, an IP, a risk score, everything a cloud incident needs, so it gets reset and closed.
Neither analyst is careless, and neither fragment felt partial, which is exactly why the multi-environment attack survives: it is not that anyone failed to investigate their piece, it is that nobody was prompted to ask whether their piece was part of something larger. The silo does not raise that question, so the analyst must. The fix is a standing habit, not a tool: before closing any layer's incident, ask what came before it in another layer and what it could feed into next.
A credential stolen on an endpoint goes somewhere; a service principal signing in from a hosting IP came from somewhere. The attack is almost never confined to the layer you found it in, and treating the fragment as the whole is how four contained incidents add up to one uncontained breach.
Seeing it in the evidence
One attack, three layers, seventeen minutes: the hybrid pivot from TR5, seen now as the single cross-environment operation it always was.
Where to find it
The evidence of a single multi-environment attack is spread across the layer-specific surfaces you already know: the endpoint logs (DeviceLogonEvents, DeviceProcessEvents) for the on-prem foothold, the directory audit trail (AuditLogs) for the cloud pivot and the backdoor registration, and the sign-in logs (AADServicePrincipalSignInLogs) for the standing cloud access. No single table holds the attack; each holds one layer of it. The work of this module is treating those separate surfaces as one incident, which begins by querying each for the same attack and noticing they describe consecutive stages of one operation.
SIEM Console
Each surface answers for its own layer: the endpoint logon for the on-prem foothold, the audit log for the directory pivot and app registration, the service-principal sign-in for the standing cloud backdoor. Run separately they are three incidents; read on one timeline they are three stages of one attack, minutes apart. The module teaches the join the console will not do for you.
azure-aad-signin-sp src_ip="185.220.101.47"
| table _time, sp_name, src_ip, resourceAADServicePrincipalSignInLogs
| where IPAddress == "185.220.101.47"
| project TimeGenerated, ServicePrincipalName, IPAddress, ResourceDisplayName# Graph PowerShell: the cloud half of the cross-environment chain
Get-MgAuditLogSignIn -Filter "ipAddress eq '185.220.101.47'" |
Select-Object createdDateTime, servicePrincipalName, ipAddressRead the output
Predict before running. The panel returns the cloud half of the hybrid attack: a service principal signing in from the attacker IP against a sensitive resource, the standing backdoor. On its own that is a complete-looking cloud incident, exactly the fragment a cloud-focused triage would close. Now place it against the other surfaces for the same incident.
In the endpoint logs, the on-prem foothold on the directory-sync server appears at 14:14. In the audit log, the app registration and permission grant, the pivot, appear minutes later. In this sign-in log, the backdoor authenticates at 14:31.
Three layers, seventeen minutes, one operation: an attacker who reached an on-prem server, used the directory-sync trust to cross into the cloud, and planted a service principal that survives any on-prem cleanup. Read in isolation, the cloud team would reset the service principal and close; the endpoint team would clean the server and close; neither would know the other existed. Read together they are one attack, and the seventeen-minute span is the whole chain. Run the panel and read this not as a cloud incident but as one stage of a cross-environment operation whose other stages are in other tables.
This is the whole module in preview: the same evidence the silos hold as three incidents, laid on one axis as three stages of one. The next subs build this timeline deliberately.
Your turn
Your SOC has three open tickets this week: an endpoint credential-theft alert on a server (endpoint team), an unusual application registration in the tenant (cloud team), and a service-principal sign-in from a hosting IP (identity team). Each team has triaged its own and is ready to close. What is the question none of them has been prompted to ask, and how would you test whether these are three incidents or one?
Reveal
The question none of them has been prompted to ask is whether their fragment is part of something larger, specifically, what came before their event in another layer and what it could feed into next. Each ticket looks complete inside its own surface: the endpoint alert has a host and a stolen credential, the app registration has an actor and a tenant change, the service-principal sign-in has an account and an IP. None of the three felt partial to the analyst who triaged it, which is exactly why the silo is dangerous, completeness within a layer is not completeness of the incident. The structural reality is that these three events are the classic shape of a single hybrid attack: a credential stolen on an endpoint, used to register a backdoor application in the cloud, which then signs in as a service principal. The sequence is suspicious precisely because the three layers line up into one operation. How you test whether they are one incident or three is by looking for shared entities and consistent ordering across the tickets. Do they share an account, the credential stolen on the endpoint being the one that registered the app or that the service principal relates to? Do they share a time window, the endpoint theft preceding the app registration preceding the sign-in, in minutes or hours, not at random? Do they share an actor or origin, the same IP, the same host as the pivot point? If the entities connect and the timing orders into a coherent sequence, they are one attack, and closing them as three would contain each fragment while leaving the chain intact, the endpoint cleaned but the cloud backdoor live, or the service principal reset but the foothold that created it still inside. You would unify them into a single incident, scope the full chain across all three layers, and contain it as one coordinated action. The lesson is the module's premise: the attacker runs one operation across the boundaries your teams and tools are organised by, so the fragments arrive separately and look whole, and the analyst's job is to ask the cross-layer question the silo never raises.
Where this leads: you have the problem, an attack that crosses the boundaries your defences are built on, and the two moves that solve it. The next sub takes the first move in depth: the shared entity, the indicator that appears in more than one layer and lets you pivot from one domain's evidence into another's.