Day 3 of 5
⏱ ~60 minutes
SOC Operations in 5 Days — Day 3

Threat Hunting

Threat hunters proactively search for attackers who have evaded automated detection. Unlike reactive alert triage, hunting starts with a hypothesis and searches logs for evidence to confirm or deny it. Today covers hunting methodology and common hunt use cases.

The Threat Hunting Loop

Hunting follows a loop: (1) Create a hypothesis based on threat intelligence or ATT&CK techniques ('attacker is using PowerShell to download payloads'); (2) Investigate using SIEM queries, EDR data, or network logs; (3) Uncover new patterns — either confirm the hypothesis (escalate) or find nothing (refine and loop); (4) Inform and improve — create detection rules for anything found. Over time, good hunts turn into automated detections.

Hunting PowerShell Abuse

PowerShell is the attacker's favorite living-off-the-land tool. Hunting indicators: encoded commands (-EncodedCommand base64 parameter), download cradles (Net.WebClient, Invoke-Expression, IEX), AMSI bypass attempts, unusual parent processes (Word.exe spawning powershell.exe), and network connections from powershell.exe processes. Sysmon Event ID 1 (process creation) and Event ID 3 (network connection) are the primary data sources.

Hunting for Lateral Movement

Lateral movement leaves traces: unusual admin share access (Event ID 5140), remote service creation (Event ID 7045), WMI remote execution (Event ID 4648 with network logon), and Pass-the-Hash indicators (Event ID 4624 logon type 3 with NTLM authentication). Look for user accounts logging into machines they never normally access, especially outside business hours.

bash
# Splunk: hunt for encoded PowerShell commands
# index=windows EventCode=4104 
# | regex Message="(?i)(-enc|-encodedcommand|IEX|Invoke-Expression)"
# | stats count by host, user, Message
# | sort -count

# Elasticsearch KQL: PowerShell network connections
# process.name: "powershell.exe" AND network.direction: "outbound"
# AND NOT destination.ip: (10.0.0.0/8 OR 192.168.0.0/16)

# Zeek: hunt for DNS-based C2 (long query names)
zeek-cut query < dns.log | \
  awk 'length($0) > 50' | \
  sort | uniq -c | sort -rn | head -20

# Windows: find lateral movement with admin shares
# Event ID 5140 + specific shares
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=5140} | \
  Where-Object {$_.Message -match 'IPC\$|ADMIN\$|C\$'} | \
  Select-Object TimeCreated, Message | Format-List

# Sysmon: find Word spawning PowerShell
# index=sysmon EventCode=1 ParentImage=*WINWORD.EXE* Image=*powershell.exe*
💡
Document every hunt — even those that find nothing. A documented negative hunt means 'we looked for this and found no evidence.' This is valuable data for auditors and for repeating the hunt with better queries later.
📝 Day 3 Exercise
Run a PowerShell Hunt
  1. Generate some PowerShell encoded command events on your Windows VM: powershell -EncodedCommand [base64]
  2. Search for these events in your SIEM using Event ID 4104 (Script Block Logging)
  3. Enable Sysmon on the Windows VM using the SwiftOnSecurity config
  4. Run a download cradle (Invoke-WebRequest) and search for the Sysmon network connection event
  5. Write a detection rule that alerts on any powershell.exe process making outbound connections

Day 3 Summary

  • Threat hunting starts with a hypothesis and searches proactively for evidence
  • Successful hunts result in new detection rules to automate future identification
  • Sysmon event IDs 1 and 3 are the primary data sources for PowerShell hunts
  • Lateral movement leaves Event IDs 5140, 7045, 4624 type 3 traces
  • Document all hunts — negative results are also valuable intelligence
Challenge

Simulate a complete attack chain on your lab: PowerShell download cradle → payload execution → LSASS credential dump → lateral movement via PsExec. Then hunt for all four techniques in your SIEM and write detection rules for each.

Finished this lesson?