Blog Post

Threat Hunter Olympics: Final Solution

And now for the grand finale of the 2018 Awake Threat Hunter Olympics challenges. If you missed the earlier solutions, you can find them at Part 1, Part 2, Part 3, Part 4 and Part 5.

Well, here it is: the final challenge. Those able to solve the previous 5 challenges will have all the information necessary to create the link where the final challenge is hosted, and login to access the files. Buckle up, it’s going to be a heck of a ride.

Once you visit the URL that you’ve created using the information from all the other challenges, you should see the following files hosted there (after logging in with the creds from the first challenge):

directory listing threat hunting puzzle 6

Below are the contents of WHOIS_the_champion.txt:


Congratulations on coming this far! You’re in the final round, and the competition is about to heat up (let’s hope we don’t melt the ice)! Within this directory are a couple of PCAPs that you’ll need to analyze and solve. To do so will require creativity and cleverness, and may also require a bit of interactivity. As many great athletes have said, remember the basics, and don’t be afraid to dig in and give it all you’ve got! Once you solve the challenges contained within, send the answer to [email protected] Now it’s time to bring home the gold!

The second file in the directory is a PCAP that we can get to analyzing right away. is a zip file that seems to want a password.

unzip file threat hunting puzzle 6

Wonder where we’ll find that…? The last file ends in .txt, but it doesn’t seem very readable does it?

We can see that this is also a password protected zip file (The PK Magic Number may have also given it away).

There’s only one real hint this time around, and that’s the all caps “WHOIS” in the filename. So let’s grab the only file that we can analyze and get to solving!

The Final Countdown!

If we take a look at the protocol distribution of the PCAP, we see that it’s mostly DNS traffic with a tiny bit of WHOIS traffic thrown in.

wireshark protocol distribution threat hunting puzzle 6

There doesn’t seem to be anything particularly interesting about this domain or its WHOIS information (it’s the domain you’re on right now as you’re reading this post).

whois information threat hunting puzzle 6

The name of the file included that hint about WHOIS traffic, but there’s nothing here—I suppose we should move on.

The only other type of traffic is DNS, so I guess we should look there next.

Well those domains certainly have something in common. At this point, we need to figure out what about these domains is interesting to us. There are a few different ways you may be able to do this. You could simply visit each of the domains and see what content they’re serving (ingenious ploy to increase our web page stats, muhahahaha!). You could also look at the nameservers or IP address answers and see if there’s anything that sticks out. The intent was to push you to look at the WHOIS information for each of the domains, and go from there.

awake whois information threat hunting puzzle 6awake whois information threat hunting puzzle 6

Most of the domains should have WHOIS information like that above. However, there are two that should stick out to you:


Their WHOIS information is different than the rest (and yes things are different now that we live in this world they call GDPR ? – but more on that later). The first seems to be sending us some kind of message (that will be relevant later), and the second is hiding its WHOIS info.

At this point, you do need to put on your curiosity hats (they were on already, right?) and actually visit the domains above.

TXT record threat hunting puzzle 6TXT record threat hunting puzzle 6

Ok…so it’s telling us to TXT it? Your first thought may be to send an SMS message to these domains (or the owners—if you texted one of the numbers in the WHOIS info, that’s awesome and I hope the numbers don’t actually exist…or I hope they do…). However, if we keep our heads in networking (more specifically DNS, which is mostly what our PCAP is comprised of), then it makes sense that we need to do something with the TXT records of those domains.

Well that (“PoDtjtoJTaUQBGBF3NVcWZteacyXeJLNe”) certainly looks like something.

And *that* (“SECRET=I4YGYRDTINWE64ZT”) certainly looks like something as well. At this point, we’ve actually solved Part 1 of the final challenge, we just need to figure out what to do with the information we’ve gathered so far.If you remember, we have two password protected zip files that we downloaded along with the first PCAP. I think it makes sense that the two TXT records we retrieved are going to help us decrypt the zip files.

