Chapter 3

Identification and Scoping

From first alert to confirmed incident — the scoping questions that define the blast radius, patient zero identification workflow, and how to map lateral movement before the attacker knows you're looking.

Scenario

An EDR alert fires at 3 AM: Mimikatz detection on LAPTOP-JSMITH. The on-call analyst isolates the host. Done, right? No. Mimikatz means credential dumping. Every credential that was in LSASS on that machine — domain user sessions, cached credentials, Kerberos tickets — may now be in the attacker's hands. The real work is: what was in LSASS when this ran? What could those credentials reach? Did the attacker move before you isolated? The host isolation was the right containment action. But scoping the blast radius is what separates an incident that ends in one day from one that ends with domain compromise three weeks later when the attacker uses a credential harvested on night one.

From Alert to Confirmed Incident

Not every alert is an incident. The first task is determining whether the alert represents actual malicious activity, and if so, at what severity.

  Alert Triage Decision Flow
  ═══════════════════════════════════════════════════════════════════

  Alert fires
       │
       ▼
  Is this a known false positive?  ──► Yes → Close, tune detection
       │ No
       ▼
  Is there corroborating evidence?
  (process tree, network connection, registry change, file creation)
       │
       ├── No corroboration → Investigate further before escalating
       │                       (check SIEM, pull EDR telemetry)
       │
       └── Yes → Confirmed malicious activity
                      │
                      ▼
                Severity classification
                (see severity matrix below)
                      │
                      ▼
                Declare incident → open case → notify IR lead

Severity	Criteria	Response time	Escalation
P1 — Critical	Active ransomware spreading, DC compromise, confirmed data exfiltration of PII/PCI/PHI, active adversary with domain admin, destructive payload	Immediate — wake IR lead now	CISO, legal, leadership within 30 min
P2 — High	Credential dumping, confirmed lateral movement, malware execution with C2 established, privileged account compromise	Within 1 hour	IR lead, CISO within 2 hours
P3 — Medium	Malware execution (no C2 confirmed), phishing click (no execution), reconnaissance activity	Within 4 hours (business hours)	IR lead notification, SOC handles investigation
P4 — Low	Suspicious but unconfirmed — likely benign with unusual characteristics	Next business day	SOC handles, document findings

The Scoping Questions

Scoping is the most important and most commonly rushed step. The goal is to define the blast radius — every system, account, and data source the attacker may have touched — before acting on that knowledge.

Question	Why it matters	Where to find the answer
What is compromised?	Defines the scope of eradication work	EDR telemetry, SIEM correlations, log analysis
How many systems?	Determines IR team size needed and containment timeline	EDR host list, SIEM alert volume, network flow logs
Since when?	Defines the forensic collection window and whether backups are clean	Earliest malicious event in SIEM / EDR historical data
What data was accessed?	Determines regulatory notification obligations	File access logs, DLP events, cloud storage API logs
How did they get in?	The initial access vector must be closed before recovery	Perimeter logs, phishing reports, credential breach databases
Do they know we know?	Determines whether stealth collection is still possible	No direct answer — infer from timing of their last action vs your first alert
What can they still do?	The current threat — informs priority of next containment action	Live EDR — what processes are running? What connections are active?

Patient Zero Identification

Patient zero is the first compromised host — the entry point. Finding it is essential for closing the initial access vector. Without it, you eradicate what you find and the attacker uses the same door to return.

Patient Zero Identification Workflow
═══════════════════════════════════════════════════════════════════

Start: confirmed malicious activity on HOST-A
│
▼
1. What is the earliest malicious event timestamp?
→ Search EDR for same process/IOC going back 30-90 days
→ Check SIEM for earliest occurrence of C2 domain/IP

│
▼
2. Trace backwards from the first malicious event
→ What executed? What was its parent process?
→ Was it launched from a document? A scheduled task? A service?
→ What network connection preceded execution? (phishing? exploit?)

│
▼
3. Check authentication logs at the time of first execution
→ 4624 (logon) events before the malicious process?
→ Who was logged in? From what source IP?
→ Was it a legitimate user session or a remote logon from unusual IP?

