Senior Digital Forensic Examiner Interview Preparation Guide - Lyft

Overview — methodical workflow

1. Evidence acquisition & preservation

• Capture live memory (WinPMEM, DumpIt): winpmem.exe --format raw -o memory.raw
• Acquire disk image with write-blocker (FTK Imager, dd): dd if=\\.\PhysicalDrive0 of=disk.E01 bs=4096 conv=noerror,sync

2. Memory artifact extraction (Volatility3 / Volatility)

• Processes: vol.py -f memory.raw --profile=WinXPSP2x86 pslist
• Sockets: vol.py ... netscan
• Modules: vol.py ... dlllist or modscan
• Decrypted strings: strings -a -el memory.raw | grep -i secret and vol.py ... malfind then vol.py ... procdump -p PID -D dumps/

3. On-disk correlation

• Parse filesystem/MFT: fls -r -m C: disk.E01 and icat disk.E01 <inode> > recovered.exe
• Check registry persistence (Software\Microsoft\Windows\CurrentVersion\Run) with reglookup or Registry Explorer against SYSTEM/NTUSER hives
• Compare hashes: sha256sum recovered.exe vs memory-dumped module hash
• Timeline: ingest events with Plaso: log2timeline.py timeline.plaso disk.E01 memory.raw to match timestamps

4. Handling conflicts (process in RAM, missing exe on disk)

• Look for deleted file entries in MFT, slack space, unallocated carve: tsk_recover / bulk_extractor
• Search pagefile/hiberfile for swapped executable fragments: strings pagefile.sys | grep <procname>; use vol.py --plugins dumpfiles to extract in-memory image
• Check alternate locations (AppData, Temp, Volume Shadow Copies)
• Check persistence artifacts (scheduled tasks, services, LNKs) to explain absence

5. Validation & documentation

• Recreate mapping table: PID ↔ image base ↔ dumped module hash ↔ disk inode/path ↔ registry key
• Use YARA rules to confirm malicious signatures: yara -r rules.yar dumps/
• Document commands, timestamps, chain-of-custody, and justify forensic choices for court

This approach ensures repeatable, defensible correlation between volatile and on-disk artifacts and provides avenues to resolve missing-file conflicts through MFT recovery, carving, pagefile/hiberfile analysis, and persistence checks.

Situation & goal
I suspect timestamp tampering (M/C/A — Modified/Changed/Accessed) on Windows files. My goal: detect tampering indicators and reconstruct a reliable timeline using independent metadata sources.

Detection methods

• Compare NTFS MFT timestamps (M, A, C, B) for inconsistencies (e.g., change-time much newer than mtime).
• Check $MFT entry sequence numbers and $STANDARD_INFORMATION vs $FILE_NAME timestamps for divergence.
• Inspect $LogFile and USN Journal for prior file writes/rename entries that predate current timestamps.
• Examine Volume Shadow Copies and previous versions for older timestamp evidence.
• Correlate Windows Event Logs (Security/Object Access, Sysmon), application logs, and IIS/SMTP logs for file operations.
• Review artifact timelines from browsers, Office MRU, and prefetch files for user activity around suspicious times.
• Look for rounding/epoch patterns or identical timestamps across many files — potential bulk touch.

Reconstruction steps

1. Acquire forensically sound images and preserve original timestamps and journals.
2. Extract $MFT, USN Journal, $LogFile, VSCs, and relevant event/app logs.
3. Parse and normalize to UTC; build a unified timeline (e.g., CSV/Plaso format) with source and confidence tags.
4. Cross-validate: prioritize write records from $LogFile/USN and event logs over file-system timestamps; use VSCs to show earlier states.
5. Use hash comparisons between VSC and current files to detect content changes despite timestamp edits.
6. Document anomalies, confidence levels, and any required caveats for legal reporting.

Example
USN shows FILE_CREATE at 2024-02-10T03:12Z; MFT mtime is 2024-03-01T12:00Z — indicates timestamp was altered after original creation; corroborate with sysmon Event ID for file write at 2024-02-10 to fix the true activity.

Best practices

• Preserve chain of custody, record parsing tools/versions, and include source metadata in reports.
• State confidence and alternative explanations (time zone changes, clock drift, legitimate bulk edits).

YARA rule

rule PE_in_same_4KB_page_with_evil_stick
{
    meta:
        author = "Candidate — Digital Forensic Examiner"
        purpose = "Detect PE header ('MZ') and the ASCII string 'evil-stick' inside the same 4KB memory page"
        date = "2026-03-03"
        confidence = "high"

    strings:
        $mz = { 4D 5A }            // "MZ" bytes
        $evil = "evil-stick" nocase

    condition:
        // Iterate over 4KB pages in the image
        for any page_start in (0 .. filesize - 4096 step 4096) :
        (
            // "MZ" appears anywhere inside the 4KB page
            for any off in (0 .. 4094) :
                uint16le(page_start + off) == 0x5A4D
            and
            // ASCII string appears somewhere in same 4KB page
            $evil in (page_start .. page_start + 4095)
        )
}

Explanation and choices to reduce false positives

• Scans pages in 4096-byte steps to mirror typical RAM page boundaries and limit scope; this avoids matching unrelated "MZ" and "evil-stick" occurrences across page boundaries.
• Checks for the raw bytes {4D 5A} via uint16le comparison to avoid accidental partial matches from text heuristics.
• Requires both signatures be located within the same 4KB page; this reduces chance of separate unrelated artifacts triggering the rule.
• Uses nocase for the ASCII token only if attacker might vary case; remove nocase for stricter matches.
• Avoids the PE module (which expects full file structure); in memory images headers may be fragmented or relocated.
• Additional practical tuning: add entropy checks, verify e_lfanew points into the same page, or require presence of other PE strings ("PE\0\0") within page to raise confidence if false positives remain.

Direct answer / definitions

• Physical (bit-for-bit) image: an exact sector-by-sector copy of a storage device (raw/dd, E01) including slack space, unallocated clusters, file system metadata, and deleted/partially overwritten data.
• Logical copy: file- or directory-level export of visible files and metadata (e.g., copy via OS, FTK/EnCase export, or API) without unallocated space or full filesystem structures.

When to use (scenarios)

• Physical: full evidence preservation, criminal cases, deep recovery, timeline reconstruction, malware analysis. Example: imaging a suspect laptop with write blocker before seizure.
• Logical: rapid triage, eDiscovery, corporate incident response where speed and volume of user files matter and full forensic depth not required.

Deleted-file recovery & timelines

• Physical: enables deleted/fragment recovery and timeline from MFT, $LogFile, slack; better for long-term, detailed timeline work. Slower to acquire and process.
• Logical: cannot recover deleted/unallocated data; faster acquisition supports tight incident-response SLAs.

Admissibility, analysis capability, storage

• Admissibility: physical images with documented hash values, write-blocking, and chain-of-custody are strongest in court. Logical copies can be admissible but require clear methodology and may be challenged for completeness.
• Analysis capability: physical > logical for low-level artifacts, carving, and registry analysis. Logical suffices for content review, keyword searches, and custodian-driven eDiscovery.
• Storage planning: physical images are large (entire device) — plan TB-scale storage and indexing. Logical copies are smaller but require strict metadata and provenance records.

Practical recommendations

• Default to physical imaging when evidence may be contested or deep recovery needed. Use logical for triage or when imaging risks device integrity or time is constrained; document limitations and retain chain-of-custody and hashes for any acquisition.

Situation: On one project, engineering and design were operating in separate lanes, which caused late feedback and rework.

Task: I needed to rebuild trust and unblock delivery without turning the problem into a blame conversation.

Action: I set up joint working sessions where both teams reviewed the same problem statement and success criteria. I also introduced a shared definition of done so we were clear about what “ready” meant before handoff. To build trust, I made sure both sides had equal airtime, captured decisions in writing, and followed through on small commitments quickly. After that, I kept the collaboration healthy with regular check-ins, shared demos, and a single place to track open questions.

Result: The teams started catching issues earlier, handoffs became smoother, and there was less tension around ownership. The biggest lesson was that silos break down faster when people share context and make small reliable commitments over time.

