🔵Dead End

Dead End

INTRO

Hello and welcome,

In the following article, I will explain how I solved the "Dead End?" room on TryHackMe: link to room created by Mokmokmok: link to creator.

In this challenge, we are provided with two files: a memory image and a disk image.

Memory dump

If you have a memory dump, Volatility is the tool to use. Personally, I'm a huge fan of Volatility and have solved a variety of CTF challenges using it.

For a handy reference, check out this Volatility cheatsheet: Volatility Cheatsheet. It’s a great resource if, like me, you struggle to remember all the commands. 😉

Let's start by identifying the operating system of the memory dump using this command: python3 vol.py -f ../RobertMemdump/memdump.mem windows.info

Next, we'll list the processes in a readable format with the command: python3 vol.py -f ../RobertMemdump/memdump.mem windows.pslist >> pslist.txt

At first glance, nothing seems out of the ordinary. However, there's one thing that caught my attention. You can see that every svchost.exe process has the same PID 804, but is that really the case?

Generally, if the PPID points to services.exe, it's normal behavior.

But this process is responsible for running PowerShell...

This is quite concerning, and the fact that svchost.exe starts from the C:\Tools directory only confirms my suspicion.

I decided to use the command: vol.py -f “/path/to/file” windows.cmdline, and in the output, I found not only confirmation of my suspicions but also the answer to the second question.

---

Disk Image

We'll start by using FTK Imager to read the contents of the disk.

From the very beginning, I decided to search for the .txt file that we saw in the previous task.

In this location, there are two files:

I initially thought that the file connector.ps1 was the answer to this question, but after reading the hint:

Auto connects to what? Is connector.ps1 downloaded or created?

I decided to keep searching. (Note: At this point, you find the answer to question 3.)

Clicking on svchost.exe reveals that it was downloaded from the autoconnector folder.

However, at this point, I wasn't sure what to do next. While searching through the USER.DAT registry by chance, using the bstrings command (from the EZtools package), I stumbled upon another reference—this time, it included an executable!

The next step was to dump the registries. The registries can be imported using FTK Imager:

• SAM (C:\Windows\System32\Config\SAM)

• SYSTEM (C:\Windows\System32\Config\SYSTEM)

• SOFTWARE (C:\Windows\System32\Config\SOFTWARE)

• SECURITY (C:\Windows\System32\Config\SECURITY)

• DEFAULT (C:\Windows\System32\Config\DEFAULT)

• NTUSER.DAT (Found in each user's profile directory, e.g., C:\Users\username\NTUSER.DAT)

After importing the registries into Registry Explorer, I used Ctrl + F to search for autoconnector.exe.

The search turned out to be really helpful—just like the hint said, it was a "Bam in your face" moment. We just need to add the prefix HKEY_LOCAL_MACHINE to narrow down the search.

And now came the biggest challenge—finding the last flag. I struggled with it for a long time.

I came up with the idea to run the script and log everything.

It wasn’t the best idea, but since I already knew what the program did and was confident it wouldn’t harm the system, I decided to run autoconnector.exe.

But first, I made sure that all commands in PowerShell would be monitored, so I adjusted the appropriate policy in the Group Policy Editor accordingly.

After running the script, the same thing happened as with the disk we analyzed earlier. A /tmp folder appeared with two files inside.

In the logs, I found the second part of the flag. It's encoded in Base64, so to reveal the full flag, you need to combine part 2 from the .txt file with the part you just found, and then decode it using a tool like CyberChef.

---

Conclusion

The room is really well-designed and definitely deserves its "Hard" difficulty rating. I improved my forensics skills while having a great time 😁.

See you soon! 😎😁