│
▼
4. Was HOST-A the first? Or did the attacker come FROM another host?
→ Check 4648 (explicit credential logon) events before the malicious
event — did the attacker log in from HOST-B first?
→ If yes: HOST-B may be patient zero, not HOST-A

│
▼
5. Repeat until you reach the host with no predecessor
→ No prior logon from another host before first malicious event
→ Initial access vector is apparent (phishing email, VPN creds,
exploited internet-facing service)

PowerShellpatient-zero-hunt.ps1

# Find earliest occurrence of a known-malicious process name in Sysmon logs
$maliciousProcess = "cobalt_beacon.exe"
Get-WinEvent -FilterHashtable @{
    ProviderName = 'Microsoft-Windows-Sysmon'
    Id = 1
} | Where-Object { $_.Message -match $maliciousProcess } |
    Sort-Object TimeCreated |
    Select-Object -First 5 |
    ForEach-Object {
        $xml = [xml]$_.ToXml()
        [PSCustomObject]@{
            Time        = $_.TimeCreated
            Process     = ($xml.Event.EventData.Data | Where-Object Name -eq 'Image').'#text'
            ParentProc  = ($xml.Event.EventData.Data | Where-Object Name -eq 'ParentImage').'#text'
            CommandLine = ($xml.Event.EventData.Data | Where-Object Name -eq 'CommandLine').'#text'
            User        = ($xml.Event.EventData.Data | Where-Object Name -eq 'User').'#text'
        }
    } | Format-List

# Find logon events preceding a specific timestamp on a host
$beforeTime = [datetime]"2026-09-19T03:15:00"
Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4624
    EndTime   = $beforeTime
    StartTime = $beforeTime.AddHours(-2)
} | ForEach-Object {
    $xml = [xml]$_.ToXml()
    [PSCustomObject]@{
        Time      = $_.TimeCreated
        Type      = ($xml.Event.EventData.Data | Where-Object Name -eq 'LogonType').'#text'
        User      = ($xml.Event.EventData.Data | Where-Object Name -eq 'TargetUserName').'#text'
        SourceIP  = ($xml.Event.EventData.Data | Where-Object Name -eq 'IpAddress').'#text'
    }
} | Format-Table

Mapping Lateral Movement

Lateral movement leaves traces in authentication logs. The key is correlating logon events across multiple machines before the attacker knows you're looking — because once they know, they may destroy logs or move aggressively.

  Lateral Movement Trace in Event Logs
  ═══════════════════════════════════════════════════════════════════

  Machine A (initial compromise)
    03:15 — Mimikatz runs (credential dump from LSASS)
    03:17 — Process creation: cmd.exe → net use \\MACHINE-B\ADMIN$

  Machine B (lateral movement target)
    03:17 — Event 4624 LogonType 3 (network logon)
             User: CORP\admin-jsmith (credential harvested from A)
             Source IP: 10.1.2.50 (Machine A)
    03:18 — Event 7045 (new service installed — psexec-style)
    03:18 — Process: cmd.exe under new service

  Machine C (second hop)
    03:22 — Event 4624 LogonType 3
             User: CORP\admin-jsmith
             Source IP: 10.1.2.60 (Machine B)

  Reading the trail:
    A → B → C is the lateral movement path
    The credential used: admin-jsmith (compromised on A)
    Initial access on A: occurred before 03:15
    → Search A's logs from BEFORE 03:15 for the initial compromise

PowerShelllateral-movement-hunt.ps1

# Hunt for network logons (Type 3) using a specific user account across all DCs
# (run on domain controller or via WinRM against DC)
$compromisedUser = "admin-jsmith"
$since = [datetime]"2026-09-19T02:00:00"

Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4624
    StartTime = $since
} | ForEach-Object {
    $xml = [xml]$_.ToXml()
    $data = $xml.Event.EventData.Data
    $user = ($data | Where-Object Name -eq 'TargetUserName').'#text'
    $type = ($data | Where-Object Name -eq 'LogonType').'#text'
    if ($user -like "*$compromisedUser*" -and $type -in @('3','10')) {
        [PSCustomObject]@{
            Time     = $_.TimeCreated
            Type     = $type
            User     = $user
            Source   = ($data | Where-Object Name -eq 'IpAddress').'#text'
            WorkStn  = ($data | Where-Object Name -eq 'WorkstationName').'#text'
        }
    }
} | Sort-Object Time | Format-Table

