Fileless malware does not live in a file you can quarantine. It runs inside legitimate processes, decrypts its payload in RAM, and often leaves the disk almost untouched. As endpoint detection has gotten better at watching the disk, attackers have moved into memory, where evidence is richest but shortest-lived. Memory forensics is how you recover the truth that never hit the platter, and in 2026 it is no longer optional for serious incident response.
What is fileless malware, and why does it defeat disk-based tools?
Fileless malware executes primarily in RAM, abusing legitimate binaries and interpreters instead of dropping an executable to disk. Because signature scanners and dead-box forensics focus on files, an in-memory implant can inject, persist, and beacon while leaving little on disk. Memory is where the evidence actually lives.
- ▸Living-off-the-land techniques abuse signed system binaries (LOLBins) so nothing malicious is written to disk.
- ▸Reflective loading maps a DLL or .NET assembly directly into a process without using the normal loader, so it never appears as a file on disk.
- ▸Process injection and hollowing (MITRE ATT&CK T1055, T1620) run attacker code inside trusted processes such as explorer.exe or svchost.exe.
- ▸Registry-resident and script-based payloads stage encoded blobs in the registry or WMI, then execute them through powershell.exe or mshta.exe in memory.
What lives only in memory that you cannot recover from disk?
Volatile memory holds the decrypted, running state of a machine: injected code, deobfuscated payloads, live network sockets, full command lines, and secrets. None of it survives a reboot, and most of it never touches disk, so a dead-box image alone will miss it. This is exactly why Memory Forensics in Practice: From Acquisition to Answers treats RAM as primary evidence.
- ▸Injected and unbacked executable regions that no file on disk explains.
- ▸Decrypted second-stage payloads and unpacked shellcode that are encrypted at rest.
- ▸Established connections and listening sockets, with the owning process and port.
- ▸Full command lines and environment variables, including what was passed to interpreters.
- ▸Loaded-but-unlinked modules hidden from the normal module lists.
- ▸Credentials in memory: cached passwords, Kerberos tickets, and NTLM hashes.
- ▸Console and PowerShell history, clipboard, and kernel hook structures left by rootkits.
How do you acquire memory without corrupting the evidence?
Capture volatile data first, following the order of volatility, and use a tool that writes its output to external media, never the target disk. Hash the image immediately, record the acquisition time and tool version, and also grab the page file and hibernation file so paged-out evidence is recoverable.
- ▸Windows: WinPmem, Magnet RAM Capture, Belkasoft Live RAM Capturer, or Comae DumpIt.
- ▸Linux: AVML (Microsoft) produces a portable image; LiME loads as a kernel module.
- ▸Virtual machines: pause and copy the .vmem and .vmsn snapshot files. This is the cleanest capture, with zero footprint inside the guest.
- ▸At scale: Velociraptor can trigger memory acquisition across a whole fleet remotely.
- ▸Caveats: Virtualization-Based Security and Credential Guard reduce what is readable; large RAM means large images; always record a SHA-256 hash of the output.
Which tools analyze a memory image in 2026?
Volatility 3 is the reference framework, driven by symbol tables (ISF) rather than the hard-coded profiles of the Volatility 2 era. MemProcFS mounts an image as a browsable filesystem for very fast triage. Add YARA for signature sweeps of memory and bulk_extractor for strings, keys, and network artifacts.
- ▸Volatility 3 for plugin-driven analysis with Windows PDB symbols and Linux banners.
- ▸MemProcFS to mount RAM as a drive and explore processes as folders.
- ▸YARA against memory to match known implant and shellcode signatures in live regions.
- ▸Velociraptor for live in-memory inspection when a full dump is impractical.
- ▸bulk_extractor and strings to pull URLs, credentials, and crypto material fast.
What does a fast memory-triage workflow look like?
Work in a fixed order: process picture, then network, then injected code, then persistence, then dump-and-analyze. A disciplined 20-minute triage answers the first questions, what ran, what talked to the network, what was injected, and what to preserve, before the box is reimaged.
- ▸Processes: windows.pslist, windows.pstree, and windows.psscan to reveal hidden or unlinked processes.
- ▸Command lines: windows.cmdline for the full arguments passed to each process.
- ▸Network: windows.netscan for sockets and connections tied to owning processes.
- ▸Injection: windows.malfind and windows.ldrmodules to flag unbacked executable memory.
- ▸Persistence and services: windows.svcscan and the windows.registry plugins.
- ▸Preserve the suspect: dump it with windows.memmap, then run YARA and strings, and build a timeline with windows.mftscan and event-log parsing.
How do you spot process injection and hollowing in a dump?
Injection appears as executable memory that no file backs. In Volatility 3, malfind flags private regions marked read-write-execute that contain MZ headers or shellcode; ldrmodules reveals modules present in memory but missing from the loaded-module lists; and thread start addresses outside any mapped image betray hollowing.
- ▸malfind: private, committed, RWX memory containing a PE header or executable bytes.
- ▸ldrmodules: a three-list mismatch, where a module is loaded but unlinked from one or more lists.
- ▸Hollowing: the on-disk image base does not match the in-memory image, or the entry point is unbacked.
- ▸Anomalous threads: thread start addresses that fall outside any legitimate module.
- ▸Parent spoofing: an implausible parent process ID for the injected host.
How do you tell a false positive from a real in-memory threat?
Not every read-write-execute region is malicious. Just-in-time compilers in Java, .NET, and modern browsers legitimately allocate executable memory, and some commercial packers look suspicious. Confirm a real threat by correlating unbacked code with network activity, injection into an unrelated process, and a payload that fails signature and reputation checks.
- ▸Known-benign RWX: JIT engines (the JVM, the .NET CLR, and V8) and some anti-cheat software allocate executable pages by design.
- ▸Corroborate, do not convict on one signal: pair a malfind hit with a suspicious parent, an outbound connection, or a YARA match before escalating.
- ▸Reputation and signing: hash the owning image and check its authenticode status and how common it is across your estate.
- ▸Baseline your environment: what is normal on a developer laptop is alarming on a domain controller, so tune expectations per host role.
How is memory forensics different in cloud and containers?
In cloud and container estates there is no console and instances are ephemeral, so you must capture before termination and automate it. On Linux VMs, AVML produces a portable image; containers share the host kernel, so you capture at the node or via eBPF; and you must snapshot an instance before autoscaling scales it away.
- ▸Cloud VMs: run AVML through your orchestration tool, or read /proc/kcore where available.
- ▸Containers: capture at the host level, since the container is just host namespaces.
- ▸Runtime capture: eBPF sensors observe in-memory behavior live, as covered in Runtime Security with eBPF: Detecting Kubernetes Threats in 2026.
- ▸Preserve before you lose it: snapshot the instance before eradication, a discipline reinforced in Cloud Incident Response: Why On-Prem Playbooks Fail in AWS.
How TuniCyberLabs helps
We build memory forensics into incident response instead of bolting it on during a crisis. That means acquisition runbooks your responders can execute under pressure, Velociraptor-based fleet collection, Volatility 3 and MemProcFS analysis, and detections fed back into the SOC so the same implant is caught faster next time, the loop described in Incident Response Playbooks That Teams Actually Use. Explore our security services to see how this fits your environment.
Facing a suspected in-memory intrusion, or want a memory-forensics capability before you need it? Talk to our team.