Holmes CTF 2025
HTB’s first-ever Blue CTF!
In this CTF, Im playing with my team, HCS. As a blue team player, this ctf was the one I waited for. At this CTF, I solved one challenge called The Tunnel Without Walls. And here's the write-up for that challenge.
The Tunnel Without Walls
Difficulty: Hard
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!
In this challenge, we're given the linux memory dump. Like the steps of my previous writeup, we can check it use Volatility to setup and start analyze. In order to retrieve the flag, we must answer a series of questions.
vol -f memdump.mem banners.Banners
Volatility 3 Framework 2.23.0
Progress: 100.00 PDB scanning finished
Offset Banner
0x67200200 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)
0x7f40ba40 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)
0x94358280 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)
0xa9fc5ac0 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)
0x12ee9c300 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)From that, we can know that the Linux distro is Debian and the version is 5.10.0-35-amd64 . Then, we can find the symbols table for the kernel we found in this repo. Now that we have found and downloaded it, we can start the analysis!
What is the Linux kernel version of the provided image? (string)
We already found the linux kernel version as we run the banners.Banners plugin to found the correct symbols table, 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 know this, we can use linux.bash plugins to check the bash history from the linux memory dump.
We know that there is some bash opened with different process. But we know that some reconnaissance command is like id , uname -a , ip a, etc. So its can be verified that the PID for the shell used is 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)
In the Volatility, there is linux plugins that can recover the cached filesystem (directories, files, symlinks) linux.pagecache.RecoverFs . After recovering all the filesystem, we can find the /etc/passwd to find the stored password. Also, we can see the bash history that the threat is switching to use jm . So we can check it
We can use hashcat with the rockyou for the wordlist to get the password.

Then, we know the password is WATSON0 . And the credential is 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)
To know this, we actually can check the hidden modules first. In the Volatility, there's a plugins called linux.hidden_modules , it used to carves memory to find hidden kernel modules.
In the recovered filesystem we already have, we can find that kernel modules to find the path.
And we can know the path is /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)
Once we know what the malicious file is, we can reverse it using the tools you are comfortable with.

Then, we know the email account of the alleged author is 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)
From the bash history, we know that the threat is installing a package with command apt install -y dnsmasq . So, we can use linux.pslist plugin to know the lists the processes present in a particular linux memory image.
So we know the PID for the dnsmasq is 38687 . Then, the answer is 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?
Refer to this writeup, we can do extract for the network traffic from the captured memory dump use bulk_extractor . After doing the extraction, we get the packets.pcap and we can do analyze for that to know the workstation hostname. We can use online tools like https://apackets.com to analyze the pcap file. And we get the workstation's

So, the workstation hostname that was already tricked is 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)
With the captured network, we also can follow the HTTP protocol traffic to found the credentials for the threat used to access the City of CogWork-1 internal portal.

From that, we know the username used to login to the portal is 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 path of the malicious file, we also know the container used, 92931307-c5fd-4804-94f2-a8287e677bd6 . So, we can find the log for the traffics. This question take's time to find the correct endpoint, but after some times, we found the correct at:
So, we know that the endpoint is /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)
From the workstation before, we know that the IP is 192.168.211.52 . And with that IP, there is DNS connected with that

And we know, the most suspicious domain is updates.cogwork-1.net and for the redirect IP address and port, we can go back to the bash history when the threat edited the the default.conf to be used in the docker. We can check that from the recovered filesystem.
So, we know that the domain is redirected to http://13.62.49.86:7477/. And the final answer is updates.cogwork-1.net,13.62.49.86:7477 .
Last updated