Post cover image

October 17, 2026

TryHackMe Profiles: Linux Memory Forensics with Volatility 3 🔍

Investigating a Linux memory dump to uncover a malicious executable, network activity, and cron-based persistence.

By Youssef Lasri

4 min read

Investigating a Linux memory dump to uncover a malicious executable, network activity, and cron-based persistence.

Introduction

Memory forensics is a powerful incident-response technique that can reveal evidence left in RAM, including process information, command history, network connections, and cached filesystem data.

In the TryHackMe Profiles challenge, I used Volatility 3 on Kali Linux to investigate a Linux memory dump, recover a suspicious executable, trace network activity, and uncover a cronjob associated with persistence.

This walkthrough includes the investigation steps while masking the final answers with asterisks. Try to solve each checkpoint before revealing the results elsewhere.

Lab Environment

  • Operating system: Kali Linux
  • Forensics framework: Volatility 3 Framework 2.28.2
  • Memory image: linux.mem
  • Target system: Ubuntu Linux
  • Techniques: Process enumeration, Bash history analysis, socket inspection, page-cache recovery, and file hashing

Memory image location:

/home/kali/memory-lab/evidence/linux.mem

1. Identify the Linux Kernel Version

Before using Linux-specific plugins, I examined the kernel banner:

vol -f /home/kali/memory-lab/evidence/linux.mem banners.Banners

The memory image identified the target kernel as Ubuntu 5.4.0-166-generic.

Generating the kernel symbols

Volatility needs compatible Linux kernel symbols to interpret kernel structures correctly. I extracted the matching kernel debug information and used dwarf2json to generate an Intermediate Symbol File.

mkdir -p /home/kali/volatility-symbols/linux
/home/kali/dwarf2json/dwarf2json linux \
  --elf /path/to/matching/vmlinux \
  > /tmp/linux-kernel.json

I validated the generated JSON:

python3 -m json.tool /tmp/linux-kernel.json > /dev/null

After generating and installing the correct symbol file, I could successfully enumerate processes.

Lesson learned: Verify the kernel banner and match the symbols to the target kernel before troubleshooting individual plugins.

Reference: Volatility 3 Symbol Tables

2. Analyze Processes and Bash History

I enumerated the processes present in the memory image:

vol -s /home/kali/volatility-symbols \
  -f /home/kali/memory-lab/evidence/linux.mem \
  linux.pslist.PsList

Next, I investigated the available Bash command history:

vol -s /home/kali/volatility-symbols \
  -f /home/kali/memory-lab/evidence/linux.mem \
  linux.bash.Bash

One suspicious sequence showed that a remote C source file was downloaded, compiled into an executable, and subsequently executed. The source file was then deleted.

This provided the lead needed to recover the compiled executable from cached filesystem pages.

Checkpoint 1: What is the full path of the malicious executable?

***********************

3. Recover the Malicious Executable

I used the linux.pagecache.InodePages plugin to recover the executable's cached contents.

mkdir -p /home/kali/dumps
vol -s /home/kali/volatility-symbols \
  -f /home/kali/memory-lab/evidence/linux.mem \
  -o /home/kali/dumps \
  linux.pagecache.InodePages \
  --find "<TARGET_FILE_PATH>" --dump

I then inspected the extracted files and calculated their MD5 hashes:

find /home/kali/dumps -type f -name '*.dmp' -size +0c \
  -exec file {} \; \
  -exec md5sum {} \;

It is important to check that the recovered file is non-empty. An empty file can produce a valid MD5 value that does not represent the original executable.

Checkpoint 2: What is the MD5 hash of the malicious file?

********************************

4. Investigate the Attacker's IP Address and Port

The command history revealed a remote host involved in transferring the suspicious source file.

I examined network socket information with Volatility:

vol -s /home/kali/volatility-symbols \
  -f /home/kali/memory-lab/evidence/linux.mem \
  linux.sockstat.Sockstat

I correlated the socket output with the download command found in Bash history to identify the relevant remote endpoint.

Checkpoint 3 : What is the attacker's IP address and port?

************:****

This step demonstrates the value of correlating command history with network artifacts instead of relying on a single clue.

5. Identify the Root Cronjob and Inode

Next, I investigated scheduled tasks for evidence of persistence.

I searched cached filesystem entries for cron-related paths:

vol -s /home/kali/volatility-symbols \
  -f /home/kali/memory-lab/evidence/linux.mem \
  linux.pagecache.Files

To narrow the output:

vol -s /home/kali/volatility-symbols \
  -f /home/kali/memory-lab/evidence/linux.mem \
  linux.pagecache.Files 2>/dev/null \
  | grep -iE 'cron|crontab|crontabs'

The goal was to locate the root user's crontab and record its filesystem path and inode number.

Checkpoint 4: What is the full path of the cronjob file and its inode number?

Required format: filename:inode number

****************************************:******

Remember that an inode identifies a filesystem object. It is different from the inode-related identifier that Volatility may use in the name of an extracted dump file.

6. Recover and Analyze the Cronjob

Once the cronjob path was identified, I recovered its cached contents:

vol -s /home/kali/volatility-symbols \
  -f /home/kali/memory-lab/evidence/linux.mem \
  -o /home/kali/dumps \
  linux.pagecache.InodePages \
  --find "<CRONJOB_FILE_PATH>" --dump

I listed the extracted files:

find /home/kali/dumps -maxdepth 1 -type f \
  -printf '%f %s bytes\n'

Then I inspected the recovered cronjob:

cat /home/kali/dumps/<RECOVERED_CRONJOB_FILE>

If the output is difficult to read, a hexadecimal view can help:

xxd -g 1 /home/kali/dumps/<RECOVERED_CRONJOB_FILE>

The contents revealed a scheduled command associated with modifying the root user's Bash startup configuration.

Checkpoint 5 : What command is found inside the cronjob file?

***************************************

A cron expression controls when a command runs. In this case, the repeated schedule and the modification of a root-owned shell startup file make the task suspicious.

To understand the full impact, an investigator should also recover and inspect the file referenced by the cronjob.

Reference: Volatility 3 Linux Page Cache

7. Correlate the Evidence

The investigation brought together several independent evidence sources:

  1. Bash history revealed suspicious download, compilation, and execution activity.
  2. Process enumeration provided context about processes running on the compromised host.
  3. Network sockets helped investigate the remote endpoint.
  4. Page-cache recovery enabled recovery of a suspicious executable and the root crontab.
  5. Cronjob analysis exposed a possible persistence mechanism.

Each artifact answered a different question. Together, they helped reconstruct the activity more effectively than analyzing any single artifact in isolation.

8. Key Lessons Learned

Kernel symbols matter. Incorrect or incompatible symbols can prevent Volatility from interpreting Linux structures.

A slow scan isn't always a frozen scan. Monitoring CPU usage and memory availability can help determine whether Volatility is still processing.

Verify every recovered file. Always inspect its size and type before trusting a computed hash.

Use multiple evidence sources. Command history, processes, sockets, and cached files provide complementary views of system activity.

Investigate persistence in context. A cronjob that modifies a root shell startup file deserves further analysis, including recovery of the referenced file.

Conclusion

The Profiles challenge provided practical experience with Linux memory forensics using Volatility 3. It involved troubleshooting kernel symbols, analyzing Bash history, recovering a suspicious executable, examining network connections, and uncovering a cron-based persistence mechanism.

The most important takeaway is that memory forensics is an evidence-correlation process: identify a lead, investigate related artifacts, recover the relevant files, and validate the results before drawing conclusions.

Challenge yourself: Can you recover all five answers from the memory image without looking at a walkthrough?

References