Unfortunately, that’s the only password so far that works on either of the files, so we’ll have to keep looking in order to unzip the final one. We have a new PCAP file to look at for the time being, so let’s start there.

The Final, Final Challenge

Taking a look at the PCAP will reveal that it is filled with email traffic.

wireshark protocol distribution threat hunting puzzle 6

If you go ahead and follow the first available TCP stream, you’ll see the following:

SMTP traffic decoding threat hunting puzzle 6


Hmm, see anything that pops out at you? What does this look like?

It should look like a 2-factor authentication email. Now, I know you’re familiar with 2-factor authentication (use it whenever you can, seriously). Oftentimes, the delivery mechanism is either an SMS message (not a great setup), or an application you can download to your phone—and yes, sometimes it’s an email.

If you follow a few more TCP streams, you should see more of the same, but to different email addresses. There’s not much to go on if we have a PCAP full of only 2-factor auth emails, so let’s see if we can find anything else. The emails we’ve seen so far have been sent from “[email protected]”, which seems to indicate that the email address is used solely for that purpose. Let’s see what other email senders there are.

It looks like there are three other email addresses. Let’s check them out in the PCAP.

SMTP traffic decoding threat hunting puzzle 6

There we go—something new to munch on, and another nod towards the fact that we’re dealing with 2-factor authentication. It may also be the case that the algorithm is something of interest.

SMTP traffic decoding threat hunting puzzle 6

The response mentions TOTP, and that it’s not yet being used. If you know about 2-factor auth algorithms (or you do some googling and wiki reading), then you know that TOTP is a 2-factor authentication algorithm that is based on time in order to be more secure than its predecessor (HOTP), which is based on the number of times the one-time password has been requested. Considering that the email says they’re not yet using TOTP implies that the 2-factor authentication that we’re seeing in the previous emails is generated by the HOTP algorithm.

The last email in this chain is just a fun jab at management ?

SMTP traffic decoding threat hunting puzzle 6

The final email that isn’t sent by [email protected] is also interesting.

SMTP traffic decoding threat hunting puzzle 6

It looks like a user, named Charles Jewtraw (The first Gold medalist of the first Winter Olympics), has just signed up for an account and was informed that he will receive a 2FA token when he attempts to login to his account. If you filter the PCAP for only emails to Charles Jewtraw, you’ll see that after this initial email there are 13 2FA token emails.


Let’s recap—we have quite a bit of information now.

  • The 2FA algorithm being used is HOTP
  • We have the original signup confirmation email for one (and only one) person: Charles Jewtraw
  • Mr. Jewtraw has received 13 2FA codes
  • [email protected] sounds like a real jerk (he’s actually pretty awesome ? )

So, what do we do with all this information? Remember the first part of the challenge wayyyyyy up at the top of the page? There was some WHOIS information that I said would become relevant later. Well, the future is now, people.

WHOIS lookup threat hunting puzzle 6

This hint is certainly esoteric, and I admit that I may have made it more difficult to interpret than I intended.

First things first, it’s saying that something about the Final Flag, 4 Times and the Description being in the WHOIS record. It also has the City/Province listed as “Bechar,code”. This seems to indicate that character encoding is involved somehow (or at least, I hope it does—ok seriously I apologize. This was hard ?).

Did you also notice that the postal code is eight numbers long and that the admin phone starts with +65 (Singapore)? Either whomever registered this domain lives in Algeria and has a phone number from Singapore, or this is part of a message somehow.

Note: I thought that I was being clever by choosing Bechar, DZ since I could string together Bechar with code to read “Be char code”. In hindsight, it wasn’t that clever, and is actually misleading since “charcode” is technically a character encoding on its own and doesn’t just mean “character encoding” in general.

At this point we know that there’s some kind of data, encoded in the record somehow. The only data that doesn’t have a meaning at this point is the numbers. For this, let’s head to cyberchef for help!

