As Cryptolocker continues to proliferate, our security team diligently monitors this threat to keep our customers from falling victim to it. Beyond threat protection, we take our responsibility as security professionals seriously and make every effort to keep our audience informed of the latest developments with this and other malicious Internet events.
Last week, we hosted a webcast discussing in greater depth the way Cryptolocker attacks and how the IT security community has reacted to stop this threat. In addition, we revealed how we proactively contained Cryptolocker before it was recognized as a threat and why we’re able to stay ahead of new variants.
During the end of our presentation, we enjoyed a stimulating discussion with our audience as they asked many pointed questions related to the Cryptolocker threat and others like it. For the benefit of all, we decided to share a few of the most riveting ones.
Since Cryptolocker’s evasion method depends mostly on its Domain Generation Algorithm, is there a critical frequency at which new domains are introduced after which the power of predictive analytics would fail?
Our analytics monitor small time windows for DGA names requested in association. Malware-infected systems will periodically attempt to phone home, and when they do, they will go through a pre-determined number of domain name candidates generated at that time. DNS queries are resolved within milliseconds, so whether it is a few to a 1000, the time frame over which the malware will exhaust its attempts is within our small time window. Neither the frequency of the phone home attempts, nor the number of domain name candidates generated is critical. Also, if new versions of the DGA are released, it will not cause the analytics to fail. The analytics examine the malware-infected systems’ DNS query behavior only, rendering the DGA itself behind these names irrelevant.
If a bot uses a hardcoded IP address, can the web gateway do a reverse lookup against your database before it allows the connection?
While many bots avoid hardcoded IP addresses because they’re easy for law enforcement or security providers to work with ISPs to shutdown, they do still exist. Today, we don’t intercept the direct IP-based connection to enforce it; however, we’re actively working on a solution to fill this gap.
Even without this capability, our unique layer of network security helps protect organizations from many threats or vulnerable systems (e.g. users roaming outside the network perimeter) that traditional security solutions can not. But there’s never a silver bullet, so its important to choose the right complementing layers. A firewall with a built-in blacklist of known malicious IPs could help, but most firewall providers don’t have the global visibility or predictive analytics to catch what we can.
Does this work for polymorphic P2P bots like Zeus Gameover that generates thousands of random domains per day, and doesn’t have a central Command and Control server?
Most malware today is either polymorphic or metamorphic, but these terms relate to the binary variants that are generated – not the phone home activity to C&C servers.
Zeus has become a family of various variants of malware. The variant you’re describing is using a DGA (domain generation algorithm) with a fast flux network, which is exactly the same as Cryptolocker. In fact, this has been occurring frequently since 2007. The “Conficker” family of malware was the first big botnet to use a DGA. “Storm” was the first big decentralized P2P botnet to use fast flux. Today, DGAs, fast flux, double fast flux (i.e. decentralized malicious DNS name server), and DNS tunneling is used. For a deeper dive on this topic, you can read our white paper on the role of DNS in botnet command and control.
So yes, we would predict the domains that Zeus uses, and the corresponding and/or associated IPs in a similar way to Cryptolocker. However, we have dozens of other algorithms that detect co-occurring DNS requests, DGA-looking domain names, and other complex patterns that may also be applied to Zeus.
How does OpenDNS deal with a DNS changer type compromise where the users DNS settings are altered and no longer point to OpenDNS?
We always recommend that customers set firewall rules to prevent DNS traffic to be sent to any IP address other than OpenDNS’s two anycast addresses. This best practice will mitigate threats that maliciously change the system’s DNS settings.