Covers investigative approaches for complex or information constrained situations, such as incident response and forensic analysis. Topics include handling encrypted or partially corrupted data, dealing with fragmented or deleted artifacts, reconciling conflicting timelines, analyzing incomplete logs, performing multi location investigations, prioritizing limited leads, documenting assumptions, preserving chain of custody where relevant, and making defensible decisions under uncertainty. Candidates should demonstrate methodical evidence collection, hypothesis driven analysis, risk management, and clear explanation of trade offs and next steps.
EasyTechnical
31 practiced
You arrive at an incident where a Windows workstation is powered on and connected to the corporate network. Describe, step-by-step, how you would perform forensic acquisition of attached disk(s) while preserving evidence integrity. Include decisions and procedures for live acquisition versus powering down and offline imaging, tools you would use (e.g., FTK Imager, dd, live-collector tools), the role of write-blockers, network isolation, and how you'd document and verify the image.
Sample Answer
**1) Initial triage & safety**- Confirm legal authority (PO, consent) and note time/location/people.- Photograph workstation state (screens, cables, attached devices, powered state).- Isolate network: unplug Ethernet/Wi‑Fi or place switch port in quarantine/VLAN to prevent remote tampering while preserving power for live capture.**2) Decide live vs. offline**- If volatile data (RAM, active network connections, running processes, crypto keys) is critical, perform live acquisition first.- If risk of tampering is low and investigator can image safely, powering down for hardware write‑blocked imaging provides cleaner forensic image. Default: capture volatility first, then offline imaging.**3) Live collection (if performed)**- Capture memory with trusted tool (DumpIt, Belkasoft Live RAM, WinPMem). Record tool hash/version, start/stop times.- Collect live artifacts: running processes, network connections, open files, user sessions (using Sysinternals, netstat, tasklist).- Use FTK Imager for logical copies or live evidence export; or use native live collectors that write to external USB (ensure destination is on investigator media).- Calculate hashes of live captures immediately (SHA256, MD5).**4) Prepare for offline imaging**- Shut down gracefully if imaging offline; record shutdown method/time.- Remove suspect disk(s) and connect to workstation using a hardware write‑blocker (CRU UltraDock, Tableau) to prevent writes.- For laptops where removal isn’t feasible, connect via write‑blocker adapter or image via SATA/USB through write‑blocker.**5) Imaging**- Use FTK Imager or dd/Guymager for bit‑stream images (E01 or raw). Example: use FTK Imager to create E01 and capture metadata.- Create a hash (MD5 + SHA1 or SHA256) during imaging and verify after image completion.- Keep original drives write‑blocked and secure.**6) Verification & documentation**- Verify image integrity: compute hashes on source (if live capture allowed) and on images; record matching hashes.- Complete Chain of Custody form: who handled device, dates/times, storage location, evidence bag tags, serial numbers.- Log tool versions, commands used, hash outputs, and photographs of media and write‑blocker setup.- Store original media in evidence locker; work on copies.**7) Tools & best practices summary**- RAM: DumpIt, WinPMem, Belkasoft.- Imaging: FTK Imager (E01), Guymager, dd for raw imaging.- Write‑blockers: hardware (Tableau/CRU). Avoid software-only blockers for source protection.- Hashes: MD5 + SHA256; record both.- Preserve chain of custody and timestamps; never modify source.This approach preserves integrity while capturing volatile evidence; documentation and verified hashes make images court‑admissible.
HardTechnical
22 practiced
You encounter a LUKS2-encrypted laptop whose header was partially corrupted, but significant ciphertext remains. Describe technical strategies you would attempt to recover access: searching for header backups on the disk, locating keyslots, attempting header reconstruction, using known-plaintext or metadata analysis, and when to escalate to cryptographic specialists or accept that recovery is infeasible. Discuss the practical feasibility and forensic preservation steps.
Sample Answer
**Brief summary / context**As a forensic examiner I’d treat a partially corrupted LUKS2 header as a live evidence-recovery problem plus a preservation/legal problem. Goal: maximize recoverable ciphertext and metadata while minimizing modification.Preservation (first and mandatory)- Apply write blocker, create full bit-for-bit images of the entire device (not just partitions) with ddrescue to capture damaged areas; keep original sealed.- Compute and record hashes (SHA256) of source and images; document chain of custody, hardware, commands, timestamps, operator.- Work only on copies; log all actions and decisions.Triage & initial analysis- Identify LUKS2 presence: search for magic bytes ("LUKS\xba\xbe" for LUKS1; LUKS2 uses JSON header structures) and offsets with hexdump/strings.- Use cryptsetup luksDump --dump-master-key / luksDump on copies to see which parts parse; do NOT write to original.Searching for header backups / detached headers- LUKS2 supports detached headers and header copies. Search whole disk and slack space for JSON descriptor fragments, keyslot objects, UUIDs, or known markers.- Check end-of-disk, partition gaps, secondary metadata areas. Use grep/xxd/photorec-style carving for JSON fragments, base64 blobs, or binary keyslot blocks.- If a detached header exists (file or alternate area) restore it to a safe copy and attempt cryptsetup --header on the image.Locating and analyzing keyslots- LUKS2 stores keyslots in header metadata (salt, iterations, protected master key material). Try to parse partial header to find intact keyslot blobs.- If keyslot ciphertexts remain intact, and only JSON/metadata corruption occurred, you may be able to reconstruct a syntactically valid header wrapper around existing keyslot blobs.- Use tools: cryptsetup (with --dump-master-key when possible), luksmeta, and community tools for LUKS2 parsing. Export any keyslot blobs for offline analysis.Header reconstruction attempts- If header is partially present, reconstruct missing fields from defaults or by copying from a template LUKS2 header adjusted to match cipher/UUID/area sizes you can infer.- Rebuild minimal JSON descriptor referencing existing keyslot blobs and attempt cryptsetup with --header pointing to reconstructed header on the image.- For detached-header scenarios, careful binary placement matters (offsets, checksums). Preserve backups of every intermediate image.Known-plaintext / metadata analysis / cryptanalysis feasibility- LUKS2 uses modern KDFs (argon2) and strong AE modes (AES-XTS) — known-plaintext or ciphertext-only recovery is effectively infeasible unless: - passphrase is weak and brute-force-able (use hashcat with extracted KDF parameters), or - part of the master key or KDF salt is recoverable.- Collect any candidate plaintext (standard filesystem headers) only to validate successful key guesses after brute force.- Known-plaintext attacks against AES-XTS with full-strength keys are not practical; focus on dictionary/rule/brute-force of passphrases if keyslot blobs intact.When to escalate or accept infeasibility- Escalate to cryptographic specialists if: - you recover partial but inconsistent keyslot material suggesting advanced partial-key reconstruction may be possible; - there are indications of vendor-specific header variants or hardware-backed keys.- Accept infeasible when all keyslots are irretrievably corrupted, no detached/header backup found, and passphrase space is infeasible to brute force. Document rationale thoroughly.Practical notes & best practices- Try non-destructive tools first; keep incremental image copies before each major attempt.- Record every parameter (cipher, sector size, UUID) you infer; these help specialists.- Use controlled brute-force only on copies and with case-appropriate legal authority.- Deliver a clear report: what was tried, artifacts recovered, why recovery failed or succeeded, and recommended next steps (specialist engagement or legal options).Outcome expectation- Recovery is often possible if a header or keyslot blob is intact, or passphrase is weak. If both header and keyslots are destroyed and KDF protects the master key, practical recovery is unlikely; the correct forensic course is preserving evidence, exhaustive documentation, and escalation when justified.
EasyBehavioral
28 practiced
Describe how you document assumptions, limitations, and confidence levels in a forensic report when evidence is incomplete or ambiguous. Provide an example structure you would use to communicate uncertainty to legal teams (for example: facts, assumption statements, confidence rating, and recommended next steps), and explain how you update documentation when new evidence arrives.
Sample Answer
Situation / TaskI was assigned a case where an image from a suspect laptop showed partial browser history and fragmented email artifacts; key server logs were unavailable. I needed to produce a defensible report that made clear what was proven versus what rested on inference.Action — how I document uncertainty- Facts: List verifiable items with provenance and timestamps. - Example: “Recovered file /Users/jdoe/Documents/contract.docx (MD5: ...) from forensic image E01; timestamp 2023-10-12T14:03:20Z; acquisition hash verified.”- Assumption Statements: Explicitly label inferred items and the basis. - Example: “Assumption A1: The deleted email referencing X was sent by user jdoe. Basis: partial header fragments and matching local Sent Items entry.”- Limitations: Describe evidence gaps, tool limitations, and environmental constraints. - Example: “Limitation L1: No mail server logs available; cannot conclusively prove delivery or receipt.”- Confidence Rating: Use a simple scale (High / Moderate / Low) with justification. - Example: “Confidence: Moderate — partial header match and local artifacts support inference but lack server corroboration reduces certainty.”- Recommended Next Steps: Practical actions to reduce uncertainty. - Example: “Request mail server logs for 2023-10-11 to 2023-10-13; obtain remote mailbox snapshot; perform carved email reconstruction.”Result — updating when new evidence arrivesWhen additional logs arrived, I appended a dated addendum: recorded new facts (with hashes), re-evaluated each prior assumption, adjusted confidence ratings, and noted which limitations were resolved. I maintained an audit trail: versioned report, timestamped change log, and retained original findings for chain-of-custody and cross-examination. This approach keeps legal teams informed, defensible, and ready for follow-up or testimony.
HardSystem Design
29 practiced
Design a tamper-evident audit trail for a forensic analysis platform that records every action (ingest, image acquisition, analysis steps, artifact exports). Specify cryptographic choices (hashing algorithms, HSM-signed attestations), storage model (append-only, WORM, distributed ledger optional), metadata schema (actor, action, parent-hash, timestamp), access control, and the process to allow third parties to independently verify the audit trail during litigation.
Sample Answer
**Approach (brief)** As a forensic examiner I’d design an append-only, tamper-evident audit trail combining content hashing, HSM-signed attestations, RFC‑3161 timestamps and optional distributed anchoring so third parties can independently verify chain-of-custody in court.**Cryptography & signing**- Content hashing: SHA‑256 for per-event hashes; SHA‑512 when high-entropy artifacts require extra collision resistance. - Structure: each record includes parent-hash and forms a Merkle tree per case; store Merkle root per day. - Attestations: HSM (FIPS 140‑2/3) holds signing keys; sign each record and daily Merkle root with ECDSA P‑384 (compact, strong). - Trusted timestamps: RFC‑3161 timestamp tokens for critical milestones (image acquisition, export).**Storage model**- Append‑only write path; enforce WORM storage (immutable object store like S3 Object Lock or appliance). - Replicate to a secondary immutable store and optionally anchor daily Merkle roots to a public blockchain (e.g., BTC/OP_RETURN or Ethereum) for external anchoring.**Metadata schema (per record)**- record_id, case_id, actor_id, actor_role, action_type (ingest|image|analyze|export), artifact_hash (SHA‑256), parent_hash, merkle_leaf_index, timestamp_utc, hsm_signature, rfc3161_token, notes, tool_version, environment_hash.**Access control & protection**- RBAC + MFA; least privilege for evidence operations. - Keys in HSM; signing operations via KMS/HSM API only. - Encryption at rest (AES‑256) and TLS 1.3 in transit. - Separate audit of admin actions, dual‑control for key use (require 2 operators for sensitive signing).**Verification process for third parties**1. Request evidence package: record chain, Merkle proofs for each record, signed HSM attestations, RFC‑3161 tokens, public verification key (certificate chain). 2. Independently verify HSM public key via CA; validate signatures on records and Merkle root. 3. Recompute hashes from provided artifacts; confirm artifact_hash matches recorded value. 4. Validate RFC‑3161 timestamps and any blockchain anchoring. 5. Confirm WORM storage receipts and replication logs.**Legal & operational notes**- Keep key custody policies, SOPs, and separation of duties documented. - Generate periodic integrity reports and preserve original images offline. This design gives cryptographic integrity, non‑repudiation via HSM signatures and timestamps, immutable storage, and an auditable verification path suitable for litigation.
MediumTechnical
27 practiced
A file on Host A has an NTFS MFT timestamp of 2022-03-10 03:15:00, but the web server log that references that file shows 2022-03-10 02:45:00. Describe how you would determine the correct timing, identify causes for the discrepancy (for example, timezones, NTP drift, daylight savings, manual clock changes), and reconcile the events so you can present an accurate timeline with documented confidence levels.
Sample Answer
**Approach summary**I would treat timestamps as data points to be validated and normalized to a single reference (UTC), then reconcile using corroborating sources and document confidence. Steps below follow forensic best practice: preserve evidence, collect metadata, correlate, adjust, and report.1) Evidence collection & preservation- Image Host A (forensically) and collect original IIS/web server logs, system event logs, w32tm status, registry time zone keys (HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation), and router/NTP server configs. Hash everything.2) Determine authoritative time bases- NTFS MFT uses Windows FILETIME (stored as UTC). So the MFT timestamp 2022-03-10 03:15:00 is typically UTC representation converted to local when viewed; confirm by checking timestamps via low-level tools (e.g., fls/plaso or raw FILETIME extraction).- Web logs (IIS/Apache) often record local time or include offset. Check log format: e.g., IIS sc-bytes fields or date-time with timezone field. If timezone absent, check server OS timezone and web server config.3) Identify possible causes for 30-minute discrepancy- Timezone offset / DST: server uses different timezone or DST shift around that date.- NTP drift or sync errors: w32tm / ntpq may show last sync times; server could have been unsynchronized.- Manual clock changes: Windows Event ID 1 (Time-Service) or Event ID 4616 (The system time was changed) show manual adjustments.- Log generation vs file modification: web log entry references served time (request time) which could precede file modification if file was replaced later.- Clock skew between hosts: client, web server, and Host A clocks differ.- Daylight saving ambiguous transition or historical timezone rules.- Timezone misinterpretation when converting FILETIME to local display.4) Correlation procedure- Normalize both timestamps to UTC explicitly. For MFT: extract raw FILETIME and convert to UTC. For web log: parse timestamp + offset; if offset absent, apply server timezone from registry/events and convert to UTC.- Check Windows Event Log for time-change events around the interval; check NTP logs for drift or failed sync.- Cross-correlate with other logs: web server access logs from load balancer, firewall, reverse proxy, or application logs; network device logs; DHCP lease events; authentication logs. Look for the same request or file access to triangulate time.- If available, check filesystem USN Journal for more granular sequence of file operations.5) Reconcile and build timeline- Produce timeline entries in UTC with offsets and original reported values. Example: - Host A MFT raw FILETIME: 2022-03-10 03:15:00 UTC (converted from raw value) - Web log entry: 2022-03-10 02:45:00 (server displayed local time -0500) => normalized to 2022-03-10 07:45:00 UTC (example)- Explain conversion steps and show calculations used.6) Assign confidence levels- High confidence: multiple independent sources agree after normalization (e.g., MFT FILETIME + USN journal + Windows event timestamps + NTP status).- Medium confidence: single authoritative source with reasonable corroboration (e.g., MFT + web server timezone settings but no NTP logs).- Low confidence: conflicting sources or missing timezone/ntp info; highlight assumptions.7) Report and remediation suggestions- Document every conversion, command/tool used, hashes, and evidence paths.- Recommend preserving NTP server logs, enabling timezone-aware logging, and configuring secure NTP.- If timeline will be used in legal context, provide signed affidavit of methods and exhibits showing raw values and conversions.Example commands/tools to use- Dump FILETIME: use fls, istat, or PowerShell Get-ItemProperty with -Force and convert via [DateTime]::FromFileTimeUtc(...)- Check Windows time events: wevtutil qe System /q:"*[System[(EventID=1 or EventID=4616 or EventID=35)]]"- Check w32tm: w32tm /query /status and /peersThis method provides an auditable, reproducible timeline with clear justification for the selected “correct” times and documented confidence levels.
Unlock Full Question Bank
Get access to hundreds of Investigative Problem Solving interview questions and detailed answers.
