Saturday, August 20, 2022

Korelogic's CMIYC 2022 @ DEF CON 30 Write-up

What a breath of fresh air to have DEF CON 30 not be canceled this year. We are thankful that Korelogic’s CMIYC is running strong 13 years in. Going into this contest we assumed the competition would be quite fierce, however we are always up for a fair challenge. As most members on our team are hobbyist password crackers not working in the cybersec industry, this gave us a wonderful opportunity to dust down and re-paste our GPUs.

Our roster this year comprised of 9 active crackers, 1 part-time cracker and 2 others providing ancillary support. The members included were AMD, blazer, cvsi, gearjunkie, golem445, hops, MXall0c, Waffle, s3in!c, pdo with winxp5421 and usasoft playing support roles in our comms and hash management system.

Our hardware list consisted of

 Confirmed

      1x 3080

      3x 2080 TI

      2x 2080

      4x 1080

      7x 1080 TI

      2x 1070

Unconfirmed

      We are missing the GPU count from two of our crackers. You know who you are, if you read this please report back.

Brief challenge overview

The 7zip and half-md5 archives were cracked easily using john the ripper (JTR). JTR was subsequently used with the correct libxcrypt library to crack the yescrypt hashes as that was the only cracker supporting yescrypt.

web.conf challenge involved setting up Jasypt (the Java equivalent to Python’s hashlib). The runme.sh indicated that each line in the output.txt was encrypted with PBEWITHMD5ANDDES, with both the input and password being the same. Therefore as a verification, if the ciphertext was correctly decrypted, the resulting output would be identical to the password.Initially, the decrypt.sh provided by Jasypt was used to manually feed in the candidates, a python script was later written to automate the process. This wasn’t relied on as it was easy enough to guess by hand once the pattern was observed. We were able to quickly form the url for this challenge and decipher the url to reveal the ‘tennis shoes’ hash list as a team.

LoopAES challenge; while this appeared to be a mountable filesystem, the length did not coincide with this, therefore it was presumed to be aespipe instead. However, since there is no ability to check whether the file is decrypted correctly a quick perl script was produced to run sanity checks on the output to determine a successful decrypt.

list23-Authoritiesappeart…gpg was cracked using JTR with a small dictionary containing the potential candidates while the heavy lifting was carried out by JTRs rule engine.

DEFCON-with-key.kdbx; initially attempted with JTR, once the keyfile was released during the contest we had issues obtaining a valid hash from keepass2john. A closer inspection showed that Korelegic messed with the keyfile and instead of using base64 encoded data, a hex string was present. This involved fixing the keyfile by decoding the hex and encoding the resulting data with base64 to extract a valid hash. Admittedly more time was spent than we would like to admit until someone tried opening the KeePass database only using the keyfile and no password.

DEFCON.kbdx (released later in the contest), once the file was released it was converted to a hash and hashcat was used to crack the hash.

Gocryptfs, a VM was spun up for this challenge and the hash quickly cracked manually on the 4th try, no cracking software was used.

Salt_and_pepper took us slightly longer than expected to identify the salt and peppers for. We did test other hash types as a precaution.

The odt file was cracked using Passware’s Passcovery, though JTR should have been able to handle this as well. We also found out that ms-word does not open password protected open office documents.

Riddled_wrapped_in_an.zip was cracked with both JTR and Passcovery independently.

Problems

We did have a slight issue parsing the nsldaps SSHA-1 hashes, this was quickly corrected, though it did accidentally trigger a double upload to Korelogic, other than this incident we did not run into any submission difficulties.

We spent a considerable amount of time wasted on cracking the initial uncrackable KeePass file. Although the name did suggest a key was needed, it wasn’t evident whether this was a hint for hashes inside, so it was better to at least try. GPUs were put on the extracted hash for this file but obviously was not able to yield any results.

We initially used hashcat mode 25400 to attack the converted pdf hash. This resulted in many false positives. These false positives, many which contained untypable characters, were tested and unsuccessful in opening up the file with non-typable characters. Mode 10500 was then used to obtain the correct password. The pdf was then required to have the security removed as there were restrictions preventing the hashes from being copied out. Furthermore, once the hashes were copied out, slight reformatting was necessary to get them usable.

