Hunt-to-IR Handoff — Packaging Evidence and Escalation Standards

A hunt finding that stays in the hunter’s notebook provides no value. The evidence must transfer to IR cleanly enough that a new analyst — who wasn’t in the hunt — can pick it up, understand it, and act correctly. Clean handoffs save hours; bad handoffs cause re-compromise.

The Hunt-to-IR Ticket Structure

P1 IR TICKET — Active C2 — [Hunt Finding]

1. AFFECTED HOST(S)
   Hostname:     WS-JSMITH-01
   IP:           10.1.2.33
   Owner:        jsmith@corp.com (Sales Engineer)
   Business role: Customer demo access — read-only CRM, full email
   Domain:       CORP

2. FINDING SUMMARY
   Hunt type:   Network beacon hunt → host pivot → memory forensics
   Confirmed:   Cobalt Strike beacon (process hollow in svchost.exe PID 8844)
                Active C2 session to 185.220.101.9:443
   Confidence:  HIGH — VT 47/72, malfind MZ header, active ESTABLISHED TCP

3. EVIDENCE CHAIN
   a. Network: CV=0.031 beacon to 185.220.101.9:443 (30 days, conn_count=1440)
   b. Sysmon:  svchost.exe PID 8844 spawned by powershell.exe PID 3444 (wrong parent)
   c. Memory:  malfind — MZ header in private PAGE_EXECUTE_READWRITE region PID 8844
   d. Memory:  netscan — ESTABLISHED 10.1.2.33:50111 → 185.220.101.9:443 (PID 8844)
   e. Hash:    injected PE SHA256 = 4a3f7e2c... → CobaltStrike.Beacon.generic (VT)
   f. Timeline: WINWORD.EXE → cmd.exe → powershell.exe (macro chain, 14:23:11)
               svcupd.exe created 14:24:02, Run key 14:24:15, beacon 14:24:18

4. IOCS
   C2 IP:      185.220.101.9 (AS12876 — Scaleway VPS France)
   C2 Port:    443 (TLS, self-signed cert, JA3: a1b2c3d4)
   Domain:     update-cdn-proxy.net (registered 14 days ago — WHOIS)
   Payload:    svcupd.exe SHA256: 4a3f7e2c...
   Persistence: HKCU\...\Run\svcmon → svcupd.exe

5. ATT&CK CHAIN
   T1566.002   Phishing (malicious Word attachment)
   T1059.003   Windows Command Shell (macro → cmd.exe)
   T1059.001   PowerShell (-enc download stager)
   T1055.012   Process Hollowing (svchost.exe)
   T1071.001   Web Protocols (TLS C2 on 443)
   T1547.001   Registry Run Keys (persistence)
   [T1003.001  Suspected — LSASS not confirmed in this hunt]

6. SCOPE ASSESSMENT
   Confirmed:  WS-JSMITH-01 (active C2 for ≥30 days)
   Suspected:  Any host jsmith authenticated to in past 30 days (credential risk)
   Pivot needed: Authentication logs — jsmith logons to other hosts
               Network logs — 10.1.2.33 internal lateral movement
   Unknown:    Whether attacker accessed file shares or CRM database

7. CONTAINMENT RECOMMENDATION (in order)
   Step 1: Block 185.220.101.9 at perimeter firewall (both directions)
   Step 2: Add update-cdn-proxy.net to DNS sinkhole
   Step 3: Disable jsmith AD account (prevent credential reuse)
   Step 4: Isolate WS-JSMITH-01 from network (VLAN or NAC quarantine)
   Step 5: Force password reset for all accounts on jsmith's host (domain-wide if DC-level access found)
   Order matters: block C2 first to prevent evidence destruction on the attacker's side.

8. EVIDENCE FILES
   memory.raw:         sha256=9b4c2f1d... (collected 2024-09-02 18:30 via Velociraptor)
   pid.8844.0x1a0000.dmp:  sha256=4a3f7e2c... (injected PE extracted by Volatility 3)
   timeline.csv:       plaso output, 2024-09-01 00:00 to 2024-09-02 23:59
   hunt_journal_2024-09-02.md: full hunt notes and query log
   Location: DFIR Evidence Server → Case #2024-089 / WS-JSMITH-01

Lateral Movement Scope Check

Before handing off, always run these three queries:

1. Authentication from Compromised Host

// Did WS-JSMITH-01 authenticate to other internal hosts?
SecurityEvent
| where EventID == 4624
| where WorkstationName == "WS-JSMITH-01" or IpAddress == "10.1.2.33"
| where LogonType in (3, 10)  // Network + RemoteInteractive
| where TargetServerName != "WS-JSMITH-01"  // to other hosts
| project TimeGenerated, TargetServerName, TargetUserName, LogonType, IpAddress
| order by TimeGenerated desc

