Memory Forensic Artifacts: The Complete List of Forensic Evidence Extracted from RAM

A RAM image is the single richest source in modern digital forensics. Even if an attacker runs without leaving a trace on disk, for every second it runs the operating system keeps dozens of structures recording its presence. This article is the natural continuation of RAM Analysis with the Volatility Framework: there we introduced the tool, here we open up the specific artifact categories that the tool finds one by one. Which structure lives where, which attack technique it gives away, which Volatility plugin extracts it, and how it is reported in court.

The sources have been kept open: Volatility Foundation, MITRE ATT&CK, SANS DFIR, NIST SP 800-86 (Guide to Integrating Forensic Techniques into Incident Response), Sysinternals / Windows Internals and Microsoft Defender Threat Intelligence publications.

1. Process Tree and Parent / Child Anomalies

In RAM, every running process is represented by an EPROCESS structure. Volatility's windows.pstree plugin lays out these structures in a tree. What is forensically critical is not the list itself but the naturalness of the parent-child relationship.

A natural example: explorer.exe -> chrome.exe. A suspicious example: winword.exe -> powershell.exe -> rundll32.exe. This chain matches MITRE ATT&CK techniques T1059.001 (PowerShell) and T1218 (Signed Binary Proxy Execution) exactly. An Office application spawning PowerShell is the classic signature of macro-based initial access.

In addition, the delta between pslist and psscan reveals processes hidden via DKOM (Direct Kernel Object Manipulation). pslist reads the active linked list, while psscan performs pool tag scanning. If there is a difference between the two, the difference itself is a finding.

During process tree analysis, three additional points must always be documented in the report: the process start time (CreateTime), the session id (SessionId), and the token integrity level. A high integrity (System) process being opened by a medium integrity (Medium) user process is a sign of UAC bypass or token impersonation (T1134). When these three fields are evaluated together, the privilege escalation stage of the attack is mapped retroactively to which process it passed through.

2. Loaded Modules and DLL Injection

The DLLs loaded by each process are recorded twice, via PEB.Ldr and the VAD. windows.dlllist reads the PEB, while windows.ldrmodules compares the three lists (InLoad, InMem, InInit). If a module exists in the VAD but not in the PEB list, it is the classic finding of reflective DLL injection (MITRE T1055.001).

The malfind plugin scans page protections. Memory regions that are PAGE_EXECUTE_READWRITE permitted and not backed by any file are a sign of shellcode or process hollowing (T1055.012). The first bytes of the region are usually MZ or directly x86 prologues such as 0x55 0x8B 0xEC (push ebp; mov ebp,esp).

3. Network Connections (TCP / UDP + IPv6)

windows.netscan scans the pool structures of Tcpip.sys and captures residue even after a connection is closed. Memory-only C2 traffic that is not in disk logs appears here. Each line: local IP/port, remote IP/port, state (ESTABLISHED, CLOSE_WAIT, LISTENING), owner process PID, protocol (TCPv4, TCPv6, UDPv4, UDPv6).

Forensic value: a svchost.exe instance with a connection going to 4444, 8443 or a foreign ASN is enough to trigger the IR Playbook. IPv6 must not be forgotten; attackers use Teredo / 6to4 tunnels to bypass IPv4-focused detection.

4. Open File Handles and Mutexes

windows.handles lists all Object Manager handles held by each process: File, Key, Mutant, Event, Section, Token. Two types are especially valuable forensically:

  • Mutex (Mutant) names: Malware opens a fixed mutex to guarantee a single instance. Signatures such as Global\\_QM_<id>, RstrtMgr<guid> are matched to a family in Microsoft Defender Threat Intelligence reports.
  • File handles: Even if the disk is deleted, if the handle is still open, the file can be recovered from memory with the dumpfiles plugin. The victim files that ransomware keeps open during encryption can be extracted whole with this method.

5. Registry Hives, the In-Memory Copy

Windows maps active registry hives into RAM for performance. windows.registry.hivelist lists the mapped hives, printkey reads a specific key, and userassist extracts the GUI programs the user ran as ROT13 encrypted.

Critical keys:

  • Run, RunOnce, Image File Execution Options (T1547.001 persistence)
  • Services (T1543.003)
  • AppCompatCache / ShimCache (program execution evidence)
  • UserAssist (user interaction evidence, enters the timeline in the expert report)

Even if the hive file on disk has been edited by the attacker, the copy in RAM usually preserves the old clean state or the live malicious state.

6. Command-Line History and the PSReadline Buffer

