Chapter 2.3 Quiz - Network Forensics & Log Analysis

Quiz Mode - All answers are hidden under collapsible sections. Attempt each question before revealing the answer.

---

Question 1

During an incident, you discover the first IDS alert fired at 14:32:15 UTC. Reviewing NetFlow data, you find a 4.2 MB outbound upload from the compromised host to an external IP at 14:47:12 UTC. But the Zeek http.log shows an initial HTTP request to a malware distribution URL at 14:15:01 UTC - 17 minutes before the IDS alert. What does this timeline gap indicate, and what is the forensic significance?

Reveal Answer & Explanation

Answer: The 17-minute gap indicates the IDS alert was not triggered at initial compromise - it fired later, likely on a secondary behavior (e.g., C2 beacon pattern, known signature in the implant's traffic). The initial infection vector was already complete before detection.

Forensic significance:

1. Dwell time begins at 14:15:01, not 14:32:15. The true dwell time is 17 minutes longer than the IDS alert suggests. This matters for scope assessment - what did the attacker do in those 17 minutes?
2. The IDS signature missed the initial download. This is a detection gap. The malware download triggered no alert, suggesting either the payload was obfuscated, delivered over HTTPS (payload encrypted), or no matching signature existed.
3. Scope of investigation expands. Any actions the attacker took between 14:15:01 and 14:32:15 - credential harvesting, host enumeration, persistence mechanisms - must be reconstructed from non-IDS sources (Zeek conn.log, proxy logs, endpoint logs).

Reconstructing the gap:

# Pull all Zeek events from the compromised host between 14:15 and 14:32
cat conn.log dns.log http.log \
  | zeek-cut ts id.orig_h id.resp_h \
  | awk '$1 >= 1700057701 && $1 <= 1700058735 && $2 == "192.168.1.55"' \
  | sort -k1

This is why multi-source log correlation is mandatory - IDS alert timestamps are not the beginning of the story. The proxy log, in this case, provided the true T0. (T1566.001, T1071.001)

---

Question 2

You are analyzing Zeek conn.log and notice that host 192.168.4.12 has made 847 connections to 203.0.113.77:443 over the past 12 hours, with an average inter-connection interval of 60.3 seconds and a coefficient of variation of 0.04. What does this indicate, and what follow-up investigation steps would you take?

Reveal Answer & Explanation

Answer: A CV of 0.04 is extremely low - near-perfect periodicity. Human web browsing produces intervals with CV > 1.0; automated software timers produce CV approaching 0.0. This is a strong beacon signature, consistent with C2 implant check-in (T1071.001).

60-second interval is the default Cobalt Strike beacon sleep time. Combined with port 443, this is a high-confidence Cobalt Strike indicator.

Follow-up steps:

1. Check TLS certificate for the destination:

cat ssl.log \
  | zeek-cut ts id.orig_h id.resp_h server_name subject issuer validation_status ja3 \
  | awk '$2 == "192.168.4.12" && $3 == "203.0.113.77"'
# Look for: self-signed, mismatched SNI, short validity, JA3 matching known CS profile

2. Check JA3 against threat intel:

# Known Cobalt Strike default JA3: 51c64c77e60f3980eea90869b68c58a8
# CS with specific malleable profiles will differ
cat ssl.log | zeek-cut ja3 | sort | uniq -c | sort -rn

3. Check for initial dropper download prior to beaconing:

# What did 192.168.4.12 download in the hour before beaconing started?
cat http.log \
  | zeek-cut ts id.orig_h method host uri resp_body_len \
  | awk '$2 == "192.168.4.12" && $6 > 50000'

4. Check for lateral movement from this host:

# Has 192.168.4.12 made SMB (445) or WinRM (5985) connections to other internal hosts?
cat conn.log \
  | zeek-cut ts id.orig_h id.resp_h id.resp_p orig_bytes \
  | awk '$2 == "192.168.4.12" && ($4 == "445" || $4 == "5985") && $3 ~ /^192\.168/'

5. Calculate byte asymmetry: Cobalt Strike C2 sessions typically show small uploads (commands) and variable downloads (responses). Extremely small orig_bytes with moderate resp_bytes per session is consistent.

6. Isolate host and trigger incident response. Do not block the C2 channel immediately - monitor for a controlled period to understand the full scope of compromise before killing the channel (cutting C2 removes your visibility into attacker actions).

---

Question 3

An analyst exports Windows Security Event Log and finds 4624 (LogonType 3) events from WKSTN-047 authenticating to 14 different internal hosts within a 4-minute window at 02:17 AM, using the account corp\svcbackup. No 4768 (Kerberos TGT) events exist for this account in the same window, but 4776 (NTLM credential validation) events do. What attack technique does this represent? Which MITRE ATT&CK IDs apply, and what log entries would you look for to confirm?

Reveal Answer & Explanation

Answer: This is Pass-the-Hash (PtH) - T1550.002. The attacker has extracted the NTLM hash of corp\svcbackup from memory (likely via Mimikatz/lsass dump) and is replaying it directly for network authentication.

Why the absence of 4768 is the key indicator:

• Kerberos (the normal Windows authentication path) requires requesting a TGT (4768) before any resource access
• NTLM authentication (4776) does not use Kerberos - it's a challenge-response using the password hash directly
• A successful network logon (4624 Type 3) using NTLM (4776) with no prior 4768 from the same account = the account's hash was used without the cleartext password

ATT&CK IDs:

• T1003.001 - OS Credential Dumping: LSASS Memory (how the hash was obtained)
• T1550.002 - Use Alternate Authentication Material: Pass the Hash (the technique here)
• T1021.002 - Remote Services: SMB/Windows Admin Shares (the lateral movement method)

Confirmation queries:

# Find 4776 events for svcbackup with no corresponding 4768
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4776; StartTime=(Get-Date).AddHours(-1)} |
  Where-Object { $_.Properties[1].Value -eq 'svcbackup' } |
  Select-Object TimeCreated, @{N='Account';E={$_.Properties[1].Value}},
                             @{N='Workstation';E={$_.Properties[2].Value}},
                             @{N='ErrorCode';E={$_.Properties[3].Value}}

