File System Forensics and Analysis Questions

Covers the principles and techniques for examining file systems to locate, recover, and interpret forensic artifacts and metadata. Candidates should understand file system internals including Master File Table structures, inode and directory record layouts, journaling behavior, and differences between common file systems such as New Technology File System, File Allocation Table variants, Extended Filesystem version four, Hierarchical File System Plus, and Apple File System. Topics include how files are allocated, modified, deleted, and recovered; slack space and unallocated space analysis; file carving and content recovery; recovery of deleted file metadata; timestamps and their forensic significance including created, modified, accessed, and changed values; ownership and permission metadata; how application data, logs, caches, temporary files, and registry data generate artifacts; and how metadata and artifacts can be used to reconstruct user activity timelines. Candidates should also be familiar with anti forensic techniques such as timestamp manipulation, secure deletion, and data hiding, and with strategies for prioritizing and triaging analysis when faced with large volumes of evidence. Familiarity with evidence handling principles, hashing for integrity verification, and common forensic workflows and tools is expected.

HardTechnical

42 practiced

In ext4, inodes (and their numbers) can be reused after deletion. Devise a forensic method to determine whether a deleted inode's content has been overwritten or reused, including which filesystem structures to inspect (inode table, block group descriptors, orphan list, journal) and how to corroborate your findings with non-filesystem artifacts.

MediumTechnical

41 practiced

You have 90 minutes on-scene with a single analyst and a 2TB corporate laptop suspected of data exfiltration. Create a prioritized triage plan listing the artifacts and commands/tools you would collect first (volatile and non-volatile), how to preserve evidence, and how to document actions while minimizing disruption to volatile data.

Sample Answer

**Situation & goal** You have 90 minutes with one analyst and a 2TB laptop suspected of data exfiltration. Priority: preserve volatile state (RAM, network, active sessions), collect high-value artifacts quickly, then acquire non‑volatile images/hashes. Minimize writes and avoid reboot.

**Immediate preserve & containment (first 2–5 minutes)**- Photograph laptop state (powered on, screens, external devices). Note time, user presence, power source, network connection.- Isolate from network without powering off: prefer unplugging Ethernet and disabling Wi‑Fi via OS UI if possible; place in airplane mode or use a hardware network disconnect. If regulatory/policy requires, place in a Faraday bag after live collection.- Assign evidence tag and start chain-of-custody log.

**Volatile collection (minutes 5–25) — capture first**- Memory image (primary): use trusted, signed tool from write-protected media. - Example tools: DumpIt, Belkasoft Live RAM capture, Magnet RAM Capture, FTK Imager (live).

bash

# example (Windows) using DumpIt (run from external USB)
DumpIt.exe

- Running processes, services, and process network connections:

powershell

tasklist /V
netstat -ano -p tcp
Get-Process | Sort CPU

- Open files, handles, loaded modules:

powershell

handle.exe -accepteula > handles.txt   # Sysinternals

- Network connections and route table, DNS cache:

powershell

netstat -abno
ipconfig /all
route print
ipconfig /displaydns

- Logged‑on users, sessions, and clipboard:

powershell

query user
whoami /all
powershell -command "Get-Clipboard" > clipboard.txt

- Browser sessions and open tabs (use browser-specific live export or copies of profile files), email client state, cloud sync clients (OneDrive/Dropbox status).- Mounts and attached devices, USB history:

powershell

wmic logicaldisk get name,description
reg query "HKLM\SYSTEM\CurrentControlSet\Enum\USBSTOR"

- Scheduled tasks, autoruns, network shares:

powershell

schtasks /query /fo LIST /v
autorunsc.exe -accepteula > autoruns.txt

Record hashes and timestamps of any collected volatile files immediately.