windows.cmdline gives the startup arguments of each process. But the real treasure is the PowerShell ConsoleHost_history and the PSReadline buffer. PSReadline holds every line the user typed (including deleted and canceled ones) in the process memory.

With a YARA rule or simple string search, signatures such as Invoke-Expression, IEX, FromBase64String, DownloadString, Add-MpPreference -ExclusionPath are caught. Microsoft Defender Threat Intelligence classifies these indicators in the AMSI bypass and fileless execution set.

7. Browser Cache and Cookies, the RAM Version

While rendering a page, Chrome, Edge and Firefox hold decoded HTML, JavaScript, cookies, session tokens, and even auto-fill form values in the process heap. Even if the disk cache is cleared when the browser is closed, traces remain in RAM.

Method: a memdump of the relevant chrome.exe or msedge.exe PID is taken, and URL, JWT, Set-Cookie, Authorization: Bearer patterns are scanned with bulk_extractor or strings. In spyware analysis this method is parallel on mobile devices as well.

8. Cryptographic Keys: Master Keys, Session Keys, BitLocker FVEK

RAM is the only place where the plaintext form of the key is found; the disk always keeps it encrypted. Volatility's windows.lsadump, windows.cachedump and windows.hashdump plugins extract from LSASS memory.

  • DPAPI Master Key: The master key of all the user's encrypted credentials.
  • TLS Session Key: The pre-master secret held by SCHANNEL; when combined with a pcap, HTTPS traffic can be decrypted.
  • BitLocker FVEK (Full Volume Encryption Key): It is in RAM while the system is on. It is extracted with bulk_extractor -e aes or MemProcFS. If a live image is not taken before the device is powered off, this key is lost forever. This is the technical justification for the "do not power off the device, do not put it into hibernate" rule in the first 24 hours after ransomware.

9. Clipboard Content

The Windows clipboard is stored within the user session of win32k.sys. The windows.clipboard plugin dumps the last copied text. Its forensic value is high: the password the victim just copied, a crypto wallet address, or a wallet address modified by clipper malware (T1115) appears here.

10. URL and Path Strings, YARA Rules

Raw strings output is noisy. Instead, targeted searches are performed with YARA rules. Typical rule sets:

  • C2 domain patterns (DGA signatures)
  • Base64 PowerShell payload beginnings (JABzAD0A, cwBlAHQA)
  • Mimikatz strings (sekurlsa::logonpasswords, gentilkiwi)
  • Cobalt Strike beacon signatures (%s as %s\\%s: %d)

The SANS DFIR FOR508 curriculum standardizes this methodology: first process-aware search (only suspicious PIDs), then a global scan.

11. The Plaintext Form of Encrypted Messaging Apps in RAM

This category is the most sensitive from a KVKK and privacy standpoint, so a court order or explicit consent is mandatory. But technically it is possible:

  • WhatsApp Desktop: Electron-based; when messages are rendered they are found as UTF-16 plaintext in the renderer process memory.
  • Signal Desktop: The SQLite database is encrypted with SQLCipher, but the key is protected via config.json with DPAPI and is in RAM while the user session is open.
  • Telegram Desktop: The tdata folder is encrypted with a local key; while the session is open the key is again in memory.

The method is standard: a process memdump, then a string search for the SQLite header (SQLite format 3) or conversation fragments. The process is carried out under the chain of custody rules of the digital forensics process.

12. VAD (Virtual Address Descriptor) Tree

Each process manages its virtual address space as a VAD tree. windows.vadinfo lists the start-end address of each region, its protection flag, and the mapped file. vadwalk verifies the integrity of the tree.

Forensic use: large regions that are anonymous, PAGE_EXECUTE_READWRITE permitted, and have no file backing are candidates for injected code. vaddump writes that region to a file, then the PE header is scanned with pescan or pestudio. In process hollowing the original .text segment does not match byte-for-byte with the binary on disk; this difference itself is a finding.

13. Cached Credentials and LSASS Dump

lsass.exe holds the credentials of all logged-in users in memory: NTLM hash, Kerberos TGT, plaintext (if old WDigest is enabled). It is the exact definition of MITRE T1003.001.

On the forensic side the aim is to prove not the attack but the aftermath of the attack: if the attacker took a dump from lsass, the dump file itself (usually with a .dmp extension) is mostly left under %TEMP%, C:\\Windows\\Temp\\, \\ProgramData\\. If it still has an open handle in RAM, it is caught with handles | grep lsass.

14. Mimikatz Traces: NTLM Hash and Kerberos Ticket

When Mimikatz runs in memory, its own string signatures and fragments of the output it obtained remain in RAM. Typical patterns searched with a YARA rule: mimikatz, gentilkiwi, sekurlsa::, kerberos::list, lsadump::sam.

