The Return of the Yeti
The Yeti needs a plan for 2023. Help him out! - by munra and ujohn
All banner and comic images are courtesy of TryHackMe - https://www.tryhackme.com
Getting to SQ1 - The QR Code
First, let's take a look at where we can find the parts of the QR code for those who may still be searching. The following social media platforms contain the links to the QR codes: You can find the first one in the #aoc-2023-side-quest channel on the TryHackMe Discord server as a pinned message. Further parts can be found in a post on LinkedIn and X former Twitter of Tryhackme. To Access Twitter without an account and find the post, you can use one of the several sites like nitter.net. All posts are listed below. You can also find the link to the challenge directly here in the writeup.
Discord
X / Twitter
LinkedIn
Side Quest Main Room
New Year, New Opportunities
The challenge itself only provides a PCAP-NG file that needs to be analyzed. A PCAP-NG (Packet Capture Next Generation) file is a file format used for storing network packet capture data. It is a further development of the PCAP file format, which now contains additional features and improvements.
What's the name of the WiFi network in the PCAP?
To view the network traffic, we load the PCAP-NG file into Wireshark. At first, we can't see anything else except that we are dealing with beacon frames in the first packages, revealing the SSID and the first answer to the question. All the traffic is Wi-Fi traffic, which we cannot see because it is encrypted.
What's the password to access the WiFi network?
We already know that the PCAP-NG file is a capture of encrypted Wi-Fi communication. We are able to retrieve the password by brute-forcing it by using Aircrack-ng.
After receiving the password, we are able to decipher the Wi-Fi traffic using Airdecap-ng, turning the encrypted pcap file into a decrypted one, to answer the following questions.
BUT we find that the new PCAP format is not supported, at least by the version used of Aircrack-ng.
We just use Wireshark to save the already opened VanSpy.pcap-ng to save it as a PCAP file.
After running Aircrack-ng using the popular wordlist rockyou.txt, we are able to retrieve the used Wi-Fi key.
What suspicious tool is used by the attacker to extract a juicy file from the server?
To answer the other questions, we need to be able to read the decrypted Wi-Fi traffic. To do this, we use the Airdecap-ng tool to decrypt the PCAP file that we have previously converted.
After executing the command, we get a pcap file with -dec in the name.
airdecap-ng <pcap.file> -e <SSID> -p <PASSWORD>
VanSpy-dec.pcap
Next, we load the VanSpy-dec.pcap into Wireshark and take a look at the traffic. The first thing we notice is that the first 20.000 packets are encrypted RDP traffic just by seeing the port 3389.
Followed by an apparent port scan. At the end of the traffic, around packet 20552, we can see traffic on port 4444. A port that is often used for reverse shells.
From packet 20560 onwards, we can see the plaintext TCP traffic and see what the attacker may have done. We can see that the attackers used Mimikatz. Mimikatz is a popular post-exploitation tool that was originally developed by Benjamin Delpy in 2011. It is designed to gather credentials, especially in Windows environments, by exploiting vulnerabilities and weaknesses in the security of the Windows operating system. That answers our third question.
What is the case number assigned by the CyberPolice to the issues reported by McSkidy?
Unfortunately, no further information could be extracted from the plaintext traffic to directly answer questions 4 and 5. It is not without reason that there seems to be so much RDP traffic, which we still have to analyze.
But filtering for RDP, we only see the first packages, the rest are encrypted. So we have to decipher it.
However, we can see that the attacker has used Mimikatz to download a PFX file from the computer's administrator (see the last question and scroll a bit down in the followed TCP stream).
A PFX (Personal Information Exchange) file, also known as a PKCS #12 file, is a binary format that stores a user's private key and corresponding X.509 digital certificate.
Its name suggests LOCAL_MACHINE_Remote Desktop_0_INTERN-PF.pfx] that it is used to encrypt RDP traffic. A detailed Guide to decrypting RDP can be found here:
And here:
Fortunately, the attacker has base64 encoded the content, and we see the entire file in this format. So we copy the content and process it to create a PFX file, from which we get the key used.
To avoid strange encoding errors, we use the same function in PowerShell to get the base 64 encoded content into a PFX.
Next, we convert the PFX to PEM format, and from the PEM format, we derive the key.
It is important to know that if a PFX file is retrieved from Windows, a password might have to be set. In this case, Mimikatz did it, and the default password is set to mimikatz.
To decrypt the traffic in the PCAP file, we can now can use Wireshark. By following the path
Edit→Preferences→Protocols→TLS→Edit… (RSA keys list) We can add the key as shown in the picture below.
It's important to set the Protocol to tpkt and the port to 3389. A password is not needed.
To confirm that the decryption worked, we can now filter for RDP again, but this time we retrieve more than 17.000 packets.
The next task we have to do is to follow the TLS stream to see in plain text what was exchanged during the RDP traffic. At this point, I would like to note that I have switched to my main computer with Windows 11, because my Kali VM could not cope with following the entire RDP traffic. Furthermore, neither my Windows version of Wireshark nor my Kali version of Wireshark were filtering correctly inside the stream. As a result, I could find secret.txt.txt at first, but not later. Furthermore, the UTF-8 characters are displayed differently in Kali, so this solution can probably only be recreated on a Windows machine.
Now, we follow the TLS stream.
Right-click on the first packet RDP packet No. 62 → Follow → TLS Stream.
We can see that the traffic contains plain text as well as strange gibberish, but the cleartext contains a space after each character.
Since I couldn't search properly in Wireshark and the program crashed, I saved the content of the TLS stream to a file and opened it with Windows Notepad. We know that the question is about the case number, so we first search for c a s e.
We find something about it, scroll up and down a few hundred lines, but don't find a number.
On closer inspection, we see the plaintext HTML format. Ok, let's search for H T M L...
… And lo and behold, we have two hits. The message by Elf McSkidy and, 20000 lines before a number in plain text, the case number. This can be found in line 56524.
What is the content of the yetikey1.txt file?
We are now looking for the yeti key. So we search for Y e t i and in line 91038, we find something about it. But now we have some scrolling to do.
Here We find my initial search for t x t again, which I was not able to do so again in Wireshark.
About 600 lines later, in line 91638, we find the yetikey1.txt, peppered with spaces that we still have to remove. Personally, I am not directly satisfied with the solution, and think there are more elegant ways in Wireshark, but unfortunately, my versions did not run cleanly.
Last updated
