a first pass DFIR triage flow using free tools

you don't need a five figure forensic suite to start figuring out what happened on a compromised box. you need a plan, a hash, and a handful of free tools that have been battle tested for decades. here's a first pass triage flow you can run on a disk image and a memory dump with nothing but open source software, and more importantly, why each step matters for defenders.

step one: hash it before you touch it

the very first thing you do with any piece of evidence, disk image or memory dump, is hash it. this isn't ceremony, it's the thing that lets you or anyone else later prove the file you analyzed is the exact file you collected.

sha256sum evidence.img

write that hash down somewhere outside the machine you're working on. if you're doing this for anything that might end up in a report, a legal proceeding, or an hr case, chain of custody starts right here and it starts with a hash, not a screenshot.

step two: map the disk before you go digging

once you know the image is intact, figure out what's actually on it. mmls reads the partition table and shows you the layout, where each partition starts and ends, what filesystem it claims to be. skipping this step is how people miss entire hidden or unallocated partitions.

from there, fls walks the filesystem and lists files, including deleted ones that are still sitting in unallocated space waiting to be overwritten. this is usually where you find the thing the attacker thought they cleaned up. deleting a file just removes the pointer, not the data, at least not right away.

step three: carve the file and read its metadata

say fls turns up an interesting deleted file. icat lets you pull that file back out by its inode number, even though the filesystem no longer "sees" it as existing. once you've carved it out, run exiftool against it.

exiftool reads embedded metadata: camera model, software used to create the file, timestamps, and if it's a photo, sometimes gps coordinates baked right into the exif data. this is a huge deal for defenders investigating insider incidents or data exfiltration, because a photo or document can quietly tell you where it was created, not just when.

step four: don't ignore memory

disk tells you what was saved. memory tells you what was happening right now, which is often where the real story is. malware that lives entirely in ram, injected processes, active network connections, none of that reliably shows up on disk.

run volatility against a memory image with something like:

vol.py -f memory.img windows.pslist

pslist gives you the process list at the moment of capture: process names, pids, parent pids. look for processes that shouldn't exist, weird parent-child relationships (a process spawned from something that never spawns processes), or things running from odd paths like temp folders.

step five: grep for the stuff nobody meant to leave behind

plaintext strings in memory can be an absolute goldmine, and not in a good way if it's your own system. credentials, tokens, and session data often sit in ram in cleartext long after they've been "used."

strings memory.img | grep -i "password"

if you find live credentials sitting in memory on a machine you're investigating, that's your answer to "why did the attacker have valid creds." memory is often the missing piece disk analysis alone can't give you.

the takeaway

this flow, hash, map the disk, list files including deleted ones, carve and check metadata, then pivot to memory for process activity and leaked secrets, is the same logic expensive commercial suites are built on. the tools are free, the methodology is what actually matters.

for your own systems, the defensive move is to build this muscle before you need it. know how to hash and image a drive, keep a memory capture tool ready to go, and practice this flow on a throwaway vm so incident response day isn't the first time you've run these commands. and if you're worried about leaked creds in memory, the fix is boring but real: shorter session lifetimes, credential rotation, and locking down who can even get physical or remote access to pull a memory image in the first place.