Kernel Architecture & OS Internals Questions

Approach / Scope Clarification

• Objective: acquire all relevant evidence without altering volatility, attempt key recovery, evaluate legal compulsion, and document findings when decryption fails.
• Constraints: multiple devices/cloud, plausible deniability, possible hidden volumes, chain-of-custody and legal limits.

Acquisition strategy

1. Triage & preserve volatile evidence first
   • Live capture of RAM (trusted tools on write-protected media; e.g., Belkasoft Live RAM, LiME) from powered-on hosts; capture hibernation/swap files, pagefile.
   • Acquire system metadata: running processes, open handles, mounted volumes, crypto daemon logs.
2. For powered-off devices
   • Create forensic images (write-blockers) of disks, removable media, and any attached storage.
   • Collect full disk images of embedded controllers (eMMC), mobile backups, snapshots from cloud providers via API with preservation requests.
3. Cloud & backup collection
   • Preserve cloud snapshots, object metadata, version histories, bucket ACLs, timestamps, and backup logs; request ESI/subpoena when needed.

Key-recovery techniques

• Memory analysis: search for VeraCrypt/LUKS key schedules, passphrases, keyslots, header remnants, and mounted volume headers using volatility/rekall and yara rules.
• Hibernation/swap: carve for key material and passphrases; extract LUKS header offsets, candidate keyfiles.
• Keyfiles & artifacts: recover deleted keyfiles, SSH agent sockets, cached credentials, browser-stored secrets, TPM/clevis bindings, systemd-cryptsetup configs.
• Header reconstruction: locate and validate LUKS headers or VeraCrypt headers across images/backups; attempt header rescue from backups.
• Brute-force / targeted cracking: use GPU-based tools (hashcat) with recovered salts/headers; prioritize passphrase lists from user documents, metadata, company context.
• Hidden volumes: be cautious—avoid writing to suspected containers; document plausible deniability indicators.

Legal & procedural

• Coordinate with legal counsel to determine compelled-decryption viability (jurisdictional privilege and testimonial compulsion rules).
• Where applicable, obtain search warrants, preservation orders, and subpoenas for cloud providers; use court orders to compel decryption but evaluate Fifth Amendment/privilege defenses and consult prosecutors.
• If compelled decryption is not permitted, seek encryption status orders (e.g., require execution of keys or disclosure of key locations).

When decryption fails

• Document exhaustive steps tried, timestamps, tool versions, checksums, and hashes of collected images/headers.
• Produce a forensic report detailing acquisition, analysis, chain-of-custody, indicators of plausible deniability, and likelihood estimates (e.g., missing header vs. strong passphrase).
• Preserve all artefacts for reanalysis; recommend legal/regulatory actions and next steps (targeted interviews, service provider records, endpoint EDR telemetry).

Outcome metrics & lessons

• Record recovered artefacts count, successful key recoveries, time-to-acquisition, and legal instruments obtained.
• Recommend policy improvements: centralized key escrow, backup of headers, endpoint memory acquisition at seizure.

Overview / context
An MFT entry (usually 1, 2, or 4 KB) is the NTFS per‑file metadata record. For a forensic examiner it’s the primary source for timestamps, allocation, and data residency — critical when reconstructing events or proving tampering.

MFT header

• Signature "FILE", fixup array (to repair torn writes), Update Sequence Number (USN).
• Fields: MFT record number, sequence number (seq), link count, flags (in use, directory), offset to first attribute.
• Forensics note: corrupted or mismatched fixup/USN indicates partial writes or deliberate tampering.

Common attribute types

• STANDARD_INFORMATION (0x10): timestamps (Creation, MFT modified, Modified, Access), permissions, flags. Source of timeline evidence.
• FILE_NAME (0x30): parent MFT ref, filename (NTFS Unicode), allocated size, real size, timestamps (often duplicate of STANDARD_INFORMATION but with different update semantics) — useful to link hard/soft links and recover names after deletion.
• DATA (0x80): file content. Can be default unnamed stream or named alternate data streams (ADS).

Resident vs non‑resident

• Resident attributes are stored inside the MFT record (small files/metadata). Fast to read; deletion may immediately remove content from MFT.
• Non‑resident attributes store pointers to clusters — the attribute header contains starting VCN/LCN mapping information and a runlist. Forensics: deleted non‑resident data often remains on disk until overwritten.