Fooo file from the enigma zip; Resources were used to analyse and tear apart the bizarre fooo file. Analysis of the file indicated it was a repeating block of 3.8M of data 27 times, which suggested the data was not encrypted due to the low entropy of output produced.  Tools used included binwalk, veracrypt, random and suspicious enigma file encryption/decryption application from softpedia and sourceforge and finally the FreeBSD enigma crypt utility.  Like the LoopAES decrypts, an automated decrypt and validate script was used to scan the decoded output for meaningful data, our attempts to decode the file were futile. Another suggestion was that since the data was nicely divisible by 16/20/32 bytes it could suggest that they were MD5/SHA1 or SHA256 hashes dumped straight out of memory. The bytes were reassembled in both endian forms, then run through crackers to try “de-hash*” them.

Analysis

The actual “de-hash*” procedure was relatively straightforward, once a challenge was solved the hashes were parsed and uploaded to our hash management system. From here, members worked collaboratively but autonomously. Once a pattern was spotted, it was reported and members would share this information, users parsed their own lists which ensured a variation of coverage for that wordlist set. This enabled us to cover each other’s parsing errors, tooling issues and hopefully differences used in the plaintext generation by Korelogic.

After a hashset was cracked close to completion, the difficulty would increase drastically. This could have been caused by missing the baseword/phrases or missing a ruleset or pattern to match the plaintext. To push that last few percent, members would shift their attack strategy or redeploy to a different algorithm as having a fresh set of eyes/wordlist does wonders.

Although we had a distributed hashtopolis instance setup, we did not have to tap in it. We did not require a large amount of compute resources for this contest and even if it was available, the challenges would have been a bottlenecking factor rather than being compute bound. Some of the challenges were even solved on a laptop or legacy hardware. Where possible, we would try to reduce the keyspace tested to a minimal number of candidates. It was also beneficial to communicate to others what was happening to prevent work being overlapped. The most important part was to recognize the patterns and adapt quickly or leverage the correct toolset.

The SHA224 hashes proved to be quite intriguing. We identified two basewords ‘hacker’ and ‘homecoming’ and quickly noticed the plaintexts were based on a heavily mangled version of these words. This included case toggles throughout the whole word, coupled with insertions/deletions, overstrikes and character swaps. It was evident that although being 2 simple basewords, this would result in an insanely large keyspace as the plaintext length increased. Once an adequate amount of plains were cracked, some users switched over to markov models, including the use of OMEN, PCFG_Cracker and PrinceProcessor and these tools gave us a decent amount of hits. We would also cycle the extracted rules from the plaintext through other basewords, as this would allow us to identify potential basewords, we thought we found another ‘ihatecooking/ihatecoding’, though this was possibly an artifact of the mutations on the original two basewords.

Thoughts

It would appear we were the first team to submit cracks for every algorithm, though we are unsure whether we were the first to actually solve all the challenges as other teams may have been working on the hashes or busy parsing them or had not actually submitted cracks yet.

If we didn’t push the envelope of password cracking, we sure pushed the envelope of interpreting a chunk of repeating bytes and demonstrating our creativity in trying to make something useful out of it. More than enough resources were spent on this task, if you are reading this Korelogic, please check your inbox for a laugh.

This year’s contest was structured quite differently to last year. Teams who were unable to solve the challenges would not have been able to unlock the hashes, in a way it pushed teams to explore. However, this would have punished teams less experienced with CTF style challenges causing a huge idle of processing power. We tried our best to keep Team Hashcat on their toes and traded places with them 5 times throughout the contest. Team Hashcat demonstrated their expertise and skills by cracking almost the most hashes across algorithms, while Hashmob was also able to keep up by solving the hashes quite rapidly once a challenge was unlocked. Towards the end of the contest when all the teams had solved all the challenges it came down to being able to constantly supply new founds as this would allow us to at least maintain our position.

As a group we had excellent team synergy, as a contest other than the red herrings it was well thought out and planned, as a competition we thoroughly enjoyed facing our competitors Team Hashcat, Hashmob, john-users, achondritic and trontastic.

Footnotes:

We are well aware that you cannot “de-hash” as hashes are strictly one way digests. It has not stopped others using it and has not stopped us from having a friendly poke at it. See here for more info.

