Fundamentals: DNS Sinkholes

Networking
,
1

NB: Categorized as Networking Tutorial since this is a concept that uses networking. However, it might fall into malware or exploit dev as well. Admins, please change at your discretion.

Given the recent saga of WannaCry and the amazingly hilarious way it was foiled (for now), I think it’s apropos to take a moment to explain sinkholes. So what even is it?

A sinkhole domain is a domain registered (or seized) and used to redirect malware traffic away from its intended command and control servers

Most malware, particularly ransomware, communicates with command and control servers (also called C2 or C&C) in order to receive instructions, updates, etc. Our fearless firefighters of the internet, malware researchers, figured out early on that they could register or seize a C&C domain and take control of a botnet for their own use. After reverse-engineering the malware, they will then often disable it by sending a command to disable the instances on infected nodes.

So what happened with WannaCrypt?

This is actually kind of funny. The MalwareTech blog post explains it in detail, but in the process of researching a sample of WannaCrypt, he discovered that it was calling out to a crazy “random” domain. When he checked to see if it was registered, he found it wasn’t and promptly registered it. Standard procedure. The funny part was what happened next: everything stopped and nobody quite knew why.

They had accidentally discovered a killswitch.

See, the normal process is something like

  1. Register a sinkhole domain
  2. Survey for affected machines and reverse engineer malware
  3. Send disabling command to bots

As the blog post stated, steps 1-3 were actually rolled into just 1 this time. To see why the authors might have coded this, I encourage you to read the article for yourself. It’s a good one.

Anyways, that’s it. A sinkhole is just a way to direct machines with malware into something controlled by someone other than the person supposed to be in charge :wink:

9 Likes
2

So the malware makers never registered the domain themselves?

3

Correct, and that was actually by design.

4

So if the domain isn’t registered, it points… nowhere?

5

Yep. Read the explanation in the MalwareTech article because he explains it so much better than me (also, homie deserves clicks for his good work).

1 Like
6

But it’s actually more common than I realized and definitely by design,.

7

So what I’ve gathered after reviewing your comments and the article is that:

  1. The malware hits some random domain D that isn’t globally registered.
  2. If D is correctly unregistered, the malware continues,
  3. otherwise (i.e., D is apparently registered), the malware quits to avoid being analyzed.

All domains, including globally unregistered ones, appear registered in certain analysis environments. In these environments, an IP is returned for all DNS queries (even those that would fail in the wild) so that the analysts can record all the data the malware sends anywhere.

2 Likes
8

Exactly. It’s a failsafe to prevent analysis.

9

Seems to me to be a weak failsafe. Avoids analysis by rookies.

Oh well, WannaCry did some damage so I’m not hating on them or anything.

But I’m sure that some m4lw4r3z have a few more anti-analysis tricks to use.

1 Like
10

This type of killswitch is actually used to prevent analysis by detecting if it’s within a lab environment. In the lab that you mentioned, any call to a domain that’s not in global DNS will return an IP anyways, as an attempt to capture C&C traffic. These applications will generate an array of several “random” domains and query them. If they all come back with the same IP, they realize that they’re in a lab and exit in order to prevent analysis.

The failing of this particular malware was that it used a single hard-coded domain.

1 Like
11

I think it is indeed a smart failsafe. Smart enough that the researchers didn’t even realise until after they had registered it.

The fact they had thought about a kill switch was smart. And showed they had thought about the potential consequences.

12

I don’t believe it was a kill switch; I think it was an anti-analysis trick.

13

So why would the functionality actually cause it to stop working? That seems like poor design. Or perhaps, done on purpose?

14

It was a bad attempt at an anti-analysis trick. The technique is sort of the result of a very stupid arms race between researchers and malware writers.

First, malware writers would use obscure domains for C2.
Then researchers caught on and would watch for them. They did this by setting up a DNS that would forward all requests for legitimate domains (ones that were registered in some global DNS like 8.8.8.8). All others that weren’t in global DNS would return a lab IP.
Then writers went, “Oh crap, they’re reversing our malware by intercepting our C2 traffic in the lab!” and set up a new mechanism: They would request a handful of randomly generated domains names (different each time) and if they all returned as registered (or even worse, all have the same IP), that’s an indicator that they’re in a lab and they exit to prevent more analysis.

This one appears to have attempted that poorly by only checking a single, hardcoded domain. Therefore, registering the domain and pointing it at an IP meant it thought it was in a lab, even when it wasn’t.

3 Likes
15

This topic was automatically closed after 30 days. New replies are no longer allowed.