**Non‑volatile collection (minutes 25–80)**- Acquire forensic disk image after volatile capture. If time is limited, create a block device clone to external write-blocked media or create E01 with FTK Imager: - Prefer a physical image (dd, ddrescue, FTK Imager) with SHA256/SHA1.- Collect key artifacts pre-image if full image delayed: registry hives (SYSTEM, SOFTWARE, SAM, NTUSER.DAT), event logs, Prefetch, MFT, $LogFile, pagefile, swapfile, shadow copies, browser profile folders, Downloads, Desktop, Documents, and cloud sync folders.

powershell

wevtutil epl Application Application.evtx
xcopy /E /I "C:\Users\username\AppData\Local\Google\Chrome\User Data" D:\artifact\chrome\

- Acquire Volume Shadow Copies (vssadmin list shadows) or use vssadmin to expose.- Compute hashes of original disk/device and of images. Log tool versions and command output.

**Preservation & evidence integrity**- Do not reboot the system. Use signed, validated tools from external media.- Use write-blockers for physical disk acquisition. For live collections, minimize writes; document any expected writes.- Record MD5/SHA1/SHA256 for each artifact and image immediately after capture.- Maintain chain-of-custody: who handled, when, why, where stored, media serial numbers.

**Documentation during process**- Maintain a running triage log: timestamps (UTC), commands run, tool name/version, operator, IP/network status, file paths collected, hashes, screenshots of desktop and important application windows.- Capture console outputs to files; include hashes of those logs.- Use a standardized checklist/template and initial incident summary for handoff.

**Minimize disruption guidance**- Prefer read-only collection and non-invasive commands. Use memory capture first to avoid losing in‑RAM artifacts.- If uncertain, capture an additional RAM image and logs before deeper probing.- When possible, perform deeper analysis on a forensic workstation using copies, not the original.

**Example prioritized checklist (short)**1. Photograph & isolate → start chain-of-custody 2. Memory image (DumpIt/Belkasoft) + hash 3. netstat, ipconfig, running processes, open files, clipboard, logged-on users 4. Browser profiles, cloud sync status, USB/drive mounts 5. Event logs, registry hives, Prefetch, MFT, VSCs 6. Full disk image (write-blocked) + hashes 7. Document everything, package evidence, handoff

This plan preserves the highest-value volatile evidence first, creates verifiable artifacts for court, and limits contamination while enabling follow-up forensic analysis.

HardSystem Design

46 practiced

Design a scalable forensic processing pipeline to ingest 100+ disk images per month: include components for acquisition ingestion, hash verification, automated triage, artifact extraction, timeline generation, indexing/search backend, analyst review queue, and long-term storage. Explain technology choices, how you ensure integrity and chain-of-custody, and how you handle scalability and parallel processing.

Sample Answer

**Clarify requirements & constraints**- Ingest ~100+ disk images/month (typical single-case bursts), preserve evidentiary integrity, support automated triage + analyst review, searchable artifacts, long-term immutable storage, ability to parallelize.

**High-level architecture**- Acquisition station → Ingestion API & queuing → Hash & COC service → Triage workers → Extraction & timeline workers → Indexing/search cluster → Analyst queue/UI → Long-term WORM storage + audit logging

**Components & technology**- Acquisition: write-blocker + FTK Imager/Guymager creating E01/RAW; capture metadata (device, examiner, date/time).- Ingestion API: REST endpoint (Python/Flask or Go) validates metadata, stores initial record in PostgreSQL.- Queueing: RabbitMQ or AWS SQS for job distribution.- Hash/COC: Compute MD5+SHA256 using libbfio or hashing service; store hashes and signed manifest; use HSM or GPG to sign manifests for chain-of-custody.- Automated triage: YARA rules / bulk_extractor / SleuthKit auto-rules in containerized workers (Docker + Kubernetes).- Artifact extraction & timeline: Plaso/Timesketch pipeline for timeline generation; volatility for memory if applicable.- Indexing/search: Elasticsearch/OpenSearch cluster with RBAC, ingest pipelines to normalize artifacts.- Analyst review queue/UI: Web app (React + backend) showing prioritized cases, evidence links, flags from triage; allow snapshot tagging.- Long-term storage: Write-once S3 Glacier Deep Archive or on-prem WORM; retain original image, signed manifests, and extracted artifacts.- Audit & logging: Immutable audit log in append-only store (e.g., blockchain-backed or write-once DB), Syslog + SIEM integration.

