11.2 Host, Network, and Memory Forensics Triage

Host Forensics: Windows File System Internals and Metadata

When conducting endpoint investigations, host forensics provides the granular evidentiary foundation necessary to substantiate an intrusion. On Microsoft Windows platforms, the New Technology File System (NTFS) maintains deeply integrated metadata structures that log file system transactions, file creation timelines, and data record modifications.

NTFS File System Internals: $MFT, $LogFile, and $UsnJrnl

• Master File Table ($MFT): The structural backbone of NTFS. Every file and directory on an NTFS volume is allocated at least one 1024-byte record within the $MFT. Each record contains headers and specific attributes that store critical forensic metadata:
  • $STANDARD_INFORMATION ($SI): Contains primary file flags (read-only, hidden, system) and the standard MACB timestamps: Modified, Accessed, $MFT Modified (Entry Modified), and Born (Creation). Because standard user-space Win32 APIs (such as SetFileTime) permit modification of $SI timestamps, threat actors frequently alter these timestamps to blend malicious binaries into legitimate system directories—an anti-forensic technique known as timestomping.
  • $FILE_NAME ($FN): Contains the file name, namespace flags, parent directory record number, and a secondary set of MACB timestamps. $FN timestamps are generally updated through NTFS namespace operations rather than the common user-mode timestamp APIs used to alter $SI. Comparing $SI and $FN values can reveal an inconsistency worth investigating, but legitimate copy, move, rename, extraction, restore, and file-system behavior can also create differences; the pattern does not by itself prove timestomping.
  • Resident vs. Non-Resident Data: If a file's payload is smaller than approximately 700 bytes, NTFS stores the raw data directly within the $MFT record inside the $DATA attribute—known as resident data. Even if the file is deleted, its complete payload can be carved directly from the $MFT record until the record is reallocated.
• $LogFile: A circular transaction logging journal located in the volume root. NTFS logs all metadata changes (such as file creation, renaming, deletion, or security descriptor updates) to $LogFile before executing them, ensuring file system fault tolerance. Forensic parsing of $LogFile allows investigators to recover transient file operations that occurred immediately prior to an incident.
• $UsnJrnl (Update Sequence Number Journal): Located in $Extend\$UsnJrnl, specifically within the alternate data stream $J. It provides a bounded change journal for many file and directory changes on the volume, including timestamps and reason codes (e.g., USN_REASON_FILE_CREATE, USN_REASON_DATA_EXTEND, USN_REASON_FILE_DELETE). If the relevant records have not wrapped or been deleted, $UsnJrnl may preserve creation, rename, data-change, and deletion activity. It does not by itself prove process execution.

---

Windows Registry Forensics: Persistence and Execution Tracking

The Windows Registry serves as a centralized hierarchical database containing operating system configurations, user preferences, hardware details, and software settings. Registry data is organized into logical trees called hives, physically stored in specific files on disk:

• SYSTEM, SOFTWARE, SAM, SECURITY: Located in C:\Windows\System32\config\ (system-wide configurations).
• NTUSER.DAT: Located in C:\Users\<Username>\ (user-specific configurations and activity).
• UsrClass.dat: Located in C:\Users\<Username>\AppData\Local\Microsoft\Windows\ (user-specific shell and association data).

Primary Registry Investigation Locations

1. Autostart Run Keys (Persistence):
   • HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run and RunOnce
   • HKCU\Software\Microsoft\Windows\CurrentVersion\Run and RunOnce
   • HKLM\System\CurrentControlSet\Services (Malicious service installations)
   • Threat actors place payloads here to survive system reboots.
2. UserAssist (Execution Tracking):
   • Path: HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist\{GUID}\Count
   • Records GUI-based application executions launched via Windows Explorer. Value names are obfuscated using a simple ROT13 substitution cipher. Parsing UserAssist entries reveals the program name, total run count, and the last execution timestamp.
3. RecentDocs and OpenSavePidlMRU:
   • Paths: HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs and OpenSavePidlMRU
   • Tracks recently opened or saved-file references and dialog interactions. These records associate activity with a user profile but require corroboration before attributing a specific human action.
4. Shellbags (Folder Browsing Reconstruction):
   • Path: UsrClass.dat\Local Settings\Software\Microsoft\Windows\Shell\Bags and BagMRU
   • Designed to store user view preferences (icon size, window position, sort order) for folders accessed via Windows Explorer. Forensically, Shellbags can corroborate that Windows Explorer represented particular directory paths, including paths on removable media or network shares. They do not alone identify the human who navigated or prove that a file was opened.
