Identify Patient Zero (First Compromised System)
Trace the earliest indicators back to the first compromised host or account. This anchors the investigation and determines the initial attack vector.
Actions
- 1.Pivot from the earliest IOC timestamp to identify the originating host: correlate source IPs, user accounts, and process trees across EDR telemetry.
- 2.Run Velociraptor artifact `Windows.EventLogs.Evtx` with a time filter around T-start on candidate hosts to find logon events (4624 Type 3/10), service installations (7045), and scheduled task creation (4698).
- 3.Check email logs for the earliest malicious delivery if phishing is suspected: `sourcetype=o365:messageTrace | search directionality=Inbound status=Delivered | where _time >= T_start | stats earliest(_time) by sender, recipient, subject`.
- 4.Examine DNS query logs for the earliest callback to known C2 infrastructure: `sourcetype=dns query IN (ioc_domain_list) | stats earliest(_time) as first_beacon by src_ip, query`.
- 5.Build a process execution timeline on the candidate patient-zero host using KAPE: `kape.exe --tsource C: --tdest \\share\case\host01 --tflush --target !SANS_Triage`.
Queries
DeviceLogonEvents | where Timestamp between (datetime(T_START) .. datetime(T_END)) | where LogonType in ("RemoteInteractive", "Network", "NewCredentials") | summarize FirstLogon=min(Timestamp), LogonCount=count() by DeviceName, AccountName, RemoteIP, LogonType | order by FirstLogon asc | take 50index=proxy sourcetype=bluecoat OR sourcetype=zscaler dest IN (ioc_ip_list) OR url IN (ioc_url_list) | stats earliest(_time) as first_contact count by src_ip, dest, url, user | sort first_contact
EmailEvents | where Timestamp > ago(30d) | where DeliveryAction == "Delivered" | join kind=inner (EmailAttachmentInfo | where FileType in ("exe","dll","js","vbs","hta","iso","img")) on NetworkMessageId | summarize Earliest=min(Timestamp) by SenderFromAddress, RecipientEmailAddress, Subject, FileName | order by Earliest ascNotes
- Patient zero may not be the most visibly compromised host -- attackers often pivot quickly. Look for the quietest host with the earliest timestamp.
- If multiple hosts show near-simultaneous compromise, suspect a supply chain or watering hole vector rather than lateral movement.
Where to Go Next
Related Artifacts
Security Event Log (4624/4625/4688)
C:\Windows\System32\winevt\Logs\Security.evtx
Message Trace Logs
Exchange Admin Center > Mail flow > Message trace (or Get-MessageTrace cmdlet)
DNS Query Logs
DNS server logs (BIND named.log, Windows DNS debug/analytical log, Pi-hole, Infoblox)
Proxy / Web Filter Logs
Web proxy appliance logs (Zscaler, Squid, Blue Coat/Symantec, McAfee Web Gateway)
Common Blockers
No EDR Agent on Compromised Hosts
The affected endpoints do not have an EDR agent installed or the agent was disabled prior to the incident. Without endpoint telemetry you lose process trees, command-line logging, and real-time containment capability.
BitLocker/Encrypted Drives Preventing Forensic Imaging
Full-disk encryption (BitLocker, FileVault, LUKS) prevents mounting or imaging the drive without the recovery key. Without decryption you cannot access the filesystem for artifact collection.
Compromised Systems Powered Off or Disconnected
Key systems have been powered off by users, IT, or as part of a premature containment action. Volatile data (running processes, network connections, memory-resident malware) is lost. Remote collection tools cannot reach the host.
Shared Cloud Environment Complicates Isolation
The compromised workload runs in a multi-tenant cloud environment (shared subscription, Kubernetes cluster, or PaaS) where isolation actions may impact other tenants or business-critical services sharing the same infrastructure.
Systems Already Rebooted -- Volatile Data Lost
The affected systems have already been rebooted (by users, IT, or automated patch processes) before memory could be captured. Running processes, network connections, injected code, and encryption keys that existed only in RAM are no longer recoverable.
Backups May Be Compromised -- Cannot Trust for Recovery
Backup integrity is uncertain. The attacker may have been present in the environment long enough to have compromised backup copies, planted persistence mechanisms in backup images, or encrypted/deleted backup repositories.