IR AnalystSwitch roles in the top navigation to see different perspectives.

Establish the earliest known indicator of compromise (IOC) and the latest known malicious activity to define the investigation window. This prevents scope creep and focuses collection efforts on relevant evidence.

Actions

  1. 1.Query SIEM for the earliest alert or IOC match and record the timestamp as T-start; search across all log sources (EDR, firewall, proxy, authentication) for corroborating events within +/- 24 hours.
  2. 2.Use PowerShell to pull the $MFT timeline: `Get-ForensicTimeline -VolumeName C: | Where-Object { $_.Date -ge $tStart -and $_.Date -le $tEnd } | Export-Csv mft_timeline.csv` -- compare with SIEM timestamps.
  3. 3.Run Velociraptor hunt `Windows.Timeline.MFT` across suspected hosts to identify file creation/modification clusters that may push T-start earlier.
  4. 4.Cross-reference email gateway logs for earliest delivery of malicious payload: `index=email sourcetype=proofpoint action=delivered | stats earliest(_time) as first_seen by sender, subject`.
  5. 5.Document the bounding timestamps in the incident ticket: T-start (earliest IOC), T-alert (first detection), T-now (current time), and the resulting investigation window.

Queries

index=* (sourcetype=crowdstrike OR sourcetype=defender OR sourcetype=sysmon) earliest=-30d | stats earliest(_time) as first_seen latest(_time) as last_seen by src_ip, dest_ip, process_name | where first_seen < relative_time(now(), "-7d")
SecurityEvent | where TimeGenerated between (ago(30d) .. now()) | where EventID in (4624, 4625, 4648, 4672) | summarize FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated) by Account, Computer, LogonType | order by FirstSeen asc
DeviceProcessEvents | where Timestamp > ago(30d) | where FileName in~ ("powershell.exe","cmd.exe","wscript.exe","mshta.exe","certutil.exe") | summarize EarliestExec=min(Timestamp), Count=count() by DeviceName, FileName, InitiatingProcessFileName | order by EarliestExec asc

Notes

  • Always pad the investigation window by at least 48 hours before T-start -- attackers often perform reconnaissance days before the first detected IOC.
  • If log retention does not cover the full window, escalate immediately to preserve whatever remains and engage backup/archive recovery.

Common Blockers

Critical Logs Rotated/Overwritten Before Collection

Key log files (Security EVTX, web server access logs, syslog) have been rotated out or overwritten due to aggressive retention settings, high volume, or attacker manipulation. The evidence window for those sources is now closed.

M365/Azure Logs Past Retention Period

Unified Audit Log (UAL) entries in Microsoft 365 or Azure AD sign-in logs have expired beyond the default 90-day (E3) or 180-day (E5) retention window. Historical evidence of initial access, mailbox abuse, or OAuth consent grants is no longer available in the tenant.

SIEM Not Ingesting Relevant Log Sources

The SIEM does not ingest logs from the affected systems, applications, or network segments. Correlation, alerting, and historical search capabilities are unavailable for the evidence sources most relevant to this incident.

Need Data from External Vendor or MSP

Critical evidence resides with a third-party managed service provider, SaaS vendor, or hosting company. Your team has no direct access and must navigate contractual, legal, and technical hurdles to obtain logs or images.

Attacker Used Timestomping, Log Clearing, or Other Anti-Forensics

Evidence of deliberate anti-forensic activity has been found: timestamps modified, event logs cleared, prefetch/shimcache wiped, or tools designed to defeat forensic analysis were executed. Standard timeline analysis may be unreliable.

Regulatory Notification Deadline Approaching

A regulatory reporting deadline (GDPR 72-hour, SEC 4-day, state breach notification, HIPAA) is imminent and the investigation has not yet determined the full scope of data exposure. The team must balance thorough investigation against mandatory disclosure timelines.

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.