5. Shimcache (AppCompatCache):
   • Path: HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache
   • Maintained by the Application Compatibility subsystem to identify programs that may require compatibility shims. Fields and interpretation vary by Windows version, but Shimcache can retain file paths and metadata useful for showing that binaries were present or considered by the compatibility subsystem. Presence is not universal proof of execution.
6. Amcache.hve:
   • Path: C:\Windows\AppCompat\Programs\Amcache.hve
   • A registry hive populated by application-compatibility and inventory mechanisms. Depending on the Windows version and entry type, Amcache can expose paths, product metadata, file sizes, timestamps, and SHA-1-related values useful for intelligence lookups. An entry is contextual evidence, not universal proof that a user executed the file.

Windows Prefetch Files (*.pf)

Located in C:\Windows\Prefetch\, Prefetch files are created by the Windows Cache Manager to optimize application launch times by pre-loading memory pages. Prefetch files follow the naming convention [EXECUTABLE_NAME]-[HASH].pf (where the 8-character hash is derived from the binary's file path). Prefetch files can provide strong corroborating evidence that Windows prepared an executable for launch, but analysts should correlate them with process, event, registry, file-system, and user-context evidence. They contain:

• The executable binary name and path.
• Total run count.
• The most recent execution timestamp (in Windows 8, 10, and 11, up to the last eight execution timestamps are preserved).
• Referenced file and volume information used by the prefetcher; interpretation varies by Windows version and workload.

Windows Event Logs (.evtx)

Stored in C:\Windows\System32\winevt\Logs\, event logs record structured XML-based auditing telemetry. Key event IDs include:

• Security.evtx:
  • Event ID 4624: Successful Logon (Logon Type 2 = Interactive console, Type 3 = Network share/SMB, Type 10 = Remote Desktop / RDP).
  • Event ID 4625: Failed Logon Attempt (crucial for detecting brute-force or password-spraying attacks).
  • Event ID 4720: A local user account was created.
  • Event ID 4672: Special privileges assigned to a new logon (administrative elevation).
• System.evtx:
  • Event ID 7045: A new service was installed in the system (classic persistence and lateral movement artifact, such as PsExec or cobalt strike service installation).
• Sysmon.evtx (Microsoft-Windows-Sysmon/Operational):
  • Event ID 1: Process Creation (logs parent-child process relationships, complete command-line strings, and SHA-256 hashes).
  • Event ID 3: Network Connection (links process IDs to destination IP addresses and ports).
  • Event ID 7: Image Loaded (detects DLL hijacking and loaded modules).
  • Event ID 8: CreateRemoteThread (detects cross-process injection).
  • Event ID 10: ProcessAccess (detects memory scraping of lsass.exe via Mimikatz).

Windows Forensic Artifacts Matrix

---

Linux Forensic Artifacts

Host investigations on Linux servers require parsing plain-text logs, binary accounting databases, user session records, and scheduling directories:

• Authentication and System Logs:
  • /var/log/auth.log (Debian/Ubuntu) and /var/log/secure (RHEL/CentOS): Records authentication attempts, sudo elevations, SSH logins, and PAM transactions.
  • /var/log/audit/audit.log: Generated by the Linux Audit daemon (auditd); records granular kernel system calls, file access, command execution, and network connections.
• User Session History & Evasion:
  • ~/.bash_history: Records command-line interactions executed by users. Threat actors attempt to evade logging by running unset HISTFILE, executing commands preceded by a leading space (if HISTCONTROL=ignorespace is configured), or redirecting history to /dev/null (export HISTFILE=/dev/null). Investigators inspect .bash_profile and .bashrc for unauthorized modifications.
• Login Accounting Files:
  • /var/run/utmp: Maintains current active user sessions (queried via who or w).
  • /var/log/wtmp: Maintains historical login and logout records (queried via last).
  • /var/log/btmp: Maintains failed login attempts (queried via lastb).
• Persistence Mechanisms:
  • Cron Jobs: /etc/crontab, /etc/cron.d/*, /etc/cron.daily/, and user spool directories /var/spool/cron/crontabs/.
  • Systemd Services and Timers: Custom unit files located in /etc/systemd/system/*.service and /etc/systemd/system/*.timer.
  • SSH Authorized Keys: ~/.ssh/authorized_keys (backdoor public key additions).

---

Memory Forensics: Frameworks and Volatility 3 Analysis

Memory forensics gives investigators a snapshot of volatile operating-system state at acquisition time and can reveal in-memory shellcode, process hollowing, reflective loading, credentials, sockets, and rootkit artifacts that disk evidence may miss. Acquisition itself changes some state, and conclusions should be corroborated with endpoint, network, and disk evidence.

Acquisition Tools

• WinPmem: Open-source physical memory acquisition driver for Windows systems.
• DumpIt: High-speed live memory acquisition utility developed by Comae / Magnet Forensics.
• LiME (Linux Memory Extractor): A Loadable Kernel Module (LKM) designed to capture volatile memory from Linux hosts while minimizing user-space contamination.

Volatility 3 Framework

The Volatility 3 framework is the industry-standard memory analysis engine. Unlike Volatility 2, which required manual profile specification (e.g., --profile=Win10x64_19041), Volatility 3 utilizes intermediate symbol tables (JSON files) downloaded dynamically to inspect Windows, Linux, and macOS memory images without rigid profile constraints.

Volatility 3 Plugin Reference Table

Unlinking Detection: windows.pslist vs. windows.psscan

In Windows, the kernel maintains an executive process structure (EPROCESS) for every active process. These structures are joined sequentially via a circular, doubly-linked list called ActiveProcessLinks. When a user runs Task Manager or an analyst runs windows.pslist, the tool traverses this linked list.

Advanced rootkits execute Direct Kernel Object Manipulation (DKOM) to unlink a malicious process's EPROCESS block by adjusting the forward and backward pointers (Flink and Blink) of neighboring structures. The malicious process continues to execute normally because the Windows CPU thread scheduler operates on KTHREAD blocks rather than the process list. The process can disappear from views that rely on the active process list, including windows.pslist, while other structures or telemetry may still expose it.

To counter this, windows.psscan ignores ActiveProcessLinks entirely. It scans raw memory byte-by-byte for the unique 4-byte pool tag identifier associated with EPROCESS structures (Proc in older versions or pool allocations matching process templates). A process-like structure found by windows.psscan but absent from windows.pslist is a DKOM lead. The analyst must distinguish an actively hidden process from terminated-process remnants, stale or reused pools, parser issues, and acquisition artifacts using timestamps, threads, handles, VADs, sockets, and other evidence.

Injected Code Detection: windows.malfind

windows.malfind inspects the Virtual Address Descriptor (VAD) tree of each process. Legitimate Windows software rarely requests memory pages with simultaneous Read, Write, and Execute (PAGE_EXECUTE_READWRITE or RWX) permissions due to Data Execution Prevention (DEP) protections. Threat actors injecting shellcode or reflective DLLs must allocate RWX memory (via VirtualAlloc or NtAllocateVirtualMemory) to write and then execute payload bytes. malfind flags RWX regions that contain code not backed by a legitimate file on disk, displaying the memory address, VAD protection flags, and a hex/ASCII disassembly preview showing typical assembly instructions (e.g., 55 8B EC function prologues or 4D 5A MZ headers).

Step-by-Step Memory Investigation Workflow

Step 1: Acquisition & Verification
  └── Capture physical memory via WinPmem/DumpIt --> Compute SHA-256 hash immediately.
Step 2: Process Lineage & Anomaly Triage
  └── Run windows.pslist & windows.pstree --> Validate process parents (e.g., explorer.exe, services.exe).
Step 3: Rootkit & DKOM Unlinking Verification
  └── Run windows.psscan --> Diff psscan vs pslist output to uncover unlinked processes.
Step 4: Memory Injection & Shellcode Scanning
  └── Run windows.malfind --> Identify VAD allocations with PAGE_EXECUTE_READWRITE permissions.
Step 5: Network Socket & C2 Correlation
  └── Run windows.netscan --> Map flagged suspicious PIDs to remote external IP connections.
Step 6: Payload Extraction & Carving
  └── Run windows.dumpfiles --pid <Suspicious_PID> --> Export memory-resident binary to disk for reverse engineering.

---

Network Forensics: PCAP Analysis with Wireshark and Tshark

Network forensics involves capturing, recording, and analyzing network events to discover the source of security attacks. While host and memory forensics detail what happened on a specific endpoint, network forensics provides an objective, external record of communications between hosts.

Full Packet Capture (PCAP) vs. NetFlow Telemetry

• NetFlow / IPFIX: Summarizes network conversations (source/destination IP, ports, protocol, packet/byte counts, timestamps). Highly scalable for long-term archiving, but lacks payload data.
• Full Packet Capture (PCAP): Records every bit and byte traversing the network cable, including packet headers and complete application payloads. Essential for extracting malware binaries, recovering credentials, and verifying data exfiltration.

Tshark Command-Line Dissection

In enterprise SOCs, multi-gigabyte PCAP files overwhelm graphical interfaces. Analysts utilize tshark (the command-line interface for Wireshark) for high-speed automated triage:

# 1. Extract all HTTP requests, virtual hosts, and URIs:
tshark -r capture.pcap -Y "http.request" -T fields -e frame.time -e ip.src -e ip.dst -e http.host -e http.request.uri

# 2. Identify all DNS queries and resolved IPs:
tshark -r capture.pcap -Y "dns.flags.response == 1" -T fields -e ip.src -e dns.qry.name -e dns.a

# 3. Dissect cleartext HTTP POST traffic for credential harvesting:
tshark -r capture.pcap -Y "http.request.method == \"POST\"" -T fields -e ip.src -e ip.dst -e http.file_data

Reconstructing TCP Streams and Carving File Transfers

Wireshark allows analysts to reassemble fragmented TCP segments into complete Layer 7 application sessions via Follow TCP Stream. To extract transferred payloads:

1. In Wireshark, navigate to File -> Export Objects -> HTTP... (or SMB...).
2. The interface lists all files transmitted across the unencrypted protocol, displaying the file name, content type, and size.
3. Selecting Save All extracts the files directly to disk for immediate cryptographic hashing and malware analysis.

Detecting C2 Beaconing Patterns

Malware command-and-control (C2) agents communicate with external infrastructure using periodic check-in signals called beacons. Analysts identify beaconing through three network traffic characteristics:

1. Temporal Regularity (Inter-Arrival Time): Automated scripts beacon at fixed intervals (e.g., exactly every 60 seconds). Analysts plot packet arrival deltas (frame.time_delta). Threat actors introduce jitter (e.g., 20% randomization: 48s, 64s, 52s) to evade static rules; statistical analysis calculates the standard deviation of arrival times to identify low-variance clusters.
2. Payload Size Uniformity: Repeated HTTP GET requests exhibiting identical byte lengths (e.g., exactly 248 bytes outbound, 42 bytes inbound) indicate automated polling.
3. DNS Tunneling & DGA Queries: Threat actors encode data inside DNS subdomains (e.g., a7x9f1k.c2.attacker.com). Detecting high Shannon entropy in DNS query strings or large volumes of TXT record queries isolates active exfiltration channels.

---

Investigating Application, Email, and Insider Incidents

The CSA blueprint separately calls for investigation of application, email, and insider incidents. These cases reuse forensic principles but require different authoritative records.

Application-Security Investigation

Preserve the relevant web, API-gateway, Web Application Firewall (WAF), authentication, application, database, and cloud audit logs with their schemas and time settings. Correlate a request ID or trace ID from the edge through the application and database layers. Determine whether an exploit string merely reached the service or caused an unauthorized action: a suspicious HTTP request alone does not prove code execution. Host process creation, unexpected child processes, database changes, new files, outbound connections, or altered identities can establish impact. Record the application version, deployment hash, configuration, container image, and any emergency change made during containment.

Email-Security Investigation

Preserve the raw RFC 5322 message, gateway and sandbox verdicts, cloud message trace, authentication results, attachment hashes, rewritten URLs, mailbox-audit events, and recipient sign-in/device telemetry. Establish delivery and interaction separately: delivery does not prove a click, and a click does not prove credential entry or code execution. For Business Email Compromise, inspect inbox and forwarding rules, delegates, OAuth grants, sent/deleted items, payment-thread changes, sign-in risk, and session activity. Scope other recipients by stable message identifiers and hashes, not only by a mutable subject line.

Insider-Incident Investigation

Coordinate with legal, privacy, Human Resources, and management before broad collection because monitoring authority and employee expectations vary by jurisdiction and policy. Build a timeline from identity and privileged-access logs, file and database access, Data Loss Prevention (DLP), removable-media events, print activity, cloud sharing, source-code or collaboration systems, and approved business duties. Preserve exculpatory as well as incriminating evidence. A large transfer may be a legitimate backup or job function; intent should not be inferred from volume alone. Maintain need-to-know access, minimize unrelated personal data, and document collection scope and authorization.