Defining the Blast Radius

The blast radius is the complete set of systems, accounts, and data the attacker had access to — whether or not they used that access. The distinction matters: just because the attacker didn't do something doesn't mean they couldn't. All accounts with access to compromised systems must be treated as compromised regardless of evidence of specific use.

  Blast Radius Definition
  ═══════════════════════════════════════════════════════════════════

  Confirmed compromised (saw malicious activity):
    LAPTOP-JSMITH, SERVER-FILES01, DOMAIN-CONTROLLER-02

  Potentially compromised (attacker had access or credentials):
    All machines admin-jsmith logged into in the last 30 days
    All machines where admin-jsmith has admin rights
    All services where admin-jsmith is a service account
    All data accessible from SERVER-FILES01

  Credential blast radius (Mimikatz ran on LAPTOP-JSMITH):
    All accounts whose credentials were in LSASS at time of dump:
      → Currently logged-on users' credentials
      → Cached domain credentials (last 10 domain users to log in)
      → Service account credentials running as services
      → Kerberos tickets currently cached
    → ALL of these must be treated as compromised

  Data blast radius:
    SERVER-FILES01 file shares accessible by compromised accounts
    → Check DLP and file access logs for reads/copies in the IR window
    → Document for regulatory notification assessment

Why "access ≠ action" changes scoping

Ransomware operators routinely dwell in an environment for weeks before deploying the payload. During that time, they may exfiltrate data, create backdoor accounts, and map the entire network — and leave no obvious trace of each individual action. When scoping, the question is not "what did we see the attacker do?" but "what was the attacker able to do?" Access to a file server means every file on that server must be assessed for potential exfiltration. An account compromise means every system that account could reach is potentially compromised. Narrowing scope based only on confirmed observed actions is one of the most common IR mistakes — and the one that leads to re-compromise two weeks later.

Q & A

Q: How long should scoping take before you start containing?

It depends on the specific incident and the attacker's current activity level. For a confirmed active adversary who is still moving laterally, initial containment of clearly-confirmed hosts can happen in parallel with scoping — but you hold suspected hosts in monitor mode (logging everything but not cutting them off) until you understand the full scope. For ransomware that's actively encrypting, the calculus changes: stop the spread first because every minute of dwell adds more encrypted machines. The goal is to never contain a subset of compromised machines while leaving the rest running — partial containment can trigger a destructive payload or cause the attacker to move everything faster.

Q: Mimikatz ran on a machine. How do you determine exactly which credentials were in LSASS at the time?

Check authentication events on that machine in the 8-12 hours before the Mimikatz execution. Event 4624 with LogonType 2 (interactive), 3 (network), 7 (unlock), 10 (Remote Interactive / RDP), and 11 (cached credentials) all represent sessions that place credentials in LSASS. Every account that appears in those events should be treated as compromised. Cross-reference with the service account list (services running on the machine whose credentials may also have been in LSASS). If memory was captured before shutdown, Volatility's windows.lsadump and windows.hashdump can show exactly what was in memory, but this requires forensic analysis.

Q: The attacker's initial access was 30 days before the alert. You need 30 days of logs. Does your SIEM retain that long?

This is a preparation failure that becomes an investigation gap. Standard SIEM retention is 30-90 days for hot (searchable) storage and 1-2 years for cold (archived, not immediately searchable). If hot retention is 30 days and the breach is 31 days old, the oldest events may be rotated out. Immediate action: check if cold archive is available and how quickly it can be restored to searchable state. Long-term fix: increase hot retention to 90 days minimum for Security and authentication logs. During the investigation, compensate for log gaps using EDR telemetry (most EDRs retain 7-90 days), DNS query logs, proxy logs, and email gateway logs — each of which may have independent retention policies.