LX1.6 Memory Acquisition with LiME

Memory Acquisition: Capturing RAM Before It Disappears

Why Memory Is the First Priority

Memory contains evidence that exists nowhere else on the system. Decrypted TLS session data, SSH session keys, database query results in process memory, the full command history of a bash process (even if .bash_history was deleted), network connection state including the remote IP and port of every active connection, and the complete executable code of every running process — including processes that the attacker deleted from disk after launching. If a rootkit is hiding processes from ps and connections from ss, those processes and connections still exist in memory and can be found with Volatility 3.

Memory is also the most volatile evidence source. A reboot destroys it completely. A process termination destroys that process’s memory. Even running commands on the system modifies memory — loading ps into memory, allocating buffers for output, and creating kernel data structures for the new process. This is why memory acquisition is Phase B in the collection sequence — before any live response commands that modify the memory state.

Pre-Compilation: Build LiME Before the Incident

LiME is a loadable kernel module (LKM). Like all kernel modules, it must be compiled for the exact kernel version running on the target system. A module compiled for kernel 5.15.0-91-generic will not load on kernel 5.15.0-88-generic — the kernel rejects modules compiled for a different version (unless module signature enforcement is disabled, which it should not be on production servers).

This means you cannot download LiME during an incident and compile it for the target. By the time you determine the kernel version, find the kernel headers, compile the module, and transfer it to the target, you have lost 30–60 minutes of volatile evidence. The solution: pre-compile LiME for every kernel version in your infrastructure and store the compiled modules in your IR toolkit.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

# On a build machine matching the target's distribution

# Install kernel headers for the target kernel
sudo apt install linux-headers-5.15.0-91-generic

# Clone LiME
git clone https://github.com/504ensicsLabs/LiME.git
cd LiME/src

# Compile for the specific kernel
make -C /lib/modules/5.15.0-91-generic/build M=$(pwd) modules

# The output is lime-5.15.0-91-generic.ko
# Copy to your IR toolkit
cp lime.ko /path/to/toolkit/lime-5.15.0-91-generic.ko

# Repeat for each kernel version in your infrastructure
# Script this: query all servers for their kernel versions,
# compile LiME for each unique version

The practical approach: maintain a script that runs monthly, queries every Linux server in your infrastructure for its kernel version (uname -r), and compiles LiME for any new versions. Store the compiled modules on your forensic workstation, on a USB drive in your IR kit, and in a shared network location accessible during incidents.

Acquisition Procedure

When you arrive at a compromised system with a pre-compiled LiME module, the acquisition procedure takes 5–15 minutes depending on the amount of RAM.

Method 1: Dump to network (preferred — no writes to compromised disk)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# On the compromised system — load LiME, dump over TCP
sudo insmod /mnt/usb/lime-$(uname -r).ko "path=tcp:4444 format=lime"

# On your forensic workstation — receive the dump
nc -l -p 4444 > ~/cases/IR-2026-0402/BASTION-NGE01/memory/memory.lime

# After transfer completes — remove the module
# On the compromised system:
sudo rmmod lime

# On your workstation — hash immediately
sha256sum ~/cases/IR-2026-0402/BASTION-NGE01/memory/memory.lime \
  > ~/cases/IR-2026-0402/BASTION-NGE01/memory/memory.lime.sha256

The format=lime parameter creates a LiME-format dump that includes memory range metadata — Volatility 3 and other analysis tools can read this format directly. The path=tcp:4444 parameter streams the memory contents over TCP to your workstation. No data is written to the compromised system’s disk. The only modification to the compromised system is loading the kernel module (which allocates kernel memory and appears in lsmod).

Method 2: Dump to local file (when network dump is not feasible)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# Dump to USB drive mounted on the compromised system
sudo insmod /mnt/usb/lime-$(uname -r).ko \
  "path=/mnt/usb/memory.lime format=lime"

# Wait for completion (monitor with ls -la /mnt/usb/memory.lime)
# When file size stops growing, the dump is complete

# Remove the module
sudo rmmod lime