Attribute runlists

• Runlist = sequence of (length, offset) encoded pairs (VCN runs). Offsets are relative and use variable-length integers.
• Interpreting runlists reconstructs LCNs to read file content. Corrupted or manipulated runlists can indicate tampering; examining gap patterns helps identify slack space or hidden data.

Sequence numbers and MFT record numbers

• MFT reference: 48‑bit value = 40‑bit MFT record number + 16‑bit sequence number.
• Sequence number increments each time an MFT record is reused. When file deleted and record reused, sequence changes.
• Forensics usage:
  • Verify that a quoted MFT ref matches current sequence; mismatch implies referencing a stale/deleted file instance.
  • Track reuse: if timestamps or attributes point to older events but sequence advanced, evidence may be from a previous file occupant.
  • Detect tampering: inconsistent sequence numbers across artifacts (USN journal, $MFT, $LogFile) suggest record replacement or rollback.

Practical steps for examiners

• Parse MFT header and attributes with validated fixup handling.
• Compare STANDARD_INFORMATION vs FILE_NAME timestamps for anomalies.
• Parse runlists to reconstruct non‑resident DATA and ADS; carve clusters if runlist missing.
• Cross‑reference MFT record/sequence with $UsnJrnl and $LogFile to detect reuse or covert modification; document chain-of-custody and tool outputs for court.

Compare containerization vs full virtualization

• Full virtualization (KVM, VMware): each VM runs a separate guest OS on virtualized hardware; strong isolation boundaries, separate kernels, persistent disk images — forensic workflows mirror physical hosts (acquire VM disk, memory, hypervisor logs).
• Containerization (Docker, LXC): containers share the host kernel; lightweight namespaces and cgroups provide process isolation but weaker kernel-level separation. Filesystems often use overlay/union layers; containers are intended to be ephemeral and orchestrated at scale (Kubernetes).

Three forensic challenges unique to containers

1. Evidence volatility and ephemerality

   • Containers are short-lived; processes, logs, and in-memory state disappear when a container is destroyed. Investigators must capture volatile data quickly (memory dumps, live process lists, network captures) from the host and orchestration layer.

2. Shared-kernel contamination and attribution difficulties

   • Since containers share the host kernel, artifacts (syscalls, kernel memory structures) are intermixed. Malicious activity in a container can affect host-level state or other containers, complicating which container caused specific kernel-level evidence. Correlate container IDs, namespaces, PID maps and auditd/tracing data from the host to attribute actions.

3. Overlay/union filesystem and persistence ambiguity

   • Union filesystems (overlayfs, AUFS) present layered fileviews: lower (image) and upper (container writable) layers. Deleted or modified files may only exist in upper layers; forensic imaging of host disk must reconstruct layers and map them to container lifecycles. Image-based evidence may not contain runtime changes if only the base image is preserved.

Practical collection guidance

• Prioritize host-level captures: kernel logs, containerd/docker daemon logs, orchestration control-plane logs, and host memory.
• Capture container namespaces (mount, pid, net) and mapping to cgroups and container IDs.
• Preserve overlay layers: copy upperdir and workdir for each container; document image IDs and timestamps.
• Use auditd, eBPF tracing, and network packet captures for attribution when kernel-level evidence is necessary.

These challenges require rapid live collection, cross-correlation between host and container artifacts, and careful reconstruction of overlay layers to sustain forensic integrity and legal admissibility.

Compare approaches (brief)

• Logical file copy: copies files/metadata via OS APIs (rsync, tar). Fast, low impact, preserves filenames/ACLs but may miss deleted/unallocated data and slack space — weaker for complete forensic reproducibility.
• File‑level imaging: creates forensic container of a filesystem (tools that walk FS and store metadata). Good balance: captures file metadata and can include hashes; still misses unallocated space.
• Full‑disk bitstream imaging: bit-for-bit copy (dd, dc3dd, FTK Imager). Highest evidentiary completeness (including MBR, slack, deleted data) and strongest defensibility, but expensive and risky on live systems (IO, possible state changes).

Recommended strategy for a live Linux server (balance integrity, uptime, defensibility)