2. Network Lateral Movement

// Internal connections from compromised host to other internal hosts
Zeek_conn_CL
| where id_orig_h_s == "10.1.2.33"
| where local_resp_b == true  // connecting to internal hosts
| where id_resp_p_i in (445, 135, 139, 5985, 5986, 3389, 22)  // LM protocols
| summarize 
    conn_count = count(),
    first_seen = min(TimeGenerated),
    last_seen = max(TimeGenerated)
  by id_resp_h_s, id_resp_p_i
| order by last_seen desc

3. IOC Sweep Across Fleet

// Did any other host connect to the same C2 IP?
Zeek_conn_CL
| where id_resp_h_s == "185.220.101.9"
| where id_orig_h_s != "10.1.2.33"  // other hosts
| summarize host_list = make_set(id_orig_h_s) by id_resp_h_s

// Did any other host have svcupd.exe? (Velociraptor fleet hash hunt)
// Already covered by fleet hash query in M22 Lesson 2

Worked Example

Handoff failure vs. clean handoff — same finding, different outcomes

Finding: svcupd.exe beacon, active C2, LSASS CreateRemoteThread observed.

Bad handoff (2 sentences in Slack):

@ir-team Found a beacon on jsmith's laptop, looks like Cobalt Strike.
IP is 185.220.101.9. You should probably isolate it.

IR response:

Isolates the host without blocking C2 first → attacker sees connectivity drop → immediately destroys evidence on their server
Doesn’t know to check authentication logs → misses that jsmith authenticated to the DC 40 minutes before isolation
Doesn’t know about LSASS CreateRemoteThread → doesn’t force enterprise-wide password reset
6 hours later: attacker uses stolen domain admin credential to re-establish foothold on a different host

Clean handoff (structured ticket per template above):

IR response:

Blocks 185.220.101.9 at perimeter first (C2 cut, attacker doesn’t know why yet)
Checks authentication logs → finds jsmith → Domain Admin (step-up) → DC01 at 16:33 (40 min after LSASS dump)
Escalates to enterprise scope: LSASS dump + DC authentication = potential Golden Ticket territory
Forces NTLM hash reset (krbtgt × 2, all privileged accounts) based on LSASS finding in ticket
Forensic image already collected → IR can start immediately without returning to the hunter

Outcome difference: clean handoff prevents re-compromise; bad handoff causes it.

Retrieval Practice

An IR team receives a hunt handoff ticket with a confirmed beacon but no scope assessment or ATT&CK chain. They isolate the one host and close the case. The next day, the attacker re-establishes access via a second compromised host. What information was missing from the handoff that would have prevented this?

Reveal answer

The missing elements: (1) Scope assessment — the handoff didn't include lateral movement analysis (authentication logs from the compromised host to other internal hosts, internal network connections from the C2-connected IP). Had IR checked WinEvt 4624 for network logons originating from the victim host, they would have found the lateral movement to the second host. (2) Credential exposure analysis — if LSASS was accessed (Sysmon Event 8 or 10 targeting lsass.exe), those credentials must be treated as compromised. A credential sweep would have identified the compromised account used on the second host. (3) IOC fleet sweep — before closing the case, search all SIEM/network data for the C2 IP and payload hash. If the payload ran on a second host, it would appear in Sysmon or Zeek. The root cause: treating a hunt finding as a single-host incident without scope verification. Scope assessment must be part of every handoff, not an optional step.

Retrieval Practice

Why should C2 network blocking always be the FIRST containment step, before host isolation?

Reveal answer

C2 network blocking before host isolation prevents the attacker from detecting containment and destroying evidence. If the host is isolated first (network link dropped), the attacker observes the loss of their beacon and can immediately: (1) Delete malware from their C2 server, removing infrastructure IOCs. (2) Activate cleanup scripts on other compromised hosts (if they have secondary implants). (3) Exfiltrate remaining staged data from other hosts before those are also isolated. Network blocking at the perimeter (firewall rule or DNS sinkhole) cuts the attacker's visibility without the endpoint losing network connectivity — the host can still be accessed by IR via internal network for forensic collection. The attacker sees connectivity failures but cannot distinguish a network block from a transient outage — buying IR time to complete scope assessment and collect evidence before hosts are isolated. Exception: if the attacker has demonstrated active destructive action (ransomware encryption in progress), isolate immediately regardless of evidence collection concerns.