**Integrity & chain-of-custody**- At acquisition: record examiner, location, device serials; generate MD5+SHA256; sign manifest with examiner key (GPG/HSM).- Every pipeline step verifies input hash before processing and appends operation record to manifest with timestamp and operator/service identity.- All manifests and audit logs are immutable and timestamped; store copies in separate secure locations (air-gapped when needed).- Access control: MFA, least privilege, and tamper-evident storage; preserve original images in WORM.

**Scalability & parallel processing**- Containerize workers and autoscale via Kubernetes; use job queues to distribute work; prioritize jobs by case severity.- Split large images into logical processing units (volumes/partitions, file-level extraction) so multiple workers can run in parallel while preserving original-file hashing verification.- Use batch indexing, incremental updates, and shard indices in OpenSearch; monitor with Prometheus/Grafana and add nodes as throughput grows.

**Trade-offs & practical notes**- Balance on-prem vs cloud for legal/jurisdiction requirements; cloud accelerates scaling but requires strong encryption and provider agreements.- Ensure forensic repeatability: store pipeline versions, tool hashes, and config in manifests for court defensibility.

This design ensures evidence integrity, auditable chain-of-custody, automated triage to reduce analyst load, and horizontal scalability to handle 100+ images/month reliably.

MediumTechnical

44 practiced

Explain key differences between HFS+ (HFS Plus) and APFS that impact forensic analysis: catalog B-tree vs APFS B-tree/object map, journaling vs copy-on-write/snapshots, and differences in file deletion semantics. Give examples of how recovery strategies differ between the two.

Sample Answer

**Brief framing (forensic perspective)** Focus changes from metadata-centric recovery on HFS+ to object/transaction-centric recovery on APFS. Investigations should prioritize different artifacts and tools.

**Catalog B-tree (HFS+) vs APFS B-tree / Object Map** - HFS+: central Catalog B-tree holds file records, directory hierarchy, timestamps and extent records. Forensics: recovering deleted entries often means scanning the Catalog B-tree for orphaned records and using extent info to carve file data. - APFS: metadata split across multiple B-trees (Object Map, CNID trees, extent b-trees). The Object Map maps object IDs to container blocks; snapshots and clones reference objects by ID. Forensics: you must parse object map and b-trees to reconstruct file-object relationships; deleted objects may remain referenced by snapshots/clones.

**Journaling vs Copy-on-Write (COW) and Snapshots** - HFS+ uses a journal to record pending metadata updates. Journal replay can restore metadata consistency and sometimes reveal recently deleted file records. Recovery strategy: extract and replay journal entries to reconstruct transactions. - APFS uses COW: updates create new objects rather than overwrite. Snapshots are immutable references to prior states. Forensics: snapshots often allow easy recovery of previous file versions. Also examine the container-level transaction log (fossil data) and snapshots before assuming data is gone.

**File deletion semantics and practical impacts** - HFS+: deletion typically removes Catalog B-tree record and marks extents free; until overwritten, data remains and carving plus Catalog remnants can recover filenames and timestamps. - APFS: deletion removes references to object IDs; COW may leave old object blocks around until space reclaimed. However, on SSDs TRIM and aggressive garbage collection combined with APFS extent reclamation and space sharing make raw carving less reliable. Snapshots can preserve deleted content long after user deletion.

**Example recovery strategies** - Recovering a deleted document (HFS+): image the device, parse Catalog B-tree for previously linked record, replay journal for last transactions, use extents to carve remaining file bytes. Tools: The Sleuth Kit, HFSExplorer, proprietary parsers. - Recovering a deleted document (APFS): first enumerate snapshots—mount or extract snapshots to restore previous state; parse Object Map and APFS b-trees to locate object IDs and extents; if snapshots absent, search unreferenced objects in containers and attempt carving, but expect lower success on SSDs due to TRIM. Tools: apfs-fuse, libfsapfs, Mac forensic suites that support APFS snapshots.

