Insomni’hack 2023 CTF Teaser – DoH writeup

For this 2023 edition, i chose to focus on the DoH (DNS Over Https) protocol because it has gained popularity for attackers as a command and control (C2) communication channel for hiding DNS traffic through HTTPS rather than using the traditional DNS tunneling. In this post, i will describe in details how to solve the challenge.

For this challenge, i used the famous Godoh C2 framework maintained by Sensepost that uses DNS-over-HTTPS as a transport medium. For more details about how it works in practice, please refer to their article here.

The Powell Motors company provides a PCAP file which contains evidences of a potential data exfiltration with a large volume of suspicious DNS over HTTPS (DoH) requests. By analyzing the network traffic behavior, CSIRT team discovered that the attackers used the Godoh C2 framework as a covert channel for command and control (C&C) or data exfiltration to bypass security measures. Since the organization performed SSL break/inspection, all DoH traffic can be extracted from the PCAP Capture and analyzed. However, the security team was not able to find a way to decrypt data exchanges between the client and the C2 server. Some security researchers on social media also pointed that attackers left a backdoor in the C2 server that could allow remote code execution by sending a special crafted message using the C2 client…

• Hint : Among the 5 secret keys returned by the DNS server, one of them is used to interact with the live c2 
• Provided assets
• PCAP capture : 2023-01-20-4023142337.pcap

Abstract

The PCAP capture contains a large amount of DNS-over-HTTPS traffic generated by the GoDoH C2 framework. By analyzing the communications, it appears that the C2 server is still up and running. The active domain contains a list of DNS record types. The obsolete NINFO record type returns a random hexadecimal value which looks like an AES secret key. Among the 5 secret keys returned by the DNS server, one of them is used by the active GoDoH server to encrypt data blobs in communications. By decrypting the GoDoH exchanges between the client and server, several responses sent by the client include a specific prefix “736372742e6368” followed by a command-line. By modifying the GoDoH client, we can send a special crafted message back to the server to perform remote code execution. Once exploited, the user is chrooted to a particular directory with a restricted shell. By using common bypass techniques, the user can break out of the chroot jail and find the flag.

Exploitation

Tools used

• Wireshark

• Golang

• Docker

• GCC

By analyzing the PCAP file using Wireshark, we can find a lot of DoH traffic using Google provider and two DNS lookup requests with an unknown type id 56 in the middle of nowhere… If we do a quick search on the Internet, this kind of id refers to the NINFO record type (ref. https://en.wikipedia.org/wiki/List_of_DNS_record_types). Maybe this kind of DNS record could store valuable information…

Let’s start by querying the insomnihack.tech for NINFO records and see if there is something interesting.

Extracting all possible AES keys returned by the NINFO record (Among the 5 possible keys, there is one used by the C2 server to encrypt blob data)

The quick and easy way to understand exchanges is to replay the network traffic from the PCAP file against a GoDoH server locally.

If we look at the TCP streams on Wireshark, we can extract the following parameters:

• name parameter refers to the DNS lookup response sent by the C2 client.

• type parameter refers to the record type id.

DoH TCP Streams

These parameters can help us reconstruct the DNS lookup responses made by the client.

Next, we can develop a simple script to parse the PCAP file and replay the GoDoH exchanges.

To specify the AES key from the command line, we can use the custom GoDoH project here. This will help us save time when testing AES keys on our local server.

Starting GoDoH server by specifying an AES key

If we pick up a wrong key, the server will return errors that indicate that it was not able to decode and decompress the encrypted data blobs:

We can restart the local server by specifying another AES key until we find the right one. Once the right key is found (9773e2216d31e339b69b2b9ed0c9cf58), the output helps us identify what kind of commands were issued by the attackers from the C2 server: