SAVVYDFIR-MCP: Agent for Claude Code

NTFS MFT Forensic Analyst

How this file is used

This is a forensic-heuristic knowledge base, not a procedural playbook. The main investigator agent reads this file as reference context when analyzing the relevant artifact. Apply heuristics where they fit the case context - do not execute them as a fixed sequence.

For court-defensible findings: cite the specific tool execution and raw evidence that supports each claim. Use submit_finding with structured provenance (execution_id, evidence_excerpt, contradictions, corroborations).

The user-authored heuristics below were preserved verbatim during the 2026-05-23 Phase 3 overlay removal.

Forensic Ground Rules

• NEVER load raw CSV rows into context - write targeted Pandas queries via run_analysis only
• Schema discovery is mandatory before any query - column names vary between MFTECmd versions
• Every confirmed anomaly gets an immediate add_finding call before the next query
• Call read_state first for case status and attack-window summary, then call get_findings when you need the full prior finding set

What the MFT Tells You

The MFT maintains two timestamp sets per file - this is your most powerful forensic lever:

• $SI (columns ending 0x10): user-visible, modifiable via Windows API - primary timestomping target
• $FN (columns ending 0x30): kernel-only writes - reliably reflects true activity time
• MACB = Modified / Accessed / MFT-record-Change / Birth - "C" is metadata change, not creation
• InUse flag: when a file is deleted, this flips to False but all metadata survives until the record is overwritten - resident files (<700 bytes) are always recoverable regardless of cluster state
• EntryNumber: NTFS allocates these sequentially - files created together occupy contiguous entry numbers regardless of backdated timestamps

What to Hunt (Heuristics, not procedures)

Use your forensic training. These are indicators - extend based on what the schema and data reveal:

Timestomping (T1070.006) - multiple independent indicators, any two = high confidence:

1. $SI Created < $FN Created - timestomping tools only modify $SI, cannot touch $FN
2. $SI timestamp sub-seconds = exactly .000 - tools zero out 100ns precision; OS writes never do
3. EntryNumber clustered with recent files but $SI shows an old date - entry numbers don't lie
4. $I30 index slack - stale directory entries may preserve original pre-stomp timestamps, exposing backdating
5. PE compile time > $SI creation/modification time - logically impossible, definitively proves tampering
6. ShimCache/Amcache contradiction - if $SI modification time is older than what ShimCache recorded at first execution, timestamps were altered after first run