BIPI
BIPI

Linux Memory Forensics on a Live Box: /proc, /sys, and Volatility

Cybersecurity

When you cannot pull a disk, memory tells the story. A practical workflow for live Linux memory forensics using /proc, /sys, LiME, and Volatility 3.

By Arjun Raghavan, Security & Systems Lead, BIPI · March 29, 2025 · 11 min read

#linux#forensics#volatility#lime#incident-response

Why live memory beats disk on Linux

Modern Linux attackers run from memory, in containers, and through fileless techniques. The disk image will be mostly clean. The interesting evidence lives in /proc, /sys, and physical memory until the next reboot.

First commands at the prompt

  • ps auxf for a process tree with command lines
  • ss -tulpenW for sockets with owning processes
  • ls -la /proc/*/exe to spot processes with deleted binaries
  • cat /proc/*/maps for memory regions, executable anonymous regions are suspicious
  • lsof +L1 for files that are open but unlinked

Triage from /proc

Each process has a directory in /proc. Read cmdline, environ, status, maps, and fd. A process whose exe symlink ends in (deleted), whose maps shows an executable region with no backing file, and whose environ contains LD_PRELOAD or HISTFILE pointing to /dev/null deserves a closer look.

Pulling memory with LiME

  1. Compile LiME against the target kernel version, headers required
  2. Transfer the lime.ko module via SSH or out of band
  3. insmod lime.ko path=/mnt/usb/memory.lime format=lime
  4. Verify the file size matches /proc/meminfo MemTotal roughly
  5. Hash the dump with sha256sum and record it in the case notes

Volatility 3 workflow

  • vol -f memory.lime linux.pslist for the kernel process list
  • vol -f memory.lime linux.psaux for command lines
  • vol -f memory.lime linux.bash for recovered shell history
  • vol -f memory.lime linux.check_modules for hidden kernel modules
  • vol -f memory.lime linux.malfind for executable anonymous regions

Symbol tables, the boring prerequisite

Volatility 3 needs a kernel symbol table for the target. Generate one with dwarf2json from the System.map and kernel debug info, then drop the JSON into volatility3/symbols/linux. Without symbols, Volatility cannot walk kernel structures.

Cross referencing live and dump

  • Compare live ps auxf with vol linux.pslist, mismatches indicate hidden processes
  • Compare lsmod with vol linux.check_modules to find unlinked modules
  • Diff /etc/passwd from disk against strings dumped from memory
  • Look for network connections in vol linux.sockstat that did not appear in ss

Container considerations

Inside a container the host kernel is shared. Memory analysis works against the host, not the container. Get the container PID with docker inspect or crictl, then read /proc/PID/ on the host to scope to that container.

Detection layers worth adding

  • Sysmon for Linux process create events with parent process IDs
  • auditd rules for execve from /tmp, /dev/shm, and memfd_create
  • Falco rule for processes whose exe is (deleted)
  • Pre install kernel headers on critical hosts to enable LiME without prep
Memory forensics on Linux is not exotic anymore. It is the difference between knowing the attacker ran and knowing what they ran.

Build the kit before you need it

Pre built LiME modules, pre generated Volatility symbols, and a tested checklist for every distro in the customer fleet. The incident is the worst time to learn that your kernel headers do not match.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.