**Practical tips** - Always preserve the whole APFS container (not just a volume) to retain snapshots and object maps. - Prefer logic acquisition that preserves snapshots or full block capture. - On encrypted systems (FileVault), acquire keys/escrow first; encrypted metadata limits analysis.

This approach shows why APFS requires different artifact prioritization (snapshots, object map) than HFS+ (Catalog B-tree, journal) and how that changes recovery tactics.

MediumTechnical

40 practiced

You're given a raw disk image with an NTFS volume. Describe, step-by-step, how you would locate and interpret MFT entries to identify metadata for recently deleted files. Include how to identify deleted MFT entries, important attributes to parse, and how to reconstruct filename history when multiple $FILE_NAME attributes exist.

Sample Answer

**Clarify goal & safety**- Work only from a forensically sound read-only image; record hashes and chain of custody first.

**Step‑by‑step process**1. Locate NTFS and MFT - Parse the boot sector (bytes at start of partition) to read bytes-per-sector, sectors-per-cluster, and $MFT cluster number and MFT record size. - Tools: sleuthkit fsstat, mmls to find partition offsets.

Example:

bash

mmls disk.img
   fls -o <offset> -m / -r disk.img
   fsstat -o <offset> disk.img

2. Identify and parse MFT records - Read $MFT starting at cluster number × cluster_size. MFT records begin with ASCII "FILE". - Determine record size (from boot: usually 1024 or 0xFFFFFFFF -> calc). - Scan entire MFT for "FILE" headers to enumerate records (can be fragmented; use tools like analyzeMFT, mftparser, or custom script).

3. Recognize deleted MFT entries - Check the Flags field in the MFT header: in-use flag = 0x01. If cleared, entry is deleted/available. - Check Sequence Number and $STANDARD_INFORMATION timestamps; deleted entries often retain attributes until overwritten.

4. Important attributes to parse (for each MFT entry) - $STANDARD_INFORMATION: creation, modified, MFT modified, access times, file permissions. - $FILE_NAME: filename, parent reference, filename namespace, timestamps (often multiple instances). - $DATA: resident data or extent pointers to clusters (data runs) — needed to recover file content. - $ATTRIBUTE_LIST: if attributes are out-of-record (extents). - $INDEX_ROOT / $INDEX_ALLOCATION (for directories). - $SECURITY_DESCRIPTOR: ownership/ACL info.

5. Reconstruct filename history when multiple $FILE_NAME attributes exist - Multiple $FILE_NAME attributes represent name/parent snapshots (hard link history, namespace variations like DOS/Win32). - For each $FILE_NAME attribute, record: - File name string and namespace (DOS, Win32, Win32 & DOS, POSIX). - Parent MFT reference. - Timestamps inside that attribute (filename-level created/modified). - Order history by timestamps: the most recent name is usually indicated by the latest MFT modified time or latest filename timestamp. When in-use entry was renamed, an older $FILE_NAME remains — use MFT sequence numbers and $STANDARD_INFORMATION.mft changed to infer chronology. - Cross-reference directory index entries to see which filename was present in parent directory at given times.

6. Recover content & confirm deletion - If $DATA non‑resident and clusters not overwritten, follow data runs to carve/icat content. - Validate recovered content hashes against known artifacts (logs, timeline).

**Evidence & reporting**- Document offsets, MFT record IDs, flags, timestamps, and commands used.- Preserve both the original image and any derived artifacts; report confidence about overwritten vs recoverable data.

Notes: SleuthKit, AnalyzeMFT, Regripper plugins, and libfsntfs are practical tools. When manual parsing, always interpret little-endian integers and update sequence/checksum fields correctly.

Unlock Full Question Bank

Get access to hundreds of File System Forensics and Analysis interview questions and detailed answers.

Join thousands of developers preparing for their dream job.