1. Prepare: document scope, legal authority, and impact; notify stakeholders.
2. Capture volatile data first:
   • Memory acquisition with LiME (Linux Memory Extractor) into an evidence container.
   • Active network connections with netstat/ss and tcpdump (pcap).
3. Minimize live changes: use LVM snapshot or filesystem snapshot (lvcreate --snapshot or filesystem-specific) to create a point-in-time consistent image without taking server offline.
4. From the snapshot (not the live volume), perform a bitstream image of relevant devices/partitions using a forensically sound tool and output to EWF or split files:

# create SHA256 hashed dd via dc3dd and write to ewf (example)
dc3dd if=/dev/mapper/vg0-snap of=/mnt/forensic/image.raw hash=sha256 hashlog=/mnt/forensic/image.sha
ewfacquire /mnt/forensic/image.raw /mnt/forensic/image.E01

5. If snapshot not possible, perform targeted file‑level copies of high‑value data (configs, logs, databases) with metadata and hashing (rsync --archive --xattrs, record mtimes) and note limitations.
6. Compute and record hashes immediately after acquisition:

sha256sum /mnt/forensic/image.E01 > image.E01.sha256
find /srv -type f -exec sha256sum {} \; > file_hashes.sha256

7. Validate hashes after transfer.

Chain-of-custody practices

• Record: date/time, case ID, reason, legal authorization, system identifiers (MAC, hostname, serial), collector name, tool/version, checksums, and exact commands used.
• Evidence labeling: unique IDs on storage media, write-protect hardware where possible, seal, and sign.
• Access log: log every transfer, access, and analyst with timestamps; retain originals (images) and work on copies.
• Storage: encrypted, access-controlled evidence vault; retain hash and chain logs in case file.
• Legal defensibility: use standardized, industry-accepted tools; preserve forensic reads (use snapshots/write-blockers when possible); produce reproducible command logs and hash validations for court.

This approach captures volatile and persistent evidence with minimal downtime, preserves point‑in‑time integrity via snapshots, and provides a documented, hash-verified chain-of-custody suitable for legal proceedings.

Initial priorities

• Preserve chain of custody, isolate host from network (if live) and document timestamps.
• Collect volatile memory first, then disk images.

Volatile collection

• Use WinPmem or DumpIt to acquire full RAM (E01 or raw) and copy pagefile. Record hashes and acquisition logs.
• Optionally use procdump to dump live svchost.exe if process stable.

Memory analysis (tools & steps)

• Volatility/Volatility3 and Rekall:
  • pslist/psscan to validate process existence and PID/PPID anomalies.
  • malfind to detect injected code: RWX pages, hidden memory regions, suspicious strings.
  • memmap to show memory protections; flag RWX or RX pages that don’t map to on-disk module.
  • vadinfo to inspect VADs for mapped PE headers or anonymous allocations.
  • dlllist,ldrmodules to detect mismatched module names vs. on-disk files.
  • threads and psxview to find remote/suspended threads and discrepancies.
  • apihooks to detect IAT/EAT/inline hooks.
• Dump suspect memory regions and run YARA and strings; use pefile to compare in-memory PE headers vs disk to identify hollowing (entrypoint, image size, checksums mismatch).

Live/host-based checks

• Process Explorer / Process Hacker: view suspended threads, integrity of modules, open handles, and network connections.
• Sysinternals Autoruns and Sigcheck for suspicious signed binaries.
• GMER or HookShark for kernel/user-mode hooking detection.

Event Log artifacts

• Security: 4688 (process create) for command lines; 4689 for exits.
• Sysmon (if present): 1 (process create), 8 (CreateRemoteThread), 10 (process access), 11 (file create), 7 (image loaded), 3 (network connection), 22/23 for DNS/HTTP anomalies.
• PowerShell: 4103/4104 scriptblock and module logging.
• Windows Defender/AM logs for detections.
• Application/System for crashes, WMI or service events indicating svchost anomalies.

Indicators of injection/hollowing

• RWX anonymous allocations inside svchost, PE headers within heap/VAD, entrypoint pointing into injected region, remote threads targeting allocated memory, IAT/EAT inline hooks, mismatch between process image on disk and in-memory layout.

Reporting

• Record tools/versions, hashes, timestamps, chain of custody, and reproduceable analysis steps. Include exported memory dumps, YARA hits, and relevant Event Log excerpts as exhibits.