Let’s start with the 8-digit postal code. Go ahead and plop the numbers into the Input for Cyberchef. There are a ton of different encodings that you could try out, but once you drag the “From Hex” recipe over, it should be apparent that you’ve made the right decision.

cyberchef hex decoding threat hunting puzzle 6

“a us” doesn’t seem to mean much on its own, so let’s continue to add the numbers that we see in the record.

cyberchef hex decoding threat hunting puzzle 6

Well look at that. “a users fure 0TP”.


In hindsight (apologies again), “fure” is a poor way to abbreviate “future”, but hopefully the point you see now is that we’re looking for a user’s future onetime password (aka 2FA token). How would we do that? We have the 1-13th OTP for Charles Jewtraw, but how to we get a “future” one?

Enter The Python

Luckily, Python has a module that makes it ridiculously easy to calculate one-time passwords. All we need is the base32 encoded secret… Do we have one of those? Oh wait, remember Part 1 of the challenge above? One of the TXT records was the password for the PCAP, the other was what?


Oh yeah that’s right, one of the TXT records included a “SECRET” : I4YGYRDTINWE64ZT. Could that be the base32 encoded OTP secret we’re looking for? Well, what happens when we base32 decode it?

cyberchef hex decoding threat hunting puzzle 6


Oh! “Gold’s Close”! I was leaving an encouraging message.

So that must be the secret. Let’s try that with the Python module.

That gives us the first 14 OTPs using HOTP as the algorithm. Let’s compare those OTPs with the ones that we see for Charles Jewtraw in the PCAP. We can dump all of those from the PCAP using this fun one-liner.

If we compare the two lists, we’ll find that they are completely identical except for the 14th entry in the output of the Python script: “957826”. Why is that significant? Remember that we’re looking for a future OTP. Based on the fact that the OTPs we calculated using Python and those in the PCAP match for the first 13 codes, indicates that not only are we using the correct secret for the user “Charles Jewtraw,” but also that “957826” is a future, currently unused (as far as we know), one-time password. Let’s try using that code to unzip the ontime.txt.

Hmmm, that didn’t work. What else do we need? Oh, that’s right! Remember in the WHOIS information? It said “4 Times Description In.” The data that we decoded was not in the WHOIS record four times, so it must mean something else. Let’s try multiplying the OTP by 4, which equals “3831304.” Nope, that doesn’t work either…

What if we type the 6-digit code four times, “957826957826957826957826”?

Oh snap! Nailed it!

Method to the Madness

I don’t always make the best decisions, but I like to think that they are at least made on purpose. The final challenge may have seemed more chaotic than the previous challenges, but there were reasons I did the things that I did.

I added TXT records to the challenge because it’s one place that attackers have been known to hide data. In fact, TXT records are often used by DNS tunneling tools. Analysts sometimes forget that TXT record requests are occurring on their network, and what legitimate requests look like versus malicious requests.

I added the second part of the challenge mostly for fun (and not the psychopathic kind, I promise). While doing an investigation on a customer’s network, I did encounter some 2FA email traffic in plain text, which I thought was at least a bit curious. I started thinking about how such a thing could pose any risk, and that’s how I came up with the (admittedly far-fetched) scenario in the second part. I was also excited to add the possibility of using Python (since it’s something that I’ve used extensively throughout my career to solve problems).

Finally, I named the zip file “onetime.txt” to remind you that the extension (in this case “TXT”) is irrelevant to what the file actually is—which is something I’ve seen security analysts forget occasionally.


Those of you that attempted the challenges, I hope you had as much fun solving them as we did creating them (even if you didn’t make it all the way to the podium). Congratulations again to the winners of the challenge:


  1. John Lampe
  2. Andy Hagar
  3. Ryan Nelson

And some extra congratulations to those who made it through all of the blog posts!

Troy Kent
Troy Kent

Threat Researcher