In the cat-and-mouse game of Red Teaming, the Blue Team has a superpower: Memory Forensics. Even if you never touch the disk (fileless malware), your code must exist in RAM to execute. This article explores how forensic analysts hunt you, so you can hide better.

Disk encryption helps, but RAM is the source of truth. It contains everything: running processes, open network connections, decrypted passwords, and chat logs. Analysis of this volatile data is often the only way to detect sophisticated APTs.

The Tool of Choice: Volatility

Volatility is the industry standard framework for extracting artifacts from raw memory dumps (from .mem, .dmp, or .vmss files).

  • Volatility 2: Python 2.7 based (Legacy, but huge plugin ecosystem).
  • Volatility 3: Python 3 based (Modern, faster, different syntax).

We will use Volatility 3 syntax for this guide.

python3 vol.py -f memory.dmp windows.info

What Are They Looking For?

1. The Process List (pslist / psscan)

Analysts look for anomalies in the process tree.

  • pslist: Walks the doubly-linked list of EPROCESS structures in the kernel. This is what Task Manager sees.
  • psscan: Scans memory for pool tags identifying EPROCESS blobs.

The Red Team take: If your malware performs DKOM (Direct Kernel Object Manipulation) to “unlink” itself from the active process list, it vanishes from pslist (Task Mgr) but still shows up in psscan. This discrepancy is a giant red flag.

Better OpSec: Don’t hide the process. Hide in a legitimate process (Process Injection/Hollowing).

2. Malicious Code Injection (malfind)

The malfind plugin scans for memory pages that are:

  1. Executable (PAGE_EXECUTE_READWRITE or RWX).
  2. Not backed by a file on disk (floating code).
  3. Start with assembly instructions (shellcode preamble).

The Red Team take: Standard VirtualAlloc shellcode loaders create RWX memory sections that light up like a Christmas tree in malfind.

Better OpSec: Use Module Stomping or Phantom DLL features. Load a legitimate DLL that you don’t need, and overwrite its .text section with your shellcode. The memory will look like it is backed by a file on disk (RX), evading malfind.

3. Network Connections (netscan)

netscan finds network artifacts (TCP endpoints, listeners).

  • Red Flag: powershell.exe connecting to port 4444 on a non-corporate IP.
  • Red Flag: svchost.exe (which should be a service) listening on a weird ephemeral port.

4. Command Line Arguments (cmdline)

windows.cmdline recovers the command strings used to launch processes.

  • Caught: powershell.exe -enc aW1hYmFkZ3V5... (Base64 encoded string).
  • Caught: mimikatz.exe "sekurlsa::logonpasswords" exit

Better OpSec: Argument Spoofing. Launch a process with benign arguments (notepad.exe file.txt), suspend it, rewrite the PEB to replace the arguments with your payload, then resume. Forensics will likely see the benign arguments in the PEB history.

Extracting Secrets

Memory forensics isn’t just about finding malware; it’s about finding credentials.

LSA Secrets

The Local Security Authority (LSA) process holds Kerberos tickets and NTLM hashes. windows.hashdump or windows.lidadump can extract these directly from the memory image, similar to how Mimikatz works on a live system.

Cleartext Passwords

Users type passwords into browsers, portals, and documents. These strings often linger in memory buffers long after the login is complete. Simply running strings memory.dmp | grep "password" is surprisingly effective.

Conclusion

You cannot be invisible in RAM. Your code has to live somewhere. But by understanding artifacts like the EPROCESS list, VAD tree, and memory permissions (RWX vs RX), you can blend into the noise.

Don’t just write malware. Dump the memory of your infected VM. Run Volatility on it. If you can find your beacon in 5 minutes, so can the Incident Response team.

UncleSp1d3r