Solving the Malware Domain Generation Algorithm Problem

It’s no secret. The enemy is smart. Malware with built-in Domain Generation Algorithms (DGAs) subvert the old method of IP and domain blacklists, making it more difficult for the good guys. I first learned of DGAs in Mark Bowden’s Book, ‘Worm: The frist Digital World War’. In the book, Mr. Bowden describes how variants of Conficker, instead of using a static list of domains, used an advanced algorithm to auto generate Domain Names used to reach out to its Command and Control ‘C2’ Server. Mr. Bowden tells how he worked with different teams and the US govt to blacklist the domains Conficker would auto-generate; so those domains could be added to a DNS sink hole,  or blacklist, and then machines infected with Conficker would never reach their C2.  While effective for some time, this effort of playing DNS ‘Whack-a-mole’ on a global scale would not prove to be a permanent solution.

Today, we are dealing with Locky Trojan, which employs its own DGAs. There are some excellent technical demonstrations of these DGAs, first one from ForcePoint, demonstrating the DGA in C  code and the second one, from FireEye, demonstrating the DGA in python.

While it is a knee-jerk reaction of any Security Pro to immediate sink-hole any IP addresses and Domains associated with these new threats; it is not a means to guaranteeing you will be protected. There is a better solution.  A longer term solution

1. Use a Proxy. Deny all internet traffic from User Access Layer that does not come through the proxy using a harden browser with a user-agent that is known to the proxy. The default route in the network in this case, just goes to a black hole in the network and packets die.  If Host A,  infected with DGA malware, reaches out to DNS and resolves [ ] domain to x.x.x.x IP address, and reaches out, that traffic dies. . .If Locky can’t access a C2 Server, it won’t get it’s encryption key and cannot encrypt your files.  [ for “Proxy-aware” malware, that is a topic for a different blog later – or check out  Nir Valtman’s Blog on proxy-aware malware ]

2. Use a Default Route to a HoneyPot Logger. The problem with solution 1 is that it only a partial solution. The host is still infected, but it is just not reaching out to its C2 through your network and you don’t know about it. Solution 2 involves the same Proxy mechanism, but here, we change the DEFAULT ROUTE in our networks to go to an isolated honey pot server. Now, Host A,  infected with DGA malware, reaches out to DNS and resolves [ ] domain to x.x.x.x IP address, and reaches out to the C2, this time, it hits your honeypot.  We log connections to this honey-pot server; and any internal host that attempts a connection is either INFECTED or has mis-configured application.  You now not only have kept the host from reaching a C2, but you also have a list of potential infected internal hosts IPs.

3.Use a smart Honey Pot to ID to learn more about what the malware is doing. You can have further visibility into the connections reaching toward your honey pot running Security Onion on it, whose default, built-in open source tool-set, includes BRO, Suricata,( employing the Emerging Threats Database  ) can aid in identifying the type of malware infection and ELSA can tell you country of origin + all kinds of other intelligence you can use to understand malware behavior. Honestly, the Security Onion Tool really deserves it’s own blog, (that said I’ll blog more about Security Onion Tools in the future). Whatever software you choose, Intelligent Honey Pots are a good idea because they help you to know the type of malware the host is infected with, and then that intelligence can be used to help with the malware removal.  The Security Onion is one example of a good Honey pot, it is an powerful tool and Durg Burks has done an amazing job with the SO toolset. There are multiple tools and methods for implementing honeypots, and the methods I describe here are not intended to be the ‘end all be all’

4.  Use a Cloud based Proxy or Auto-VPN. We still have not addressed the issue of HOST A getting infected, and then going off your network to an unprotected network, Coffee shop, Hotel, etc and not being under the protection of your Proxy, Default Route and HoneyPot ANND THEN getting infected. At this point, you would investigate a Cloud based Proxy Service,  OR an auto-VPN to your network. Many vendors have this solution.  Here, HOST A is at Starbucks, but when the machine is booted; it auto-loads the VPN client; or Cloud Proxy solution, and the secure tunnel is built; and HOST A is now actually on your network, ( or using a proxy with your policy) before any true internet browsing happens.  Now all of the same controls still apply to HOST A.

The methods about are one way of solving the problem of black-listing IPs and domains, and keeping ahead of DGAs and advanced malware. I hope you found this helpful!

with gratitude,




This entry was posted in Cyber Security, Technical. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s