This time we try to reverse every Base64 string that will yield a ASCII output. Since, in Base64, padding characters are not required to be in every Base64 string it is a safe assumption that there are other strings polluting the DNS traffic, maybe even attempting to hide something else. If we try to reverse the character order and then Base64 decode we see the following:Īfter attempting to reverse then decode, we see some common subdomains but nothing that hints at where the flag might be. It is at this point where we may be scratching our heads wondering whether these strings are related in some way. In Base64, the padding is only found at the end of the string it’s never found at the beginning. When we look at the strings closely we notice some have the padding (equal signs) in the leading section of the string. Instead of instinctively concatenating the Base64 which decodes to nothing useful, we must first analyze the strings individually (Figure 2). It is at this point where many participants encountered the first major hurdle of the challenge. This strongly suggests DNS tunneling between the client and the DNS server. After a quick glance at the subdomain field, we can correctly identify the strings to be encoded with Base64. There are suspicious queries for odd subdomains of many well-known websites.
When filtering on DNS traffic in Wireshark, the packet capture becomes much more manageable with only 178 interesting packets. I will be analyzing the challenge, both the solution as well as conceptually.įor the challenge, we are provided a packet capture with roughly thirty-two thousand frames, and a hint: “Knock on the door and get the flag.”Īfter a brief opportunity to analyze the packets in Wireshark, we can see there is anomalous DNS traffic (Figure 1). At this year’s ISTS 16, I had a great opportunity to create a forensics CTF challenge which I thoroughly enjoyed making.
0 kommentar(er)
