5

I read about the release of a free dataset of malware related DNS queries called "Predict". A researcher or network security team can download or query this data set and use it to identify malware communication using DNS. Commercial vendors are already providing such services.

I know of two ways that malware might use DNS.

  1. Look up the address of a web site it is supposed to communicate with for command and control purposes.
  2. Use DNS itself to tunnel.

It seems like the dataset in the news article could protect against both.

In that first use, the malware program generates a number of domain names and queries each of them until one gets resolved to an IP address. The bot then contacts the IP address of the command and control server. This was a handy way to 1) Not reveal specific IP addresses in the malware itself. 2) recover if a particular Command and Control server was taken down (or blocked by the network admins).

DNS in the second use is harder to stop because it communicates via DNS itself instead of TCP/IP. Using a DNS server to try and filter traffic like this might be impractical.

So, cooperation like the "Predict" dataset makes malware use of DNS more risky because it will, on a daily basis, collect tens of thousands DNS queries and inform the world. It won't find them all, of course, but probably enough to make use of DNS more risky.

So, knowing this, why use DNS at all? Wouldn't it be easier and safer from the malware's point of view for it to simply contact one or more direct IP addresses instead of using DNS? Why not just skip registering domains and just use IP addresses that blink in and out of existence and serve the same purpose? Perhaps the problem of slowing down DNS by inpspecting DNS traffic still prevent full use of a dataset like "Predict"?

  • Reading the description of this dataset in the linked page, I wonder how they filter out legitimate domains from their lists (malware may try to contact legitimate domains to check internet connectivity for instance, or just use them as decoy). I wonder this specially when I see the two big "download.microsoft.com" and "crl.microsoft.com" in their daily feed words cloud picture: I fear that sink-holing such domains may have some side effect against Windows update capabilities... – WhiteWinterWolf Jul 27 '15 at 15:17
  • DNS can also be the mechanism by which a CnC distributes operational instructions - consider www.command.example.com CNAME attack-target.google.com.example.com – symcbean Oct 25 '16 at 15:34
7

Note: PREDICT transitioned to IMPACT

Is this the end of malware use of DNS?

No. Might tweak the landscape a little, but not hugely.

It seems like the dataset in the news article could protect against both.

It's useful for catching people using malware that other people have caught before. It is not useful for catching someone who sets up a burner domain just for their attack against you, or someone who hasn't been caught by someone else yet.

DNS in the second use is harder to stop because it communicates via DNS itself instead of TCP/IP. Using a DNS server to try and filter traffic like this might be impractical.

There are "DNS firewalls" that perform this sort of blacklisting; perfectly practical. However, again, severely limited by the rules of the "blacklist" game.

So, cooperation like the "Predict" dataset makes malware use of DNS more risky because it will, on a daily basis, collect tens of thousands DNS queries and inform the world. It won't find them all, of course, but probably enough to make use of DNS more risky.

So, knowing this, why use DNS at all?

Something like the PREDICT GT Malware Passive DNS dataset (hereafter PREDICT-GTMPDNS) incrementally increases the risk, but I certainly wouldn't say it significantly increases the risk. Malicious operators are comfortable operating in a world where their DNS-based web sites can be interdicted by filtering proxies, where their mail servers can be blocking using RBL, and where firewall rule routinely try to restrict egress traffic.

One of the reasons they use DNS is that it's difficult to block at egress - due to the indirect nature of DNS, you can't easily block some of it without blocking all of it. You can even have DNS pointing somewhere benign, then cut it over to somewhere malicious briefly while you use it, then point it back... hard to do with an IP, easy with DNS.

Wouldn't it be easier and safer from the malware's point of view for it to simply contact one or more direct IP addresses instead of using DNS?

Historically, the inflexibility of direct IP addressing has lessened it's attractiveness. PREDICT-GTMPDNS could help reduce DNS's attractiveness, but not enough to rule it out.

Why not just skip registering domains and just use IP addresses that blink in and out of existence and serve the same purpose?

It's harder to have IP addresses "blink in and out of existence" than it is domains. And once you send out the malware with a hard-coded address, it's stuck on that address, and you can't just blink it out of existence without shutting yourself off.

Perhaps the problem of slowing down DNS by inpspecting DNS traffic still prevent full use of a dataset like "Predict"?

The DNS inspection cost is low enough not to be an issue... the real problem, as with any blacklist, is the sample size and turnaround time. If your database inputs cover 50% of the malware out there, that's insanely awesome... and still leaves one out of every two exploits free to maraud. And let's say malware is found, submitted, run, and indexed a day after release... that's 24 hours in which that malware can run free and clear before the database catches up.

In reality, I think the inputs to PREDICT-GTMPDNS will be both less comprehensive and slower to catch up with new malware releases. Playing catch-up sucks.

That's not to say PREDICT-GTMPDNS isn't an awesome idea. It is. But it's not any kind of silver bullet.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.