In this section
TR1.8 Cross-Environment Evidence Correlation
From TR1.2–1.4 you captured volatile evidence independently in cloud, Windows, and Linux environments. From TR1.5 you know when to preserve and when to contain. But isolated evidence from three environments doesn't tell a story — it tells three fragments. You learn to connect the fragments into a single attack narrative using three correlation methods, then automate the collection so every future triage produces consistent, correlated results.
Scenario
It's 07:30. The NE response team has preserved evidence across all three environments and executed containment at 07:10. Rachel now needs the answer to the investigation team's first question: was this one attacker operating across all three environments, or were these separate compromises that coincidentally occurred during the same weekend? The answer determines whether the investigation scopes to one incident with one attack chain, or three independent incidents with potentially three different threat actors. The evidence to answer that question exists in three different log formats — Entra SigninLogs (JSON), Windows Security events (XML/structured), and Linux auth.log (syslog plaintext). Correlating across those formats is the triage skill that determines whether the investigation starts with the right scope.
Figure TR1.8 — Three correlation methods connect evidence across environments. Timestamps show temporal proximity. IP addresses prove shared infrastructure. Entity mapping resolves identity across naming conventions.
Correlation method 1: timestamps
The most intuitive correlation method: events in different environments that occur within a narrow time window are likely related. In the NE scenario, the cloud compromise occurs at 02:17 (credential stuffing against svc-backup), the Windows DLL sideloading activates at 02:38 (21 minutes later, consistent with the attacker authenticating to the endpoint via the compromised cloud identity), and the Linux SSH pivot occurs at 03:14 (36 minutes after the endpoint compromise, consistent with credential harvesting and lateral movement).
The timing gaps between events are as telling as the events themselves. A 21-minute gap between cloud compromise and endpoint access is consistent with an attacker authenticating through Entra, discovering which endpoints the compromised account can reach, and establishing a foothold. A 36-minute gap between endpoint access and Linux pivot is consistent with running credential harvesting tools on the Windows endpoint, identifying SSH keys or passwords in memory or on disk, and using those credentials to access the Linux server.
If the Linux event had occurred 3 days after the Windows event, the correlation would be weaker — 3 days is enough time for an unrelated attacker to discover the same server independently.
Timestamp correlation requires normalising all times to UTC before comparison. Cloud logs in Entra and Sentinel use UTC natively. Windows event logs on domain-joined systems typically use UTC, but workstations may record events in the system's configured local timezone. Linux auth.log uses the system timezone configured in /etc/timezone — on a UK server, that's UTC or BST depending on the time of year. Before building any cross-environment timeline, verify the timezone setting on each source system and convert all timestamps to a common reference.
Clock drift creates a subtler problem. Systems without properly configured NTP synchronisation may drift seconds or even minutes from the correct time. A 2-minute drift between the Windows endpoint and the Linux server means events that appear 5 minutes apart may actually be 3 or 7 minutes apart. The triage responder checks NTP status on each system during evidence collection: w32tm /query /status on Windows, timedatectl on Linux. Any drift is documented in the triage report so the investigation team can adjust the timeline accordingly.
The practical output of timestamp correlation is a unified chronological timeline — a single document that interleaves events from all environments in order. This timeline is the most valuable artifact the triage responder produces for the investigation team, because it transforms three separate evidence sets into one narrative.
The investigation team opens the timeline and reads the attack story from top to bottom: authentication at 02:17, OAuth consent at 02:22, inbox rule creation at 02:31, endpoint logon at 02:31, DLL sideloading at 02:38, C2 establishment at 02:39, SSH pivot at 03:14, container modification at 03:14. Without this unified timeline, the investigation team would spend their first hour reconstructing exactly what the triage responder already knows.
Correlation method 2: IP addresses
IP address correlation connects events across network boundaries. When the same external IP address appears in both Entra SigninLogs and Linux auth.log, the attacker used the same infrastructure to access both environments. In the NE scenario, 185.220.101.34 appears as the source IP for the cloud sign-in at 02:17, the C2 destination from the Windows endpoint at 02:38, and the SSH source for the Linux pivot at 03:14. Three appearances of the same IP across three environments within 57 minutes eliminates coincidence.
Internal IP correlation is equally valuable. When the Windows endpoint's internal IP (10.50.1.50) appears as the SSH source in the Linux auth.log, the attacker pivoted from the Windows system to the Linux server across the internal network. The internal IP correlation proves lateral movement — the attack didn't jump from the cloud directly to the Linux server. It traversed the Windows endpoint as an intermediate hop.
This is visible in the auth.log entry from TR1.4: the SSH connection to web-prod-01 originates from 10.50.1.50, which the asset inventory maps to WS-FIN-042.
IP correlation has blind spots that the triage responder must understand. VPN and proxy infrastructure can mask the attacker's true source IP. If the attacker routes traffic through a corporate VPN, the source IP visible in Entra SigninLogs is the VPN gateway's IP — shared by hundreds of legitimate users. The correlation with endpoint events must then rely on user identity rather than IP address.
Similarly, if the organisation uses a forward proxy for outbound traffic, the C2 connections from the Windows endpoint appear in external network logs as originating from the proxy's IP, not from WS-FIN-042's internal IP. The analyst cross-references the proxy logs to recover the true source endpoint. Attackers who are aware of the organisation's proxy configuration may use HTTPS to blend their C2 traffic with legitimate web browsing, making the proxy logs essential for attribution.
Cloud-to-cloud correlation adds another IP complexity. When the attacker uses the compromised OAuth token to access SharePoint, the source IP in the SharePoint audit log may be the attacker's IP (if they accessed SharePoint directly from their infrastructure) or a Microsoft service IP (if the OAuth flow traversed Microsoft's authentication proxy). Entra's conditional access and sign-in risk logs provide better visibility into the authentication chain than the downstream application audit logs.
IP address correlation has limitations the triage responder must recognise. NAT gateways and web proxies can make multiple users share a single external IP. A cloud sign-in from 185.220.101.34 and a separate legitimate user's VPN connection from the same IP would correlate falsely. Corporate proxy servers create the same problem for internal traffic — all outbound connections from a building may share a single source IP. The triage responder documents the correlation but notes the proxy/NAT caveat when the shared IP corresponds to known infrastructure.
This union query merges cloud sign-in events and endpoint process and network events into a single chronological timeline with normalised columns — Source, Activity, Entity. The output shows the attacker's progression from cloud authentication through endpoint compromise to network connections reaching the Linux server, all in UTC order. The query covers the 02:00–04:00 window that spans the entire NE attack chain.
The Linux auth.log entries don't appear in this query because web-prod-01 doesn't forward syslog to Sentinel — a common gap in organisations that treat Linux servers as outside the SOC's visibility. The triage responder adds the Linux evidence manually by extracting the relevant auth.log entries (the SSH and sudo commands from TR1.4) and appending them to the union query output as additional rows. The combined output — Sentinel query results plus manual Linux entries — becomes the definitive cross-environment timeline.
Correlation method 3: entity mapping
The same person or device appears under different names in different environments. In Entra, the compromised account is svc-backup@northgateeng.com (UserPrincipalName format). In Windows event logs, the same account appears as NORTHGATE\svc-backup (domain\SAM format) or just svc-backup (AccountName). In Linux auth.log, the attacker authenticated as deploy — a completely different identity, because the attacker used a different credential (stolen SSH key) for the Linux pivot.
Entity mapping connects these identities through the attack chain rather than through a shared username. The cloud account svc-backup was compromised at 02:17. That account authenticated to WS-FIN-042 at 02:31 (visible in DeviceLogonEvents). WS-FIN-042's IP address (10.50.1.50) then appeared as the SSH source for deploy on web-prod-01 at 03:14. The entity mapping is: svc-backup (cloud) → NORTHGATE\svc-backup (Windows) → deploy (Linux, via SSH key found on the Windows system). Three different usernames, one attacker, connected by the device that bridges the environments.
Device entity mapping follows a parallel pattern. The compromised endpoint is WS-FIN-042 in Defender's DeviceName field, DESKTOP-NGE042 in the local hostname, 10.50.1.50 in network logs, and 6c:4b:90:1e:2a:f7 in DHCP records. The attacker's C2 server is 185.220.101.34 in every environment — but only because this particular attacker didn't use separate infrastructure for each stage. A more sophisticated attacker might use different IPs for each environment, eliminating IP correlation and making entity mapping the only reliable connection method.
Building an entity mapping table before the incident is a readiness exercise that pays dividends during triage. The table maps each person's cloud UPN to their Active Directory SAM name, their Linux usernames on each server, their endpoint hostnames, and the IP ranges associated with their team's network segment. During an incident, the analyst looks up the compromised entity in the mapping table and immediately knows which names to search for in each environment's logs.
Without this pre-built mapping, the analyst spends precious triage minutes figuring out that svc-backup and NORTHGATE\svc-backup are the same account — time that should be spent assessing scope and impact.
The mapping table is not a one-time creation exercise. It requires maintenance as employees join, leave, change roles, and as service accounts are created or decommissioned. Organisations that maintain their entity mapping in a dynamic source — an IT asset management database, a configuration management database (CMDB), or an identity governance platform — can generate the mapping table automatically during an incident. Organisations that maintain it in a spreadsheet need a scheduled review (quarterly at minimum) to keep it current.
A stale mapping table is worse than none at all when it directs the analyst to search for an entity that no longer exists or misses one that was recently created.
Service accounts create an additional entity mapping challenge because they often don't map cleanly to a single person. svc-backup may be used by three different administrators, each of whom could have been the point of credential compromise. The triage responder documents the service account's authorised users (from the identity governance records covered in IAM) and flags all three administrators as potentially affected entities requiring investigation.
The attacker may also have created new service accounts or modified existing ones during the compromise — entity mapping at the time of the incident may not match entity mapping at the time of the attacker's initial access if the attacker has been persistent for weeks.
The correlation confidence levels documented in the incident comment give the investigation team a clear signal. Moderate confidence (one shared indicator — IP only) means the correlation is plausible but requires additional verification. High confidence (two shared indicators — IP plus temporal proximity) means the correlation is strong but not definitive. Definitive confidence (three or more shared indicators — IP, timing, internal lateral movement path, shared credentials) eliminates reasonable doubt.
The NE scenario reaches definitive confidence because four independent indicators all point to the same attacker.
Sentinel's entity mapping and incident grouping help — alerts referencing the same user or IP may be grouped into a single incident. But Sentinel only correlates what it's configured to correlate. If the analytics rules for cloud events use UserPrincipalName and the rules for endpoint events use AccountName, Sentinel may create two separate incidents for the same attack. If Linux logs aren't forwarded to Sentinel at all — a common gap for organisations that treat Linux servers as outside the SOC's responsibility — those events are invisible. The triage responder verifies the correlation manually across all environments, including those outside Sentinel's visibility.
Triage Principle
Every triage should include a cross-environment check, regardless of whether the initial alert suggests cross-environment activity. For cloud alerts, check which endpoints the compromised user authenticated to in the last 48 hours. For endpoint alerts, check whether the user has cloud identity alerts in the same window. For Linux alerts, check whether the SSH source IP maps to a known Windows endpoint. This bidirectional check takes 2 minutes and prevents the investigation team from discovering uncontained systems days later.
Get weekly detection and investigation techniques
KQL queries, detection rules, and investigation methods — the same depth as this course, delivered every Tuesday.
No spam. Unsubscribe anytime. ~2,000 security practitioners.