# Find 4624 Type 3 events for svcbackup
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} |
  Where-Object { $_.Properties[5].Value -eq 'svcbackup' -and $_.Properties[8].Value -eq 3 } |
  Select-Object TimeCreated, @{N='SrcIP';E={$_.Properties[18].Value}}

# Confirm no Kerberos TGT issued for svcbackup around the same time
# 4768 events appear on the Domain Controller's Security log
Get-WinEvent -ComputerName DC01 -FilterHashtable @{LogName='Security'; Id=4768} |
  Where-Object { $_.Properties[0].Value -eq 'svcbackup' } |
  Where-Object { $_.TimeCreated -gt '02:10' -and $_.TimeCreated -lt '02:25' }
# If this returns empty while 4776+4624 exist: PtH confirmed

Additional: was the hash dumped earlier? Look for Event 10 in Sysmon (process accessed lsass.exe) on WKSTN-047 in the hour before 02:17. Also look for suspicious processes spawned via Sysmon Event 1 (process create) - Mimikatz, procdump, or custom loaders.

---

Question 4

You are building a retention and collection strategy for a 5 Gbps sustained traffic environment (university network). Budget allows for approximately 20 TB of dedicated forensic storage. Sustained FPC at 5 Gbps would fill this storage in roughly 4-5 hours. What collection architecture would you design, and what evidence fidelity tradeoffs are you accepting?

Reveal Answer & Explanation

Answer: Full packet capture at 5 Gbps sustained is approximately 400-500 GB/hour after LZ4 compression. 20 TB = ~40-50 hours of full capture - useful for active incidents, not for historical investigation.

Recommended tiered architecture:

Tier 1 - Selective FPC (short retention, targeted):

- Capture only specific segments: DMZ, server VLAN, executive subnets
- Apply BPF filters to exclude bulk consumer traffic (video streaming, OS updates)
- Estimated reduction: 60-70% of traffic eliminated
- Storage at ~40% of line rate: ~160-200 GB/hr -> 20TB ~ 4 days on targeted segments

# Capture only traffic to/from server VLANs and DMZ
tcpdump -i eth0 -s 0 -w /data/fpc/capture-%Y%m%d%H%M.pcap \
  -G 3600 -C 5000 -W 96 \           # 96 files x 5 GB = 480 GB = 4 days at 5 GB/hr
  "net 10.0.1.0/24 or net 10.0.2.0/24 or net 172.16.0.0/24"

Tier 2 - Zeek full coverage (medium retention):

- Run Zeek on all interfaces at full line rate
- All protocol logs (conn, dns, http, ssl, files, smtp)
- Estimated volume: 2-4 GB/hr at 5 Gbps -> 20 TB = 200-400 days
- Contains app-layer semantics, file hashes, TLS fingerprints -- covers 80% of investigative questions

Tier 3 - NetFlow (long retention, all traffic):

- Sample 1:100 or export full flows from router/switch
- 50-100 MB/hr -> 20 TB = 2,000+ days
- Session-level visibility with no payload -- catches lateral movement, exfil volumes

Storage breakdown (20 TB example):

Tier	Allocation	Retention
FPC (targeted)	5 TB	~25 days (targeted segments only)
Zeek logs	10 TB	~100-200 days
NetFlow	3 TB	~1,000+ days
SIEM/auth/DNS logs	2 TB	~365 days

Evidence fidelity tradeoffs accepted:

• Non-targeted segment FPC is lost - file carving and session reconstruction unavailable for those hosts
• Attacks that exclusively use non-targeted segments may not have FPC evidence
• Zeek and NetFlow cover the gap with lower fidelity - you can confirm that a connection happened and how much data moved, but not what the payload contained

For compliance environments (PCI-DSS, HIPAA): ensure cardholder/PHI network segments are in the FPC-targeted tier. Exfiltration of a single record must be reconstructable - "we had flow data showing 500 KB left the segment" is insufficient if forensic specificity is required by your incident response SLA.