Fan Get Fame Fast

Inspiration

During a live incident the evidence is split across three places that don't talk to each other: the network capture, a memory image, and the disk. Each one needs its own tools and its own specialist. So the analyst ends up being a courier, taking one suspicious IP from Wireshark over to Volatility, then over to The Sleuth Kit, trying to get three half-answers to line up. It's slow, it's easy to get wrong, and the attacker isn't waiting around while you do it.

We built this because we were tired of watching good analysts spend their week writing reports instead of doing forensics.

What it does

Fan Get Fame Fast pulls the three forensic domains into one investigation. FAN handles the network side (PCAP), FAME handles memory, and FAST handles disk. The name is a bit of a joke but the split is real.

The part we actually care about is that the modules query each other. If FAN spots an odd outbound connection, Claude takes that straight to FAME and asks which process held the socket open, then to FAST to find what wrote that process to disk. Claude runs the whole back-and-forth, decides what to look at next, and stops when there's nothing left to pivot on.

Then it writes the report for you. You get one document with a management summary in plain language (no IPs, no port numbers, just what happened and what it cost) followed by the full technical body for the analysts. It comes out as Markdown, PDF, PowerPoint and Word, and the whole Claude session is saved as a hashed transcript so the reasoning is auditable later.

How we built it

It's three engines with Claude sitting in the middle.

FAN runs 22 protocol checks over a PCAP (DNS, TLS, HTTP, QUIC, ARP, DHCP and so on) plus Suricata and YARA, and pulls out the IPs, domains, certs and file hashes worth chasing. FAME is Volatility 3 — pslist, netscan, malfind, filescan, the usual plugins — with an optional baseline comparison if you give it a clean reference image. FAST is The Sleuth Kit, the EWF tools and bulk_extractor; it mounts the image read-only and pulls EVTX, registry, prefetch, MFT, the USN journal, SRUM and browser history.

A separate correlation step does the cross-matching: netscan to PCAP, process to deleted file, DNS to carved URL. Findings get written into a plain-Markdown Obsidian vault that builds up case to case, and we lean on MCP servers for OpenCTI and a Perplexity client when we need outside intel, checking the vault first before going to the web. The whole thing is Python on an Ubuntu 24.04 SIFT box.

Challenges we ran into

Getting the three modules to actually agree on a single event was harder than collecting the data in the first place. Parsing a PCAP or listing processes is easy; deciding that this socket, that process and that deleted binary are the same incident — and being able to back it up — took a real correlation pass and a rule that every conclusion has to name the evidence it came from.

We also spent a lot of time making sure we never touch the evidence. Saying "read-only" isn't enough, so we routed every write through one policy module that refuses anything outside the output folders, had the MCP servers reject writes under the evidence root independently, and made the shell scripts confirm the mounts are read-only before they run anything.

Linux memory images gave us grief too. They often don't have matching Volatility symbols, which normally just kills the analysis. We added a strings-based fallback so it keeps going instead of falling over.

And writing one report for two very different readers was fiddlier than expected. A CISO wants the business story with none of the identifiers; an analyst wants every port and hash. Getting both into one document without either side feeling shortchanged took a few rounds.

What we learned

The thing that actually made the difference was letting the modules ask each other questions instead of just running them in sequence and stapling the outputs together. Three separate reports don't save anyone time. One module asking another a question mid-investigation does.

We also learned the coordinator is only useful if it knows when to stop, otherwise it just keeps poking at evidence. Writing findings back into the vault paid off faster than we thought — the second case genuinely went quicker than the first. And we came to treat the hashed session transcript as part of the deliverable, not an afterthought, because a finding nobody can trace back isn't much use when it has to hold up later.

What's next

We want to generate separate report versions per audience (CISO, legal, law enforcement, IT, audit) off the same investigation instead of one combined document. After that, more evidence types — cloud, containers, mobile images — into the same cross-questioning setup. We'd also like tighter OpenCTI sync so the vault gets sharper across a whole team, a faster path for surfacing containment-worthy findings mid-incident rather than only in the post-mortem, and a set of ready-made baselines for common OS builds so the memory diffing works without setup.