TR0.4 The NE Attack Timeline

CHAIN-HARVEST extended: cloud → Windows → Linux

Figure TR0.4 — CHAIN-HARVEST extended across three environments. Each downward arrow represents a boundary crossing — and a triage intervention point where earlier detection changes the outcome.

The cloud session token gives the attacker access to j.morrison's M365 environment, including OneDrive. The attacker places a malicious DLL in j.morrison's OneDrive sync folder. When DESKTOP-NGE042 syncs, the DLL is pulled locally. A scheduled task that j.morrison created months ago triggers the DLL — the attacker now has code execution on a Windows endpoint.

At 14:45, the attacker dumps LSASS memory using the comsvcs.dll technique — j.morrison has local admin, a common but dangerous configuration. The dump reveals cached credentials for svc-dbadmin, a service account that j.morrison's workstation uses for automated database report generation. At 15:12, the attacker SSH sessions from DESKTOP-NGE042 to SRV-NGE-BRS-DB01 and initiates a 4.2 GB database export of engineering drawings and specifications to an external staging server.

Five intervention points

Each boundary crossing creates a triage intervention point — a moment where detection and containment would have interrupted the chain.

Point 1 — Cloud detection (08:14). The AiTM alert fires. If the responder classifies and revokes the session within 15 minutes, the attacker loses cloud access before persistence — the MFA registration occurred at 09:22, 68 minutes after the initial alert. Incident scope: one cloud identity. Containment cost: session revocation and password reset. Total triage time: 15 minutes.

Point 2 — Persistence detection (09:22). If Point 1 is missed, the attacker registers a fraudulent MFA method. The AuditLogs show the registration. Removing the MFA method at this point prevents re-authentication after any later containment action. Without removal, the attacker re-enters after every password reset. This is why the 5-query triage pack includes the MFA check as Query 2, not Query 5 — it's time-critical.

Point 3 — BEC preparation (08:47–14:00). The inbox rule forwards financial emails. Between 09:30 and 13:00, the attacker reads 47 emails from the CEO's communications. If the responder detects the inbox rule and the mailbox access pattern during this window, the BEC email can be prevented. The attacker has the intelligence but hasn't yet sent the wire transfer request.

Point 4 — Endpoint compromise (14:30). Defender for Endpoint alerts on suspicious DLL execution. If the responder isolates the endpoint within 30 minutes, the attacker cannot pivot to Linux. The beacon has active C2 but hasn't yet been used for credential theft. Containment: device isolation plus the cloud actions from Points 1–2. Investigation scope: one endpoint and one cloud identity.

Point 5 — Lateral movement (15:12). The attacker SSH sessions to the database server. If this connection isn't detected and contained, the attacker accesses the engineering database — the ultimate target. Detection depends on Linux auth.log forwarding to Sentinel (if not forwarded, the SSH session is invisible to cloud-side triage) or the Windows endpoint's connection table showing an outbound SSH session.

Each missed point expands the scope. Point 1 missed: attacker plants persistence. Point 3 missed: attacker has BEC intelligence. Point 4 missed: attacker has endpoint access and stolen credentials. Point 5 missed: attacker has database access and is exfiltrating data. The responder who catches Point 1 resolves the incident in 15 minutes with zero business impact. The responder who catches Point 5 faces hours of cross-environment containment and confirmed data exposure.

The missed intervention is the scenario that matters most. If the triage responder triages only the cloud alert at 08:14 and revokes j.morrison's cloud sessions — the correct cloud containment — but does not check for endpoint compromise, the attacker retains endpoint access. The OneDrive-delivered DLL is already on the workstation and executing independently of the cloud session. Cloud containment does not stop the endpoint attack.

The attacker proceeds from endpoint to Linux to data exfiltration while the SOC believes the incident is contained because the cloud triage was correct within its scope.

What the investigation team needs from triage

The triage handoff for a cross-environment incident must include findings from every affected environment. A report that covers only the cloud phase hands the investigation team incomplete context — they would begin by repeating the endpoint and Linux triage that the responder should have already completed.

This report gives the investigation team a complete starting point. They don't need to re-triage any environment. They begin deep investigation — forensic analysis of the DLL, full LSASS dump analysis, database access audit, lateral movement scope assessment — from the triage responder's findings as their foundation.

The structure is intentional: classification and severity first (the IR lead needs this immediately), per-environment findings in chronological order (the timeline of the attack), evidence preserved (what the forensics team can work with), and outstanding scope questions (what to investigate next). Section 0.9 provides the full report template.

