This is a forensics triage tool I wrote while studying for the GCFE. You give it a copy of a computer's files and it hashes everything, builds a timeline, spots files in disguise and faked dates, recovers deleted files from a raw disk image, and keeps a tamper-evident log of what it did. I built it so that someone who is not a forensics expert can see quickly what happened on a machine, and trust that the evidence was not changed along the way. The case you are looking at is invented (an employee copying files to a USB stick), so nothing real is exposed.

Try this in 60 seconds

1. Start on "The case" tab. Read the Case summary card, then the "What happened, in order" strip on the right. It tells the story in a short list: an employee gathers files, renames an archive to look like a photo, copies it to a USB stick and deletes the originals. The "Show the other 9" button under it lists the rest.

   Take me there

2. Click the red stamp marked "1 critical". It jumps to "What I found" with just one finding: invoice_template.pdf, a file whose hash is on a known-bad list. Notice the "1 of 20 findings" count, then click "Start over" to see all twenty.

   Take me there

3. Click the card "Extension does not match content: holiday_photos_2025.jpg". A panel opens with "In short", "Why I flagged it" and "What to do about it". The file is named like a photo but its contents are a ZIP archive. Under "Files involved", click holiday_photos_2025.jpg to see its three hashes (MD5, SHA-1, SHA-256) and a line saying an identical copy was recovered from deleted space. Then press Close.

   Take me there

4. Open "More of the file" in the left-hand tabs, then "Deleted, then found", and click the first row, CF-001. It is a 6,342 byte ZIP pulled out of the raw disk image. The panel says it is the same as holiday_photos_2025.jpg on disk, matches a Recycle Bin record for proj_backup.zip, and holds three files. So the "photo" is the deleted archive.

   Take me there

5. In "More of the file", open "Did I change anything?" and click "Check the chain here". It says the chain is intact. Now click "Pretend someone edited an entry", then "Check the chain here" again. It reports the chain is broken at entry 3. Click "Undo" to put it back. That is how you can tell a log was edited.

   Take me there

Words you will see

Triage

A fast first pass to find what matters before anyone starts a slow, deep investigation.

Evidence, read-only

The copy of the files being examined. The tool opens it so it can look but not change anything.

Hash (MD5, SHA-1, SHA-256)

A fingerprint worked out from a file's bytes. Change one byte and the fingerprint changes completely, so two files with the same fingerprint are the same file.

Known-bad hash

A fingerprint on a list of files already known to be malicious. If a file matches, it is that file, whatever it is called.

Chain of custody

The written record of who handled the evidence and when, so you can show it was not altered.

Hash chain

How my custody log protects itself. Each entry carries the fingerprint of the entry before it, so editing one entry breaks every entry after it.

Timestomping

Changing a file's dates to hide when it was really made or edited. I compare two sets of dates ($STANDARD_INFORMATION and $FILE_NAME) because one of them is harder to fake.

MACB

The four times a file keeps: Modified, Accessed, Changed (its record) and Born (created). It is a column on the Timeline.

File in disguise

A file whose name says one thing and whose first bytes say another, like a ZIP named .jpg. The first bytes are called the signature.

File carving

Recovering deleted files by scanning the raw disk for the start of known file types, without needing the file table.

Unallocated space

Parts of a disk not assigned to any file. Deleted data can sit there for a long time.

MFT

The Windows file index. It still has entries for deleted files, which is how I match recovered files to names.

Prefetch

A Windows record of which programs have run and how often. It is how I know the archive tool and the secure-delete tool ran.

IOC (indicator of compromise)

A clue such as an IP address, web address, email or hash that points to something bad. They are listed on the Clues tab.

MITRE ATT&CK

A public catalogue of attacker techniques, each with an ID like T1036. I tag each finding with the ones it looks like.

UTC

The world standard time. Every time on this page uses it, so nothing depends on a time zone.

Everything that happened to the files, per hour and coloured by where the timestamp came from (UTC). Click a bar to list its events, click it again to let go.

Nothing matches those filters.

All the files under the evidence folder, each with MD5, SHA-1 and SHA-256, what the bytes say it is, and any red flags. Click a row for the hashes, the dates and my reasoning.

No files match.

IP addresses, web addresses, emails, hashes and Windows paths pulled out of file contents, recovered files and the browser database (these are what people call IOCs). Addresses from documentation ranges and private ranges are labelled, not hidden.

No clues match.

I scanned the raw disk image for the first bytes of JPEG, PNG, PDF and ZIP files and then checked that the rest of the file really holds together, instead of trusting a file table that may be gone. Solid green means the structure checks out to the end. Amber means only part of it did.

Custody log

Every entry stores the SHA-256 of the entry before it, like numbered pages with the previous page's fingerprint written on the next one. The button below recalculates all of it in your browser, using the same rules as the Python tool.

What the machine remembers besides files: USB sticks, programs that ran, documents opened, sites visited, things that were deleted.

ATT&CK is a public catalogue of attacker techniques. Each finding is tagged with the ones it looks like. Click a row to see only those findings.