CMIYC 2024: RAdmin3 Challenge

"Nothing is more permanent than a temporary solution."

- Russian Proverb

This is a continuation of my write-up about this year's Crack Me If You Can challenge. You can view the previous entry focusing on the StripHash challenge [here]. Like the last write-up, this one is going to focus on one specific hash format (RAdmin3), details about that hash format, and how to load those hashes into a cracking session. I'm going to defer most of the actual cracking of these passwords to a later writeup though since running a successful cracking session relies on solving other challenges found throughout the contest.

Important Links, Tools, and References for this Post:

I'll admit that before this contest, I had never encountered Radmin3 password hashes. That probably reflects on my lack of recent full scope pentest experiences. On the flip side, their inclusion in this year's CMIYC challenge also highlights the contest organizer's (Korelogic) experiences with pentesting since the entire challenge revolves around limitations in current public open-source tools supporting Radmin3 cracking.

To learn more about the Radmin3 hash itself, how to obtain them, and how they are used, I *strongly* recommend you check out Synactiv's excellent blog post on this subject (linked above). The TLDR summary is that Radmin3 hashes are generated by a Windows remote server management tool (Radmin Server 3). My understanding is these hashes reside on the server itself (vs. being cached on client side systems), but this isn't a centrally managed tool so gaining access to one server and cracking an administrator's password will likely grant you access to other servers during an engagement. Also, having an administrator's cracked password is good for all sorts of other "fun" as well.

The hashes themselves are stored in the Windows registry and can be dumped using standard Windows registry tools. I'll dig more into that later as this was a core component of this year's CMIYC challenge. The actual hashing algorithm is weird. It starts out with a fairly standard:

sha_hash = SHA1(salt + SHA1("username:password"))

But then goes a bit crazy with:

Hash = pow(g,int(sha_hash.hex(),16),modulus)

The Radmin Server development team obviously has an aspiring cryptographer on their staff! Now while such an optimization is annoying/challenging to someone encountering it the first time, the Synactiv team managed to find a number of attack optimizations that limits the value of that last step. This just goes to show how hard it is to develop a secure hashing algorithm.

In the first PGP encrypted KoreLogic provided for the CMIYC contest there was a file called radmin.reg that was 6473 lines long and formatted like a Microsoft Windows registry dump of the keys/values in:

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Radmin\v3.0\Server\Parameters\Radmin Security\]

Looking at this data, the filename itself, and the fact that Radmin3 hashes were listed in Korelogic's contest scoreboard it's pretty easy to guess there are Radmin3 password hashes in this file. So how do we convert these to a format we can crack? The short answer for me was to do a lot of Googling, but the more repeatable answer is that there is a tool called radmin3_to_hashcat.pl that comes bundled with Hashcat. A direct link to it is listed above as well. So let's try to use that Perl script on the challenge registry file!

Not really surprising the script errored out. Korelogic certainly doesn't have a track record of making things easy for players. Let's look at the radmin3_to_hashcat.pl script to understand what may be breaking.

And let's compare it to the start of our challenge registry file.

Oh hey, it looks like some extra registry keys and debugging info was included in the file by the Windows Registry Editor used to dump the registry keys. Let's delete those key/values and try to run the radmin3_to_hashcat.pl script again.

So it extracted one hash at least. Looking at the registry file though, there are a ton of hashes in it. Unfortunately it looks like the Perl script is not looping though all of those hashes.

Digression/Side-Note: This is more gossip than a technical point, but this challenge design feels like one of the Korelogic staff encountered this problem on a pen test engagement, was very annoyed, and thought "oh we can torture players with this and someone might fix the Perl script for us at the same time!" Props to Korelogic if this is the case. I mean I can't judge. I've certainly designed CTF challenges to get players to solve problems for me before. If you ever participate in the Biohacking Village CTF, the lateral movement challenge from an physical infusion pump falls into this category. I had no idea how to solve due to a buggy BusyBox telnet binary (those words together should concern you since this is a medical device) so I thought "hey, lets just throw it into the CTF with a disclaimer and see if someone else can do it." Research and development though CTFs is a powerful tool!

Ok, back to the technical challenge at hand! Let's take stock at where we are at:

We have a bunch of hashes in a registry file
We have a way to extract the first hash from the registry file

That's a pretty good spot to be. From here, the following two paths could be taken to be able to extract all the Radmin3 password hashes from the registry file:

Option 1) I could modify the Perl script to include a loop so that it would repeat the parsing logic on each registry key.

Plus: The resulting Perl script would be helpful for people after the contest.
Plus: I could add additional logic to dump the entry number of the registry entry as a userid in case there were some association attacks enabled by other Korelogic challenges.
Minus: I couldn't just simply add in a top level loop due to some design decisions of the script. So I'd also need to add logic that it was done parsing the hash file, which involved writing some basic Perl code.
Minus: I really didn't want to write any Perl code

Option 2) I could write a quick script to cut up the registry file into many, many different files. Each file would contain one registry value. I could then run the Perl script inside another script so that I could automate it running against all those files and collect the output.

Minus: This is janky as all get out
Minus: This is the type of solution that you deploy as a temporary fix, it ends up in production, and years later someone looks at it and goes "what the hell happened here?!"
Minus: This isn't really useful to the larger password cracking community
Minus: This will probably take longer to implement than writing around 10 lines of Perl code to accomplish it using method #1
Plus: I could implement this in Python

Solution: I obviously picked Option #2!

I'm not proud of this, and looking back at the challenge I really should have picked option #1. Now Option #2 would be more justifiable if I had scripted up an elegant solution like player 64_nickels described on the CMIYC Contest Discord server:

My solution was ... not that clean.

I can make a lot of excuses for my ugly approach, but I have to say, it did work!

So this part is going to be pretty boring. The Perl hash extraction script came from Hashcat's repository, so it stands to reason that Hashcat can crack these hashes. Looking at the different Hashcat modes (link above) you can see there is an entry for Radmin3 hashes (Mode 29200). Looking at the example hash, it looks very similar to what we were able to dump:

Without going into too many more details about the cracking session, I can verify that Hashcat can crack these hashes using that mode, but that it's a slower attack, and I didn't crack many of these hashes using "standard" password cracking wordlists/rulesets for slow attacks.

So you might be wondering, can you crack these hashes with John the Ripper? The short answer is no, (John only supports Radmin2 hashes), but this provides a good opportunity to talk about a John the Ripper feature I learned about after my last blog post. You can have John run through a mixed hash list and output all the possible hash types in JSON format using the --show=format command. For example you can run the following command on the main CMIYC2024 cmiyc-2024_street_passwd_1 mixed hash list:

./john --show=format cmiyc_2024_street_passd_1

That command will cause John the Ripper to parse the hash file and return the following output which is pretty cool and can then be read into other analysis programs:

Long story short, if you do this on the Radmin3 hashes, John the Ripper will report that it doesn't support them. But this was a feature of John that I wasn't aware of before, so I wanted to share it since I think it's super neat. Also it may point to some future blog posts :)

I need to give Korelogic credit. This was a fun challenge and I'm glad they included it in this year's contest. I'm probably going to wait a bit to see if someone else beats me to it, but if nobody else steps up I may take a swing at modifying the Radmin3 extraction program to be a bit more robust to registry dump headers, unassociated keys, and to support multiple Radmin3 hashes. So fingers crossed someone else is working on it!