Skip to main content

Chapter 4.3 Quiz - Incident Response & Digital Forensics

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

Question 1

You acquire memory from a suspected compromised Windows host and run Volatility's malfind plugin. It returns a result for svchost.exe (PID 1234) showing a memory region at address 0x1a0000 with permissions PAGE_EXECUTE_READWRITE and the first bytes 4D 5A 90 00. What does this indicate, and what are the next three investigative steps?

Reveal Answer

Answer: This indicates reflective PE injection into svchost.exe.

Explanation:

  • PAGE_EXECUTE_READWRITE (RWX): Memory that is simultaneously executable, readable, and writable is a strong indicator of injected code. Legitimate code sections in properly compiled executables are either RX (execute only) or RW (data), never RWX simultaneously.
  • 4D 5A 90 00: This is the MZ header - the DOS signature of a Windows Portable Executable (PE) file. A PE file found in the heap/stack region of a running process (not in a mapped image section) means a full executable was injected into the process memory and is executing from there - fileless malware with no disk artifact.

Next three investigative steps:

Step 1 - Dump the injected PE for analysis

python3 vol.py -f memory.lime \
  windows.memmap \
  --pid 1234 \
  --dump
# Produces: pid.1234.dmp

# Carve the MZ/PE from the dump starting at the identified offset
python3 -c "
with open('pid.1234.dmp', 'rb') as f:
    data = f.read()
mz_offset = data.find(b'MZ')
with open('/evidence/injected_pe.exe', 'wb') as f:
    f.write(data[mz_offset:mz_offset+10485760])  # Carve up to 10MB
"
# Submit to VirusTotal / run through YARA / static analysis with strings
strings /evidence/injected_pe.exe | grep -E "http|cmd|powershell|inject"

Step 2 - Identify the injection source (parent process chain)

python3 vol.py -f memory.lime windows.pstree
# Find PID 1234 (svchost) and its parent
# svchost.exe should ALWAYS be a child of services.exe (PID ~680)
# If parent is powershell.exe, cmd.exe, or any non-services.exe - malicious launcher

python3 vol.py -f memory.lime windows.cmdline --pid 1234
# What command line was used to start this svchost? Non-standard arguments = injector

Step 3 - Extract network connections from the injected process

python3 vol.py -f memory.lime windows.netstat
# Filter for PID 1234 - what external IPs is it connected to?
# These are C2 infrastructure - extract IPs for threat intel, firewall blocks,
# and PCAP correlation

MITRE ATT&CK: T1055.002 (Process Injection: Portable Executable Injection), T1055 (Process Injection)

Question 2

During IR, you find that the initial compromise occurred 3 weeks ago but was only detected today. The attacker has been present in the environment for 21 days. List the five most important forensic artifacts to collect, in priority order, and explain what each reveals about the 21-day dwell period.

Reveal Answer

Answer:

Priority 1 - Memory dumps of all likely compromised hosts (collect immediately)

Memory is volatile - rebooting destroys it. After 21 days, the attacker likely has persistent footholds, but active C2 sessions, injected shellcode, cached credentials, and decrypted configuration data exist only in RAM.

# Capture before any containment action that might trigger reboot
# For each likely compromised host:
sudo insmod lime.ko "path=tcp:4444 format=lime"
# Reveals: active C2 connections, injected code, credentials in LSASS memory

Priority 2 - SIEM logs for the full 21-day window (from central store)

The SIEM already has the data - extract the complete timeline for all affected entities. This reconstructs the entire kill chain without touching potentially-compromised endpoints.

# Elastic: export full 21-day log window for affected hosts
curl -X GET "https://elasticsearch:9200/logs-*/_search" \
  -d '{"query":{"bool":{"must":[
    {"range":{"@timestamp":{"gte":"now-21d"}}},
    {"terms":{"host.name":["WORKSTATION-01","DC01","FILESERVER"]}}
  ]}},"size":10000}'
# Reveals: complete attacker TTP timeline, all accounts touched, all hosts accessed

Priority 3 - Active Directory audit logs + NTDS.dit (if DC was accessed)

21 days is long enough for the attacker to have created backdoor accounts, modified group memberships, or performed DCSync. AD logs and NTDS.dit reveal every account change.

# Export NTDS.dit (offline - mount DC image)
# Compare current AD state against backup from before compromise:
# - New accounts created (compare objectWhenCreated timestamps)
# - Group membership changes (Event 4728/4732)
# - AdminSDHolder modifications (stealth privilege persistence)

Priority 4 - Firewall/proxy logs for all C2 infrastructure identification

21 days of C2 traffic in firewall/proxy logs reveals all external infrastructure the attacker used. Essential for: determining data exfiltration volume, identifying all C2 domains/IPs for blocking, and understanding the full scope of outbound communication.

# Pull all unique external destinations for compromised hosts over 21 days
# Splunk:
index=firewall src_ip IN (compromised_host_list)
| stats sum(bytes_out) as total_out by dest_ip, dest_port
| sort - total_out
| head 50
# Reveals: C2 IPs (repeated connections), data exfil destinations (high byte count)

Priority 5 - Disk images of confirmed pivot points and initial compromise host

The initial compromise host has the oldest attacker artifacts - the dropper, the original exploit, the first persistence mechanism. Disk forensics with Plaso creates a definitive timeline of attacker activity from day 1.