Thursday, August 12, 2021

Korelogic's CMIYC 2021 @ DEF CON 29 Write-up


Crack me if you can write-up 2021

 

We once again assembled the team to take on KoreLogic’s annual Crack me if you can contest for Def Con 29. This year we had 12 members participating they were s3in!c, blazer, golem445, user, pdo, winxp5421, Waffle, gearjunkie, hops, cvsi, 0xln & usasoft. Since we were from all over the world, we were able to continuously submit cracks throughout the 48-hour duration of the contest.

In preparation for the contest, we re-developed the back end of our hash management platform “TeamLogic” and therefore expected that things may not be as smooth. We expected to see exotic hashes or perhaps some use of Hashcat’s new association mode. However, when we first saw the big 6GB download we thought it would be interesting as we wondered how the hashes would be shared with us. Would they be in a text file on the desktop? What operating system would it be running? Do we have to extract the hashes? Nevertheless, some of us setup VirtualBox in preparation.  Upon receiving the decryption key, this was some of the chatter that occurred.

“Sorry guys, it’s a Windows… good luck have fun”

“How come this VM is not working?”

“This VM keeps restarting”

“This VM does not work in VMware”

“Nothing is working properly with this VM”

“There are a crap ton of objects in this AD”

As a team of hobbyist password crackers, who don’t generally dump hashes of domain controllers daily, it took us some time to navigate the forensic side of things. We were able to use various methods to access the VM including:

·         Cracking the admin AD hash and logging in normally

·         Extracting the ntds file directly off the image file

·         Dumping the ntds file off the running VM

·         Live booting over the VM 

The sheer volume of objects in the AD made things extremely sluggish, mimikatz was run on the Vm and impacket was also used to dump the ntlm hashes off the ntds file.

Protip: Use pypy instead of normal python for a nice speedup when using impacket’s secrestdump.py

We suspected that other teams were in a similar situation to us, as we did not see the scoreboard being populated. We made a start with a partial dump and believe we were the first to register scores across all the various hash histories

Once the hashes were upload to our hash management platform, we all went of to work our magic on the hashes. Some notable patterns which we noticed where the lyrics/quotes, ferengi, bible phrases along with the occasional bonjovi, minga and korelogic plaintexts scattered.

 

Having retrieved a sufficient number of plaintexts, the hashes were grouped by users to create a visual aid in assisting us to discover patterns.

When we initially saw that these hashes were NTLM only we thought that it would be a game of who has the highest hashrate wins contest. However, we were quite wrong, because a bruteforce approach would not have been effective at all.  Korelogic had put some thought in designing the passwords in such a way that other exhaustive approaches had to be taken such as switching to pure kernels to attack very long plaintexts.


Despite having to apply various hotfixes to our hash management platform and running into minor hiccups, we cracked most of the passwords very early on, as shown in our internal submission graph. Towards the last 12 hours of the contest, we developed a workflow which consisted of converting as many history6 hashes as we could to history5 and so on until history2. From here, we would try to isolate a pattern and crack as many history1 and ultimately history0 hashes as we could.

 This following workflow worked very well for us and we were able to use a series of custom scripts to achieve

 

We found that using the following rule "sv^sa@se3so0sh5@j” which is a variation of the 1337.rule we were able to convert most of the history1 to history0 plaintexts. Towards the end, we made a huge push and spent lots of resources trying to find more patterns, but we were unable to get a breakthrough.

While we took the lead for a short period of time, we quickly fell back to second place. Ultimately, we were able to secure a very comfortable second spot in the contest and kept close to team hashcat’s tail throughout the contest. Congratulations to the other returning team’s john-users and trontastic and the newcomers hashmob and 1IHsxRAM7GzoM for demonstrating their ability to participate in the pro division.

Thank you Korelogic for putting together a very fun challenge this year, despite only using NTLMs, you still managed to keep us entertained for a good 48 hours. We are eager to see what future challenges brings.

We have attached the list of both the hashes and plains which we cracked for this contest here. While we understand the plaintexts have been released by KoreLogic, we have decided to leave readers a little challenge to decode our cracked plaintexts. 

Hint: Being Identical is the key