Brief approach — why these matter
Plists and Unified Logs are high-value timeline sources on macOS: plists record persistent configuration, LastOpened/LastUsed times, and app metadata; Unified Logs capture in‑flight system and app events. Together they let an examiner correlate user actions, process launches, and system events.

Common plist locations

• User: ~/Library/Preferences/.plist, ~/Library/Application Support//.plist, ~/Library/Containers//Data/Library/Preferences/
• System: /Library/Preferences/.plist, /System/Library/Preferences/, /Library/LaunchDaemons/.plist, /Library/LaunchAgents/.plist, /var/db/receipts/.plist

Parsing binary plists safely

• Preferred tools: plutil -convert xml1 (safe CLI), Python plistlib (supports binary plists), libplist (objc/lib) for structured extraction.
• Safety practices:
  • Work on forensic images or read-only mounts.
  • Convert to XML for inspection but keep originals preserved.
  • Use sandboxed/parsing libraries (avoid executing embedded code or plist-specified scripts).
  • Validate expected schemas and handle malformed files defensively (catch exceptions, size-check).
  • For bulk processing, use streaming parsers and rate-limit memory to avoid DoS with crafted files.

Unified Logging: challenges & handling

• Storage/format: logs are stored in a compressed, proprietary, chunked format (system cache files, /var/db/diagnostics or logd storage). Decoding often depends on system version and symbol tables.
• Ephemeral/sampling: not all events are persisted; some entries are sampled or dropped — absence is not proof of absence.
• Timestamps: entries use mach/monotonic timestamps (mach_absolute_time). Convert to wall clock by combining:
  • kernel boottime (sysctl kern.boottime) or recorded boot time from logs
  • mach_timebase_info conversion (scale factors)
  • Many tools (log show, log collect) perform conversion automatically; when parsing raw blobs you must compute: wall_time = boot_time + (mach_ts * timebase_numer / timebase_denom) / 1e9.
• Tooling/compatibility: use Apple-provided tools (log show, log collect --output), and accept that archives from a different macOS build may fail to decode without correct symbol/schemas. Open-source decoders exist but may lag.
• Forensic approach:
  • Capture log archive with log collect (preserves metadata) or export via log show with time windows.
  • Correlate mach-based timestamps with plist timestamps (CFAbsoluteTime = seconds since 2001-01-01 UTC) and filesystem times.
  • Document decoding steps, OS build, and any missing data due to sampling/compression.

Practical example

• Extract ~/Library/Preferences/com.example.app.plist (plistlib -> LastOpenDate) => user action at X.
• Use log show --start "YYYY-MM-DD HH:MM" --predicate 'process == "ExampleApp"' to find matching process events.
• If parsing raw log store, compute wall time from mach timestamps using recorded boot_time found in system.log or log metadata.

Use these combined methods, preserve originals, and document conversion formulas and tool versions for court-admissible timelines.

Direct answer

Describe a specific incident where you personally made a containment decision, the trade-off you consciously weighed (typically downtime or business disruption against preserving evidence or fully understanding scope), how you coordinated with other teams to reach and communicate that decision, and one concrete thing you changed afterward as a result.

Structured elaboration

The strongest version of this answer picks one real, specific incident rather than a generic composite, names the actual trade-off you weighed in the moment (not an abstract "I had to balance security and business needs"), and is honest about what you'd do differently with hindsight, which reads as far more credible than a story where every decision was obviously correct in retrospect.

Structure it as: the situation (what alerted you, how severe it looked at first), the specific containment decision you had to make and why it wasn't obvious, how you coordinated with other stakeholders (who did you loop in, and when), the result (what actually happened, including any part that didn't go perfectly), and what changed afterward in your own approach or your team's playbook.

Worked example