# Timeline the initial compromise host
log2timeline.py --storage-file /evidence/host01.plaso /mnt/host01_image/
psort.py -o l2tcsv -w /evidence/host01_timeline.csv /evidence/host01.plaso
# Reveals: exact initial access method, tools dropped, persistence established,
#          lateral movement timestamps

MITRE ATT&CK context: Long dwell time is particularly associated with APT actors. The 21-day window requires full scope determination - assume all Domain Admin accounts and all servers the attacker could reach are compromised until forensically cleared.

Question 3

A Volatility pstree output shows cmd.exe (PID 3412) as a child of svchost.exe (PID 2100). svchost.exe itself has services.exe as parent. Explain why this process relationship is suspicious, what specific persistence or execution technique it suggests, and the two commands to investigate further.

Reveal Answer

Answer: cmd.exe as a child of svchost.exe is suspicious because svchost.exe hosts Windows services - it runs service DLLs, not interactive command shells. Legitimate svchost.exe processes never spawn cmd.exe under normal operating conditions.

What technique this suggests:

This pattern is characteristic of malicious service execution (T1543.003) or WMI command execution (T1047). The attacker either:

  1. Installed a malicious service that, when started by services.exe, runs svchost.exe which executes a command shell - this is the psexec pattern (creates a PSEXECSVC service that spawns cmd.exe)

  2. WMI process creation via Win32_Process.Create() - WMI runs under svchost.exe (hosting the WMI service) and spawns child processes from there

The parent svchost.exe hosting legitimate services (PID 2100 with parent services.exe) is normal. The child cmd.exe is the anomaly.

Two investigative commands:

# Command 1 - Get the full command line of both processes
python3 vol.py -f memory.lime windows.cmdline \
  --pid 2100     # What service is this svchost instance hosting?
# svchost.exe -k netsvcs - hosts many services; check which DLLs loaded
# svchost.exe -k WbemSvc - WMI service - strongly suggests WMI execution
# svchost.exe -k secsvcs - Security Center - unusual for cmd.exe child

python3 vol.py -f memory.lime windows.cmdline \
  --pid 3412     # What command is cmd.exe running?
# cmd.exe /c net user hacker /add   - account creation
# cmd.exe /c powershell -enc ...    - PowerShell stage 2
# Reveals the actual attacker command executed

# Command 2 - Check DLLs loaded by the parent svchost (confirm which service)
python3 vol.py -f memory.lime windows.dlllist \
  --pid 2100
# Look for: unusual DLLs from temp directories, recently modified DLLs,
# DLLs without Microsoft signatures
# A malicious service DLL shows up here alongside legitimate ones

Correlate with Event ID 7045 (new service installed) in the Security event log - if a service was created recently, its name and binary path will be there.

MITRE ATT&CK: T1543.003 (Create or Modify System Process: Windows Service), T1047 (Windows Management Instrumentation)

Question 4

During forensic analysis, you find that a file on the compromised host has a $STANDARD_INFORMATION creation timestamp of 2024-01-15 but its $FILE_NAME creation timestamp is 2023-08-03. What does this discrepancy indicate, and how does it affect your timeline analysis? What tool detects this automatically?

Reveal Answer

Answer: This discrepancy indicates timestomping (T1070.006) - a defense evasion technique where an attacker modifies file timestamps to make malicious files appear older than they are, or to blend in with legitimate files.

Technical explanation:

NTFS maintains timestamps in two separate attribute structures per file:

  • $STANDARD_INFORMATION (SI): The timestamps shown by Windows Explorer, dir, ls. Easily modified by any application using standard API calls (SetFileTime()). This is what attackers manipulate.
  • $FILE_NAME (FN): Timestamps maintained by the NTFS kernel driver itself, updated when the MFT record is modified. These are much harder to modify without kernel access or specialized tools.

When $SI timestamps predate $FN timestamps, it is impossible - $FN is set at file creation and the file cannot have been created in the file system before its own MFT record existed. This is a forensic impossibility that proves manipulation.

Interpretation in this case:

  • $FN creation = 2023-08-03 - The file was actually placed on the file system on August 3, 2023
  • $SI creation = 2024-01-15 - An attacker changed the visible timestamp to January 15, 2024 to hide its true age

More commonly, attackers change $SI to an older date to make a recently dropped tool look like it has been there for years. A $SI timestamp older than $FN (file placed years before it was "created") is the classic timestomping indicator.

Impact on timeline analysis: The $SI timestamps cannot be trusted for affected files - they do not represent actual file system activity. Use $FN timestamps for the forensic timeline, as these are ground truth.

Automated detection tool:

# analyzeMFT - detects $SI/$FN timestamp discrepancies automatically
pip install analyzeMFT

analyzeMFT.py \
  -f /mnt/evidence/\$MFT \
  -o /tmp/mft_analysis.csv \
  -a                                  # -a: anomaly detection (timestomping)

# Output includes a "Possible Timestomp" flag column
# Filter for anomalies:
grep "Timestomp" /tmp/mft_analysis.csv | head -20

# Manual check with TSK:
istat -o 2048 /evidence/sda.img INODE_NUMBER
# Compare timestamps in SI vs FN attribute blocks

MITRE ATT&CK: T1070.006 (Indicator Removal: Timestomp) - this is specifically designed to defeat timestamp-based forensic analysis and is a strong indicator of a sophisticated attacker who anticipated forensic investigation.

End of Quiz 4.3 - Incident Response & Digital Forensics