> For the complete documentation index, see [llms.txt](https://breakpoint-journal.gitbook.io/breakpoint/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://breakpoint-journal.gitbook.io/breakpoint/malware-diaries/using-volatility-3-to-detect-sophisticated-malware.md).
# Using Volatility 3 to Detect Sophisticated Malware
I learned about Volatility 3 during a BSidesNYC 25' talk from [Andrew Case, Director of Research at Volexity](https://www.linkedin.com/in/andrewcase/). I thought this talk was cool right away. I have done my own forays into Windows malware development, so I wanted the blue-team view on how defenders can still catch modern tradecraft.
### Why Volatility 3 matters
Malware can avoid traces on disk, load code reflectively, and overwrite headers, or try to render on-disk artifacts useless. That's where Volatility comes into play - a memory forensics framework used to inspect what a system looked like in memory.
{% hint style="info" %}
Volatility first shipped in 2007. Volatility 3 is the current generation.
{% endhint %}
### Enumerating Process Memory
One of the first things worth inspecting is process memory layout through VADs.
{% code title="Enumerating process memory (kernel view)" %}
```bash
vol3 -f data.lime windows.vadinfo
```
{% endcode %}
When a memory region looks normal, it is often backed by a real file and uses protections you would expect from image-backed memory, such as `PAGE_EXECUTE_WRITECOPY`.
When that relationship breaks, it gets interesting.
### PWK (Plugins Worth Knowing)
| PLUGIN | DESCRIPTION |
| -------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: |
| windows.malfind | Finds suspiciously injected code.
It is especially useful for reflective DLL injection and shellcode that never followed a normal image loading path.
|
| hollowfind | Hollowfind is useful when you suspect process hollowing. The best short write-up I found is [Detecting deceptive hollowing techniques](https://cysinfo.com/detecting-deceptive-hollowing-techniques/). |
| windows.cmdline | This is not a detection plugin by itself, but it helps add context once you have a suspicious process. |
| windows.suspended\_threads | Suspended threads matter because they can be part of staging and evasion workflows.
This also ties into techniques like Dirty Vanity.
|
| windows.processghosting | This plugin is relevant for process ghosting cases and related file tampering tricks. |
| windows.vadinfo | Enumerating process memory (kernel view) |
{% code title="Running Volatility plugins" %}
```bash
# Using malfind to surface suspicious memory regions
vol.py -f data.lime windows.malfind
# Review process command lines on a sample
vol.py -f Emotet.lime windows.cmdline
# List threads for a specific PID
vol.py -f data.lime -r pretty -filters PID,836 windows.threads
# Enumerating process memory (kernel view)
vol3 -f data.lime windows.vadinfo
```
{% endcode %}
### Malware Techniques Awareness
#### Reflective DLL injection
Reflective DLL injection loads a DLL straight into memory. There is no normal disk-to-loader path to lean on. That is why memory analysis matters so much here.
#### Delete-on-close
Some Cobalt Strike workflows use `DeleteOnClose`. If the machine shuts down, the file disappears from disk. Memory still gives defenders a way to see what ran.
#### Base address mismatches
One detail I want to dig deeper into is the relationship between `SectionBaseAddress` and `ImageBaseAddress`. If those values stop making sense together, it can hint that something unusual happened during loading or mapping.
For more background, see [this process injection example](https://github.com/Offensive-Panda/ProcessInjectionTechniques/tree/main/NtCreateSection_MapViewOfSection).
#### Overwriting PE headers
Once a PE is loaded, the header is no longer needed in the same way it was during startup. Malware can overwrite the PE header to frustrate scanners and make analysis harder. That does not make it invisible. VADs and thread start addresses still help expose what is happening.
See [Deep dive into a dumped malware without a PE header](https://www.fortinet.com/blog/threat-research/deep-dive-into-a-dumped-malware-without-a-pe-header).
#### Process ghosting and transaction tampering
Process ghosting can load malicious code from a file that ends up marked as deleted. That breaks normal scanning paths because the OS blocks access to the deleted file handle. Transaction tampering creates a similar mismatch. Defenders may see clean content on disk while the malicious version is what actually runs in memory. In both cases, new VADs and suspicious threads become strong detection points.
### The Detection Mindset
If a region is executable, not file-backed, or protected in an unusual way, keep digging. That same logic still helps even when malware overwrites headers or tries to delete its own disk footprint. Overall, the flow is to...
{% stepper %}
{% step %}
Start with memory regions.
{% endstep %}
{% step %}
Check whether executable regions are backed by a real file.
{% endstep %}
{% step %}
Follow the threads into those regions
{% endstep %}
{% endstepper %}
### Resources
* Mark Your Calendar: APT41 Innovative Tactics
* [DEF CON 32 - Defeating EDR Evading Malware with Memory Forensics](https://www.youtube.com/watch?v=PmqvBe1LSZc\&t=1s)
* [Volexity resources](https://www.volexity.com/resources/)
For more information, reach out to
## Glossary
| TERM | DEFINITION |
| ---- | ----------------------------------------------------------------------------------------------------------------------- |
| VAD | Virtual Address Descriptor - A **VAD represents a contiguous range of virtual addresses** in a process’s address space. |
| | |
| | |