"I was the on-call analyst when an EDR alert flagged a suspicious process on a shared file server used by two different business units. My first instinct was to isolate the host immediately, but that would have disrupted both teams' access simultaneously, and initial evidence wasn't yet clear whether this was a real compromise or a false positive from a recently-deployed monitoring rule. I spent about ten minutes pulling corroborating evidence, process details, recent authentication logs, before deciding the pattern was credible enough to isolate. Rather than isolating unilaterally, I called the on-call lead for one of the two affected business units to give a two-minute warning before I acted, since an unannounced outage on a shared resource would have caused confusion and extra support tickets on top of the actual incident. The host turned out to be genuinely compromised, evidence was preserved cleanly since I'd captured process and network state before isolating, and the business disruption was limited to about 20 minutes rather than becoming a longer, confusing outage. Afterward, I proposed adding a specific step to our containment runbook: a quick stakeholder-notification call before isolating any shared, multi-team resource, which wasn't previously an explicit step."

Trade-offs and pitfalls

A common weak answer describes only the technical containment action without describing an actual decision or trade-off, which misses what this question is really probing: judgment under uncertainty, not just technical execution. Another weak pattern is describing a story where hindsight makes every choice look obviously correct, which reads as either an oversimplified retelling or a lack of genuine reflection on what was actually uncertain in the moment.

Situation summary (brief)
I open a sealed evidence package: the digital image’s hash equals the custody log value, but the tamper-evident seal shows it was cut and resealed. This is a potential chain-of-custody discrepancy that could affect admissibility.

Immediate technical steps

• Re-photograph and document the packaging, seal, label, and evidence condition with scale and timestamps.
• Without altering the device, create a forensically sound disk image (write-blocker) and calculate multiple hashes (MD5, SHA-1, SHA-256) while logging tool/version, host, and time.
• Compare on-disk artifacts and metadata to the logged hash: confirm that the interior image matches the log (bytes-level match).
• Examine file system and forensic artifacts for signs of post-seal modification: MFT timestamps, MAC times, slack space, file system journaling, application logs, and residual timestamps inconsistent with custody timeline.
• Extract and analyze device/system event logs, USB connection logs, and forensic timeline to detect any access between sealing and current opening.

Procedural / investigative steps

• Secure and preserve original packaging separately; seal with new tamper-evident wrap and document chain-of-custody addendum noting observed seal condition.
• Obtain witness statements from the officer who sealed and transported evidence, chain custodians, and anyone who handled the package. Record interviews and note discrepancies.
• Collect and retain CCTV/entry logs from storage and transport locations for the relevant time window.
• If possible, request transportation manifest, evidence room access logs, and key-control logs.

Admissibility risk assessment

• If the internal digital image hashes exactly match the original logged hash and forensic timeline shows no internal modification, risk is mitigated: tampering may be limited to packaging. Explain that data integrity is intact (hash preserves evidentiary value) but chain-of-custody integrity is weakened and could be challenged as creating reasonable doubt.
• If forensic artifacts indicate access or modification inconsistent with custody times, high risk: evidence authenticity could be attacked; may require corroborating evidence or re-evaluation of probative value.

Preparing to explain to counsel / defend against motion

• Prepare a clear written addendum: step-by-step timeline, methods, tool versions, hash values, photos, witness statements, CCTV logs, and my interpretation.
• Produce a concise “expert summary” stating whether the digital content was altered and the basis (hash match + timeline artifacts). Use plain language and an appendix with technical detail.
• Anticipate defense lines (seal breached implies file tampering) and be ready to explain: difference between package tamper and data tamper; how cryptographic hashes demonstrate byte-level integrity; what artifacts would show device-level modification.
• Recommend remedial steps to prosecution: obtain and preserve all custodian testimony, corroborating logs, and consider stipulations if appropriate to avoid admissibility hearing.

Lessons / next steps

• Recommend policy changes: improved sealing procedures, dual custody signatures, CCTV coverage, and periodic audit of evidence storage.

How TLS limits network forensics

TLS encrypts payload and most HTTP headers after the handshake, preventing inspection of URLs, cookies, POST bodies and file contents. That loss forces examiners to rely on unencrypted metadata and endpoint artefacts (logs, disk images, memory) to reconstruct intent and data exfiltration.

Metadata-based detection techniques

