How do you spot Linux malware in a memory image?

To spot Linux malware in a memory image, list processes and kernel modules several different ways, then look for disagreement, injected memory regions, odd network sockets and tampered kernel tables. Volatility 3 is the open source framework most responders use, and it ships plugins for each of these checks.

Why look at memory at all?

Disk shows what was installed. Memory shows what is running. Malware that deletes its binary after launch, runs inside another process, or hides a kernel module can leave an empty disk and a busy memory image. That is why responders capture RAM before they reboot a suspect host.

A capture is a file. The Volatility 3 documentation describes it as a set of layers: raw physical memory at the bottom, and translation layers on top that map virtual addresses to physical ones. It mentions the LiME file format as one way a Linux image is stored. The framework needs a symbol table that matches the target kernel, so note the exact kernel version when you capture, or you may be unable to parse the image later.

Which plugins do the work?

The Volatility 3 Linux plugin index lists these relevant ones:

• linux.pslist and linux.psscan both enumerate tasks, by different methods.
• linux.lsmod lists loaded kernel modules, and linux.malware.hidden_modules looks for ones that are not in that list.
• linux.malware.check_syscall, check_idt, check_modules, check_creds and check_afinfo test kernel structures for tampering.
• linux.malware.malfind looks for suspicious memory regions in processes.
• linux.malware.process_spoofing targets processes that misreport themselves.
• linux.malware.netfilter, keyboard_notifiers and tty_check cover other hooks.
• linux.sockstat lists sockets and linux.bash recovers shell history from memory.

A typical call looks like this, with a constructed file name:

vol -f host42.lime linux.pslist.PsList

Check the documentation for your installed version, since plugin names and options change between releases.

What does a cross-view comparison show?

Two plugins that read different kernel structures should usually agree. When a process shows up in one list and not in the other, or a module is visible only to the hidden-module check, something is hiding or the capture is damaged. Treat the discrepancy as a lead, not a verdict. Exited tasks and capture timing can produce harmless differences.

A constructed walk-through

You have an image from a web server that sent odd traffic overnight. First, list processes and compare the two views. Next, run the socket plugin and note any connection owned by a process with a generic name. Then run the injection check on that process and read the shell history plugin for commands run just before the traffic started. Finally, check kernel modules against the hidden-module plugin. Each step narrows the question from "is something wrong" to "which process, which binary, which time".

What are the limits?

Memory forensics is a snapshot. Malware that was idle at capture time leaves little. Heavy kernel tampering can also mislead tools that rely on the same kernel data. Combine findings with network logs, authentication logs and file system evidence before you conclude anything.

How to check or apply this

1. Capture memory before rebooting, and record the kernel version and the capture tool.
2. Prepare the matching symbol table ahead of time for the kernels you run.
3. Compare process lists produced by different plugins.
4. Compare loaded modules with the hidden-module check.
5. Run the injection and kernel table checks on suspicious items.
6. Pull sockets and shell history to build a timeline.
7. Confirm findings against logs and disk before acting.

Quick check

Sources

• Volatility 3 documentation, Basics, fetched 18 October 2026.
• Volatility 3 documentation, Linux plugins, fetched 18 October 2026.

Last reviewed: 18 October 2026.