Kerberos tickets are extracted as TGT/TGS in .kirbi format. If a ticket's lifetime field is close to 10 years, it means a Golden Ticket (T1558.001), signed with the domain controller's krbtgt hash. The moment of detection triggers the "reset the krbtgt password twice" step in the IR playbook.

15. PowerShell Decoded Payload

The attackers' favorite encoding chain: Base64 + Gzip + IEX. On disk the command line appears as -enc <base64> but the real payload is decoded at runtime and written as a string to the heap.

Extraction method: a pwsh.exe / powershell.exe memdump, then reaching the final command line by repeating the From-Base64 | gunzip chain over the RAM content. The resulting payload is typically an Empire, Covenant, Sliver or Cobalt Strike stager.

16. Network Beacon and C2 Traffic Indicators

Two separate traces of beacon behavior are in RAM:

  1. Network: In the netscan output, short-lived connections going to the same remote IP at regular intervals (jitter may have been added).
  2. Memory: The Cobalt Strike beacon holds its own config block in the heap as 0x2e2e2e2e or 0x69696969 XOR'd. Open-source tools such as CobaltStrikeScan and 1768.py decode this block and extract the C2 URL, sleep time, jitter, watermark.

Microsoft Defender Threat Intelligence matches the watermark value to the operator group; this is a finding that enters the "Actor Assessment" section of the expert report in the attribution process.

The parameters extracted from the beacon config block carry IOC value on their own: sleep time, jitter percentage, named pipe name, malleable C2 profile, spawnto_x86 and spawnto_x64 paths. Since the combination of these fields usually belongs to a single campaign, a match with past cases in threat intel pools can be achieved. This match shows whether the same actor is also active at other organizations, and a decision is made on whether coordinated notification to the relevant organizations is needed.

17. DSET Memory Lab, Qualitative Use

The memory forensic station in DSET's Hacettepe Teknokent Ankara laboratory consists of three components: a .raw image pool pulled over a write-blocker, an analysis workstation running Volatility 3, and a separate scanning node for the YARA + bulk_extractor chain. All findings are linked to the chain of custody with SHA-256 hashes and timestamps, as required by our digital forensics process. What we observe in practice: the breaking point of a case is usually not a file on disk, but an open handle in RAM, a mutex name, or a beacon config block.

18. Frequently Asked Questions

1. How many hours is a RAM image valid? If the device keeps running, the content changes every second. It is a "snapshot"; two images of the same device taken at two different times are reported as two different pieces of evidence.

2. Is reading encrypted messages from RAM legal? A court order or the user's explicit consent is required. Analysis done without a basis under KVKK art. 5 and the Criminal Procedure Code loses its evidentiary value.

3. What happens if a BitLocker-enabled device is powered off? The FVEK is erased from RAM. When the device is turned on again, the disk cannot be read without the recovery key or TPM. The rule: do not power off a live device, take a RAM image first.

4. Does taking an LSASS dump trigger an antivirus alert? Modern EDRs monitor the MiniDumpWriteDump call. For this reason, in forensic work not a local agent but Velociraptor, DumpIt or kernel-mode WinPMEM is used.

5. How is Linux support in Volatility 3? Critical in banker / SSH server cases. The symbol table (ISF) must match the target kernel version exactly; if it does not, the plugins return empty.

6. How large is a memory image? As large as the physical RAM. A ~32 GB raw image comes out of a system with 32 GB RAM. It is stored uncompressed; compression is done after the hash chain.

7. Are RAM findings court evidence on their own? They are, but correlation strengthens them. A RAM finding + a disk artifact + a network log is the standard trio. The expert report presents this trio separately under the "Findings" heading.

8. Does the hibernation file (hiberfil.sys) replace a RAM image? Partly. It is a compressed copy of the memory at the moment the system entered hibernation. volatility can read this file directly, but anything after that moment is lost.

Conclusion

Every artifact in RAM is part of a story: the process tree tells how the attacker started, the network connections who it talked to, the LSASS / mimikatz traces what it stole, the beacon config who the operator is. Collecting these structures in the right order and placing them in the chain of custody is the backbone of modern digital forensics.

At DSET, in our memory forensic laboratory at Hacettepe Teknokent Ankara, we run corporate cases with an analysis pipeline based on Volatility 3, Rekall, MemProcFS and YARA. For a live system after ransomware, a suspected insider, an APT suspicion, or the examination of a BitLocker-enabled encrypted device, you can reach our digital forensics team at +90 536 662 38 09.