• JA3 / JA3S fingerprinting: fingerprint TLS client and server hello fields (cipher suites, extensions, ordering). Use JA3/JA3S to cluster and attribute clients or identify malicious toolkits that reuse unique stacks (e.g., custom malware TLS vs. browser).
• SNI analysis: Server Name Indication in cleartext during ClientHello often reveals the requested hostname. Correlate unusual or suspicious SNI values, rapid SNI churn, or mismatches with expected domains.
• Certificate anomalies: Detect self-signed, short-lived, newly issued, or mismatched CN/SANs; unusual issuers; weak keys or abnormal validity periods—common in command-and-control and phishing.
• Flow and timing metadata: IP/port pairs, byte counts, session duration, inter-packet timing, and unusual session frequency help spot beaconing or exfiltration.
• DNS and TLS correlation: Combine DNS queries, passive DNS, and JA3/SNI to attribute hosts and detect domain-flux.

Practical example
During an incident I identified a beaconing implant by matching a rare JA3 fingerprint across multiple hosts, correlating SNI to a newly registered domain, and spotting short TLS sessions with consistent byte ratios—leading to containment.

Privacy and legal considerations
Respect lawful intercept and minimization: avoid decrypting content without warrant; collect only necessary metadata; document chain-of-custody. Some metadata can still be sensitive (visited host lists); obtain proper legal authority and follow jurisdictional rules before collection or disclosure.

Direct answer

State the facts plainly and completely before any interpretation: what was exposed, how many users, how you know, and what's already been done. Then translate the consequence into each listener's terms, evidence and notification-relevant facts for Legal, cost and exposure for the CFO, resisting both minimizing language and alarmist language on the way there.

Structured elaboration

• Separate three layers, and don't blend them. (1) What happened: plain facts, no jargon ("a bug let some users see another user's email address," not "an IDOR in the batch-export endpoint"). (2) What it means: the legal and business exposure. (3) What's being done: remediation and timeline.
• Calibrate tone with precision, not adjectives. Neither "minor issue" (minimizing) nor "major breach" (panic-inducing) does the job; exact scope numbers do: how many users, which field, how you found it, whether you have evidence of external access.
• Give Legal the facts, not your guess at the legal conclusion. Whether this triggers a mandatory breach notification is their call once they have the exact scope; stating it as settled either way (in either direction) oversteps and can be wrong.
• Give the CFO honest uncertainty where it exists. Quantify remediation cost and effort, which you know. If downstream revenue or reputational exposure isn't defensibly knowable yet, say that directly rather than attach a number to make the room feel more informed than it is.
• The same three-layer discipline scales to a bigger stakeholder list. It's what a cascading-outage incident commander delivers to the CEO, support, legal, enterprise customers, and the public, the same facts, layered the same way, at different depth and formality for each. And it's the same shape whether the trigger is an active exposure or a not-yet-exploited security-patch risk being explained to the CFO and Legal before a fix ships.

Worked example

"Here's what we know. A bug in the account-export feature let a user see another user's email address under a specific, narrow condition. We've confirmed it affects up to about 1,200 accounts out of 400,000 total, roughly 0.3%. We found this through an internal security review, not an external report. We shipped a fix that closes the access path as of this morning, and we're now confirming whether any of those 1,200 accounts were actually viewed, versus just technically exposed. We have no evidence right now of the data leaving our systems.

Legal, I want to hand you the exact scope now so you can make the notification call, I'm not going to guess at the compliance answer here.

Finance, at this stage the remediation itself is about three engineer-days, already done. I don't yet have a defensible number for downstream cost or churn risk, and I'd rather tell you that plainly than invent one to fill the silence."

Trade-offs & pitfalls

The question names both failure directions on purpose: minimizing (soft-pedaling the scope to avoid alarm) destroys credibility the moment the real scope surfaces later, and panic-inducing framing (over-scoping before you have facts) can trigger costly, premature actions that turn out to be wrong. A related pitfall is attaching an invented multiplier or estimate to reputational or revenue exposure just to hand the room a number, once said out loud, that number gets repeated as fact even with a caveat attached. The better move, and the harder one, is to give the real scope with full confidence and the downstream cost with honest uncertainty, in the same conversation. Finally, don't let Legal's need for a precise, defensible scope slow down sharing the facts with Finance, the scope statement doesn't have to wait for the legal conclusion.