← back to writeups
forensics 2026-01-12 · 8 min read

Memory dump: finding the malicious process with Volatility3

4 GB of captured RAM, an attacker who cleaned up on disk. Memory, though, still remembers.

The disk was wiped, but the memory capture was taken while the implant was running. In forensics, that's where it all plays out: what was erased from disk still lives in RAM—connections, injected code, keys.

Map the processes

We start by listing the process tree and spotting anomalies: an inconsistent parent, a legitimately named executable launched from the wrong path, an orphan PID.

$ vol -f mem.raw windows.pstree
 ... 
 4820  612   svchost.exe   # parent = explorer.exe ?!  abnormal
       └─ 4996  cmd.exe
// the tell A legitimate svchost.exe always descends from services.exe. Here, parent = explorer.exe: someone named their implant after a system binary to blend into the list. False friend.

Confirm the injection

We look for executable and writable memory regions with no associated file—the classic signature of injected code:

$ vol -f mem.raw windows.malfind --pid 4820
 Process svchost.exe PID 4820
 Protection: PAGE_EXECUTE_READWRITE
 MZ header present, no mapped file  # -> injection

Trace back to the C2

The network connections at capture time point to the command infrastructure:

$ vol -f mem.raw windows.netscan | grep 4820
 TCP  10.0.3.14:52233 -> 185.xx.xx.xx:443  ESTABLISHED  4820

We dump the injected region with windows.vadinfo / windows.dumpfiles, then analyze it statically. A hard-coded string held the flag:

flag captured flag{m3m0ry_n3v3r_l13s_ev3n_wh3n_d1sk_d0es}

Takeaways

  • Process lineage is a strong signal: a legitimate name is worthless if the parent is fake.
  • malfind catches injection by looking for RWX with no backing file—a baseline reflex.
  • Capture RAM before powering off a compromised machine, always. Otherwise you lose half the story.