Hacktivitycon 2021

This past weekend, some of the ConnectWise CRU members participated in the H@cktivitycon 2021 CTF put on by HackerOne as part of their H@cktivitycon, which returned after a very successful inaugural H@cktivitycon event in 2020. The CTF was hosted by John Hammond and his incredible team, along with CTF4Hire.

I started hitting the challenges right off the bat on Thursday evening, later being joined by other members of the team. We ended in the top 5% of participants at 129th place out of 2,527 teams. The CTF had some fantastic Jeopardy-style challenges with the classic categories of Pwn, Forensics, Scripting etc. We also saw the introduction of a Malware category which was based on real malware samples (defanged of course) being used out in the wild. This was an incredible addition and some of our personal favorites. With our own upcoming CTF, we thought it would be helpful to go over a couple of the challenges from this CTF and how we solved them.

Oddball – Warmup – 189 solves

Oddball is a warmup challenge that did not get as many solves as you’d expect for a warmup, with 189 solves and not hitting its minimal point allocation. The CTF is using dynamic scoring, so for every solve, it lowers the value for completion until a defined minimal point award. We are given a file called “oddball” and the following text: “Well this file sure is… odd…". Running cat on the file gives us output that at first glance looks like a Hexdump, but is it?

You may notice something looks a bit off. A Hexdump would include all numbers 0-9 and letters A-F, but the largest digit in this dump is 7 and there is an extra byte in each grouping when compared to hexadecimal. The hint gives an idea of something involving an odd number or in this case, an “odd” base. A “base” in this context is a reference to the number of digits in a numeral system. For example, decimal (what we normally use) is base 10, since it uses 10 digits (0-9), hexadecimal is base 16 since it uses 16 digits (0-F), and binary is base 2 since it only uses 2 digits (0-1). This file is showing data in a base 8 (octal) dump. We can use many different tools to convert this over to something more familiar, and in this case we used https://cryptii.com/ to convert the data from octal to hexadecimal.

After converting this to hex, I moved over to a local cyberchef page to play with the data. Attempting to just convert from hex shows some garbled data. Looking at it, you can see artifacts of what looks like a message and a flag. After trying some initial ideas, I started swapping bytes to see if the message changed to something legible. Turns out this returned promising results as parts of the sentence became readable. So, we set Cyberchef to swap endianness at 2 bytes, then converted from hex. Endianness is a computer science term that dictates the order bytes are referenced, with every 2 hexadecimal characters representing a single byte. For example, our hex data begins with the 2 bytes “596F”, but if we swap the endianness every 2 bytes, this becomes “6F59” which when converted to ASCII is “Yo”.This almost solves it, but part of the flag is still garbled. Looking at the data, we noticed several spots where there are missing bits, leaving an odd set in several spots. Padding these with 0s fixed the issues and we got the flag!

Dotbat – Malware – 56 Solves

Dotbat is a malware challenge with the given hint “This file is a dotbat, literally! Don’t believe me? Try it!". We are given a file called “Dotbat” which given the title tells me this is a Windows bat file. Attempting to open this in a text editor shows a huge file containing non-English characters.

Running the file via the command line in a VM shows that this is an actual executable bat file that is performing some actions then deleting itself. Using a hexeditor shows some promising results.

We can see “public” being referenced which we assume to be the Windows Public directory, along with what looks like batch variables being referenced using the %. Digging around for batch obfuscation techniques shows the reason text editors are having a much different result versus Hexedit is due to the starting bytes. The first 8 bytes of the file are being read by charset detectors and causing it to change the encoding to UTF-16 which is why an editor like Notepad++ is reading it different versus raw command line. We can set these to null and fix that issue or set your editor to simply read it as ASCII. I then found a heavily obfuscated script with ^ escapes and substring substitution. After some searching, we believe this script was obfuscated using a tool called batchobfuscator.py. Using the words and windows strings I recognized, and with a bit of help from find/replace, I removed all ^ escapes, replaced obfuscated strings, and reverted the script to something more readable.

Here, we see the script before it was heavily obfuscated. Reading to the end of this script, it performs a lot of registry actions and loads a certificate that is decoded into an exe using certutil.exe, a common technique we’ve seen malware use, and placed on the disk at "%sySTEmdRive%\pRogRAmDAtA\MicrosoFt\WiNDoWs\sTArt mEnU\pRogRAMs\sTARTup". Running this through CFF explorer, the PE header shows this is a .Net assembled binary meaning I can use DNSpy to read the source code.

Jumping to the main() function, I saw AES Encrpyt/Decrypt functions and a main program to decrypt a hardcoded value using a hardcoded key. A quick read of the code shows a null IV being used as well, meaning we can decrypt this and the flag!

These were only a few of the great challenges we had the pleasure of working on. We plan on participating in future CTFs as well.

Cheers,

Ross – Threat Researcher, CRU

We'd love to hear your thoughts. Find us on Twitter, LinkedIn or write in to hello@perchsecurity.com

Next: More Exchange Vulnerabilities and a Confluence Rce