Volatility Plugins — Plugin windows.malfind Let’s Talk About it

13 minutes ago
4 min read

Let’s get into Second Plugin windows.malfind — my favorite plugin when I want to quickly spot weird injected memory in a process.

What malfind Actually Does

malfind looks for two suspicious things inside process memory:

Memory region is executable→ PAGE_EXECUTE_READWRITE or similar permissions→ This is already a red flag because legit apps rarely need RWX memory.
Memory region is NOT mapped to a file on disk→ Meaning the process has code in memory that didn’t come from an EXE or DLL on the system.

If malfind finds both together… boom! You have a potential injected section.

And if you include --dump-dir, malfind will dump that entire memory section into files so you can reverse, scan, or investigate further.

What malfind Shows You

Volatility 3 gives you useful columns like:

PID
Process Name
Start/End VPN (basically the memory range)
Protection (this is where RWX shows up)
PrivateMemory (0 = mapped, 1 = private → injected stuff is usually private)
CommitCharge
Tag (pool tag)

But honestly, the real magic is the hex + assembly dump of the first 64 bytes.

This part tells you everything if you know what you’re looking at.

Checking for Real Code (The Final Injection Test)

malfind purposely doesn’t confirm whether the bytes are actual code — that’s the analyst’s job.

So your last check is: Does the memory actually contain real executable code?

You look for:

MZ header (4D 5A)

→ Means a PE file (EXE/DLL) was injected reflectively.

Function prologue patterns

When you run malfind and found EBP and ESP it often indicates that some part of the memory that is traditionally not executable (such as the stack) now contains executable code.

On x86:

PUSH EBP  
MOV EBP, ESP

On x64:a bunch of pushes like:

push rbp
mov  rbp, rsp
push rdi
push rsi
...

[rax], al) → probably false positive.

malfind gives a lot of false positives, so this final step is critical.

Another Example: OneDrive False Positive

malfind flagged a section inside OneDrive.exe. Looked scary because permissions were RWX.

But the assembly dump was:

00 00 00 00 00 00 ...

Disassembler tried to interpret it as:

add [rax], al
add [rax], al
add [rax], al
...

This means garbage. Not real code. Not injection.

So this is one of those common false positives that malfind throws around.

The Evolution of Code Injection:

LoadLibrary → Reflective Injection → Header Cleaning

Load Library: - (A load library contains programs ready to be executed)

Originally, malware injected code using LoadLibrary. Easy to detect, easy to monitor.

Then came frameworks like Metasploit using reflective DLL injection, which bypasses Windows loader APIs completely.

Tools like malfind were built specifically to catch reflective injection — and they did a brilliant job.

So attackers adapted again.

Malware started wiping its PE headers.

CoreFlood botnet cleared the first 4096 bytes of its injected DLL.
APT29, APT32, use Cobalt Strike loaders that erase headers after loading.
Some newer families pad their shellcode deeper in the page so the first 64 bytes look harmless.

This is a huge problem because malfind only shows you a tiny preview (64 bytes).If the malicious code sits after the preview window, the output looks like a false positive.

Bypassing RWX Detection (Attackers Getting Clever)

malfind heavily relies on detecting EXECUTE_READWRITE memory. So, malware authors figured out an elegant bypass:

Allocate memory as READWRITE
Write payload into it
Flip permissions to EXECUTE_READ only at execution time

PEB Manipulation — A Common Target for Stealth

Because the Process Environment Block (PEB) is userland and easy to modify, attackers love tampering with it:

Unlinking entries from the loaded DLL lists
Rewriting DLL names or paths
Masquerading the process name
Using PowerShell to patch fields directly

If your detection tool trusts the PEB blindly… you’re already in trouble.

Advanced Techniques: Stomping, Patching & Camouflage

Newer malware families move beyond simple injections:

Module Stomping

Overwrite a legitimate DLL in memory with malicious code.

Patching Legitimate Code

Replace functions inside real modules with attacker logic.

These make the injected payload look like it belongs to a real module.

How We Fight Back: Dump Everything

When in doubt, dump the whole region.

Using --dump with malfind gives you a full memory section, not just the misleading 64-byte preview. Once dumped, you can:

Run strings
Scan with antivirus
Use YARA rules
Load into IDA/Ghidra
Compare with known-good modules

Reverse engineering is the most accurate option — but also the most expensive. And yes, attackers know this.

Reality Check: Not All Malware Uses Fancy Techniques

Don’t overthink it.

Most real-world injections are still:

Reflective DLL injection
Process hollowing
Remote thread injection
Shellcode in RWX pages

Why?

Because these techniques are simple, tested, reliable, and still bypass many defenses.

So while we prepare for the future, remember the majority of cases you’ll see are still detectable using standard techniques.

-------------------------------------------------------------------------------------------------------------

The Memory Layout Matters (And Helps You Catch Stealthy Stuff)

Windows process memory has three major areas:

1. Private Memory

Allocated via VirtualAlloc
Contains stack, heap, app data
Usually READWRITE
Should NEVER contain real executable code

If you see RX or RWX here → high suspicion.

2. Shareable (Mapped) Memory

Contains mapped files like .dat, .mui
Mostly READONLY
Rarely executable

3. Image Memory (Executable Section)

Legit place for EXEs and DLLs
Usually EXECUTE_READ or EXECUTE_WRITECOPY
Rarely RWX

Important insight from Forrest Orr’s memory research:

Memory Type	Normal RWX Rate
Private	0.24%
Shareable	0.014%
Image	0.01%

RWX almost NEVER occurs in legitimate scenarios.

Even RX pages outside of image memory should raise eyebrows.

Why This Matters for Injection Detection

Most attacks — hollowing, reflective injection, manual mapping — end up placing executable code in the wrong part of memory:

Hollowing → executable code ends up in private memory
Doppelganging → ends up in shareable memory
Reflective DLL → RWX pages created temporarily

Your job is to understand:

Where should executable code exist, and where SHOULD it never exist?

If you master this, you’ll detect even advanced injection without needing heavy automation.

Because memory forensics is about recognizing what is normal — and what isn't.