# Verify hash
sha256sum /mnt/usb/memory.lime

This method writes the memory dump to the USB drive (or other external media) mounted on the compromised system. It is faster than network transfer (no TCP overhead) but requires sufficient space on the external media — a system with 64GB RAM produces a ~64GB memory dump.

Method 3: Dump to remote filesystem via SSH (fallback)

1
2
3

# On the compromised system — pipe LiME output through SSH
sudo insmod /mnt/usb/lime-$(uname -r).ko "path=tcp:4444 format=lime" &
ssh forensics@workstation "nc -l -p 4444 > /cases/memory.lime"

What Happens When LiME Is Not Available

If you do not have a pre-compiled LiME module for the target’s kernel version — a common situation with unmanaged servers, cloud instances with auto-updated kernels, or systems where you did not proactively prepare — you have limited alternatives.

/proc/kcore is a pseudo-file that represents the kernel’s virtual address space. On systems where it is accessible (not all hardened kernels expose it), you can copy it: sudo dd if=/proc/kcore of=/mnt/usb/kcore bs=1M. The limitation: /proc/kcore is a virtual memory representation, not physical memory. It contains the kernel’s view of memory, which includes unmapped regions that appear as zeros. It is significantly harder to analyze than a LiME dump and not all Volatility 3 plugins work correctly with /proc/kcore input.

/dev/mem provides access to physical memory on older kernels. Modern kernels (4.x+) restrict /dev/mem access to the first 1MB by default (controlled by CONFIG_STRICT_DEVMEM). This is insufficient for forensic analysis. On systems where CONFIG_STRICT_DEVMEM=n, you can read physical memory: sudo dd if=/dev/mem of=/mnt/usb/devmem.raw bs=1M. But this configuration is rare on modern production systems.

Compile LiME on the compromised system (last resort). If kernel headers are installed on the compromised system and you have no other option: apt install linux-headers-$(uname -r) && cd /tmp/LiME/src && make. This modifies the compromised system significantly (package installation, compilation, disk writes) and should only be done when the alternative is no memory evidence at all. Document every step and every modification.

Skip memory acquisition. If none of the above options are viable, document that memory was not acquired and why, then proceed to Phase C (live volatile collection). You can still capture significant volatile data from /proc — running processes, network connections, open files — using the live response commands from LX1.2. You will not be able to detect hidden rootkit processes (which require kernel-level memory analysis) or recover deleted binaries from process memory (which requires a full memory dump).

Forensic Implications of Loading a Kernel Module

Loading LiME is itself a forensic action that modifies the system. The modifications:

The module is loaded into kernel memory — this modifies the kernel’s module list and allocates kernel memory. The insmod command execution may appear in the audit log (if auditd is monitoring module loads). The kernel ring buffer (dmesg) records the module load event. The module’s memory acquisition process reads every page of physical memory sequentially — this does not modify memory content, but the act of reading may update CPU cache state and TLB entries.

These modifications are minimal compared to the evidence value of the memory dump. The key requirement is documentation: record when you loaded the module, which module file you used, and when you removed it. This information goes into the chain of custody log.

On systems with Secure Boot enabled, unsigned kernel modules may be rejected. LiME modules are not signed by default. If Secure Boot is blocking the module load (insmod: ERROR: could not insert module: Required key not available), you have three options: disable Secure Boot in BIOS/UEFI (requires physical access and a reboot — which destroys the memory you are trying to capture), sign the LiME module with a Machine Owner Key (MOK) that is enrolled in the system’s firmware (must be done proactively), or use /proc/kcore as a fallback.

Beyond This Investigation

Memory acquisition is the first step of every high-severity investigation. LX12 (Linux Memory Forensics) teaches you to analyze the dumps acquired with the techniques in this subsection — extracting hidden processes, network connections, kernel modules, and bash history from memory. The quality of the memory analysis depends entirely on the quality of the acquisition — a dump that was acquired after the attacker disconnected and their processes terminated contains less evidence than a dump acquired while the attacker was still active.