// Given a compromised device, find every system it connected to
// This is how you discover boundary crossings from the endpoint
let targetDevice = "DESKTOP-NGE042";
DeviceNetworkEvents
| where Timestamp > ago(4h)
| where DeviceName == targetDevice
| where ActionType == "ConnectionSuccess"
| where RemotePort in (22, 3389, 445, 5985, 5986)
| project Timestamp, RemoteIP, RemotePort,
    Protocol = case(
        RemotePort == 22, "SSH",
        RemotePort == 3389, "RDP",
        RemotePort == 445, "SMB",
        RemotePort in (5985,5986), "WinRM",
        "Other"),
    InitiatingProcessFileName
| sort by Timestamp asc

Timestamp                RemoteIP        RemotePort  Protocol  Process
───────────────────────  ──────────────  ──────────  ────────  ────────────
2026-02-27T14:42:18Z     10.10.4.15     445         SMB       rundll32.exe
2026-02-27T14:48:11Z     10.10.4.15     445         SMB       rundll32.exe
2026-02-27T15:12:03Z     10.10.6.50     22          SSH       ssh.exe

The output reveals the boundary crossings. Two SMB connections at 14:42 and 14:48 — the beacon probing internal network shares. Then the SSH connection to 10.10.6.50 (SRV-NGE-BRS-DB01) at 15:12 — the pivot to Linux. The process name is critical: rundll32.exe initiating SMB is the beacon (legitimate Windows SMB traffic uses svchost.exe or explorer.exe). The triage responder who runs this query immediately after isolating the endpoint at Point 4 discovers the Linux compromise before the investigation team even begins their analysis.

Evidence available at each stage

Understanding what evidence exists at each stage — and where it lives — determines what the investigation team can work with.

Cloud evidence (08:11–13:08) persists in Sentinel for 30–90 days depending on workspace configuration. SigninLogs show the spray attempts, token replay, and IP addresses. AuditLogs show MFA registration and conditional access evaluations. OfficeActivity shows inbox rule creation, mailbox access, and email sends. This evidence is not volatile in the traditional sense — it persists in cloud storage.

But it is time-sensitive: the audit log entries showing the attacker's MFA registration are useful only if the triage responder knows to look for them. The longer the gap between the attacker's actions and the triage, the more the attacker's activity blends into the background noise of normal authentication and configuration changes. The 5-query triage pack in TR2 is designed to surface these signals within the first 10 minutes of cloud triage.

Windows evidence (14:30–14:45) includes both telemetry (DeviceProcessEvents, DeviceFileEvents, DeviceNetworkEvents — queryable in Sentinel and Defender XDR) and local volatile evidence (the malicious DLL on disk, the scheduled task, memory containing the beacon configuration and C2 address). Memory is the critical volatile artifact. A reboot destroys the beacon's execution state, injected code, and C2 configuration. If the analyst triages within 15 minutes of the endpoint alert, memory contains everything. After 4 hours, the beacon may have migrated processes or the user may have rebooted.

Linux evidence (15:12 onward) includes auth.log (SSH session details — timestamp, source IP, authentication method), bash_history (database export command, if the attacker doesn't clear it), and /proc/PID/ for the active export process (command line, open files, network connections). The process state is volatile — it disappears when the process completes or is killed. The auth.log survives until rotation or deliberate clearing.

If the attacker completes the export and disconnects before triage reaches the Linux server, the active process evidence is gone, but auth.log and bash_history remain.

Practical triage timing across environments

The CHAIN-HARVEST extended timeline spans 7 hours from initial access to data exfiltration. You don't triage the entire 7-hour timeline in 15 minutes. You triage the current state in 15 minutes: is the attacker still active, what evidence is volatile right now, and what containment action stops the current threat. The full timeline reconstruction is the investigation team's job.

At NE, Rachel's cross-environment triage of this incident followed the Triage Trinity in each environment sequentially. Cloud triage came first because the alert fired on the cloud event — 12 minutes to classify, preserve sign-in and audit logs, and revoke the session.

She then identified the endpoint entity from the sign-in logs (device fingerprint and IP correlation) and ran the Windows triage: the DeviceNetworkEvents query revealed the lateral movement connections in under 30 seconds, and device isolation was executed at 14:35. Memory capture completed by 14:38. Finally, the Linux triage — the SSH session in auth.log confirmed the boundary crossing. Source IP blocked via iptables, svc-dbadmin disabled, and /proc state captured before killing the export process.

Total triage across all three environments: 25 minutes. Total time from first alert to complete containment in all environments: 38 minutes — within the 60-minute window.

The difference between triaging in sequence versus parallel depends on access. If you have direct access to all three environments (cloud portal, Defender for Endpoint, SSH to Linux servers), you can run preservation actions in parallel — cloud log export and Windows memory capture happening simultaneously. If you're working through team handoffs (passing the endpoint triage to the endpoint team), sequential is your only option, and the Triage Trinity report at each handoff ensures the receiving team starts from your findings rather than from zero.