- DynWiFi
- Corporate ›
- DynTLD ›
- Dynect ›
- DynDNS.com ›
World leader in DNS, email and domain solutions.
We at DNS Inc. are committed to security, especially when it comes to the use of our services for illegal activities. Our White Hat reputation has been earned by proactively policing and cleaning our system and quickly responding to operators who report issues – law enforcement agencies locally, nationally, and internationally. We perform workshops for LEOs about how to better identify and recognize nefarious activities and we participate in various operator and security groups, forums, and lists – many of them private to the public.
Damballa, a security company which claims to protect “businesses from targeted attacks used for organized, online crime,” recently posted a research paper (PDF) regarding a “spamming botnet” called ‘Kraken’ which they claim to have “400,000 distinct victims observed daily”
In a related announcement, Damballa claims that hundreds of DynDNS hosts are being used by this botnet (PDF).
The Damballa list was a surprise to us and we diligently researched the hosts listed in this paper and found that none of them actually exist in our system. We want to assure everyone that we have researched these claims and found no DynDNS hosts are being used in conjunction with this supposed ‘botnet’.
We encourage lively and constructive discussion on any of the opinions expressed on our blog. You can read what others have said and share your own thoughts. Please keep it documented, friendly and on-topic. If your comment does not appear immediately, do not panic: it may mean that it is being held for moderation by our filters, in which case we will get around to reading it soon.
On May 2, 2008, Paul Royal said:
I think you could be more rigorous. Even if the botmaster has already unregistered their domains, there’s an evidence trail that everybody has already seen.
md5 | domain | ip | virus_name | process_date —————————————————+——————————-+———————-+——————————+———————88a94a282417ee2a8c17bc6ee3613de9 | ggwypum.dyndns.org | 66.29.71.239 | Spam-Mailbot | 2008-01-07
00ec1421e9e661b54ce500b5d23e8933 | smhburg.dyndns.org | 66.148.72.106 | Spam-Mailbot.gen | 2008-03-01
0e84eaa3690795853303f726312c1430 | smhburg.dyndns.org | 66.148.72.106 | Spam-Mailbot.gen | 2008-03-03
2c1012e89212af4cc037733abfed8103 | smhburg.dyndns.org | 66.148.72.106 | Spam-Mailbot.gen | 2008-03-04 1d51463150db06bc098fef335bc64971 | gyuzohut.dyndns.org | 64.21.181.87 | Spam-Mailbot.f | 2008-03-21 236c2514eab1f64db12e09b165cb3fa8 | rffcteo.dyndns.org | 209.160.65.66 | Spam-Mailbot.f.gen | 2008-04-13 58b61f92f1369bdd6e6065639f951d01 | ggwypum.dyndns.org | 209.160.65.66 | Spam-Mailbot.gen | 2008-04-14 6c371a38aacf6a18f1efb48086f92e8d | ggwypum.dyndns.org | 209.160.65.66 | Spam-Mailbot.gen | 2008-04-24(8 rows)
On May 4, 2008, Jeremy Hitchcock said:
We looked at a database dump before you published your “research” and found less than 10% of the hosts that you mentioned. Most of them were in your account that you created and the others (a total of 4) were deleted two days after your story but through no connection to the results you published. When we actually looked into your results several days afterwards, only your hosts remained. It isn’t a factor of us not catching it quickly enough, your data is weeks, months, or based on other data provided to us, years old.
As with any security related activity, we aggressively take things down when we detect them or when they are reported. Since your practices are based on secrecy to generate subscriptions to your “list”.
Even those results you post here don’t exist.
On May 5, 2008, Paul Royal said:
The hosts published were those that Kraken bot malware has been
engineered to look up and does look up, regardless of whether they are
registered. The hosts I provided, which you remark on by writing “Even
those results you post here don’t exist” also contain a process_date,
which corresponds to the date Kraken malware was processed, the host
looked up, and the resolve IP of the host at the time of host lookup.
Further Kraken malware analysis and the domain name corpus it looks up
is corroborated by ThreatExpert:
http://blog.threatexpert.com/2008/04/kraken-is-finally-cracked.html
http://www.threatexpert.com/blog/kraken/output_list.txt
http://www.threatexpert.com/report.aspx?uid=52accf15-a173-4f90-9482-b2634c151d87
TippingPoint:
http://dvlabs.tippingpoint.com/blog/2008/04/28/owning-kraken-zombies
http://dvlabs.tippingpoint.com/pub/cpierce/kraken_hosts_ordered.txt
and others:
http://malwaredomains.com/?p=151
Are these people also making things up? Why would they, or we for that
matter? That your service was used for for a large botnet and you’ve
decided to deny that it happened does nothing to solve the problem.
Josh Anderson (of the afraid.org DynDNS service) has made it such that
the *.mooo.com Kraken domains can’t be registered and Damballa has
directed a subset of the domains to the Georgia Tech Karstnet sinkhole
to prevent their registration. Yet, anyone can still register
unregistered the non-blocked hosts (which include the *.dyndns.org),
which is exactly what TippingPoint did. They write, “Armed with this
information we registered the first of the available hosts and
immediately began getting requests from live Kraken infections in the
wild.” If you really think that this botnet does not exist, register
one of the *.dyndns.org Kraken hosts on that list and see whether you
observe a high volume of TCP/UDP 447 traffic.
Finally, FYI, we’ve received requests from LEO to discuss Kraken and
will be providing them with evidence (malware samples, pcaps of
sandbox runs, etc) soon. If you’d like us to give them a different
position than “DynDNS.org denies Kraken’s obvious use of their dynamic
DNS services and claims it doesn’t exist,” send us an email.
On May 11, 2008, Jim said:
Are we forgetting that most malware authors will use expendable domain names for either a second stage code loader, or command and control channel? Nothing new here.
This is not an issue with DynDNS specifically, but all dynamic-type DNS resolution providers. *.afraid.org, *.8800.org and related. Code gets released and executed every day with dynamic-type DNS host names. Welcome to life on the Internet.
The issue, if any, is what credibility the research has, what host names are actually being used, and of what a proper response should consist.
Simply because the *.dyndns.org FQDNs did not exist at the time of the zone search only means that they did not exist within that snapshot in time. Possibly they were used or plan on being used.
A point about sandbox analysis – It can be useful for an initial quick check on what your captured code does, but should not be trusted. Unless the binary has been reverse engineered and support can be given to the legitimacy of the behavior-based observations, behavior-based on its own is not a reliable interpretation of what your captured code will actually do and with whom it will attempt to communicate.
If there are known good reverse engineered samples of code that point to specific host names, and this is as wide-spread as claimed perhaps simply denying use of the domain from DynDNS’s perspective may not be the best choice. One could use the known hostnames, direct the traffic to a benign host, and generate a list of the addresses exhibiting the kraken behavior and begin the process of notification and cleanup. Someone in .edu land want to volunteer for this? Should be a good research topic for someone…
In turn, the malware authors will simply change embedded FQDNs for newer versions of the code. If the cited numbers are correct, there is obviously an effective malware distribution mechanism.
On May 13, 2008, Jeremy Hitchcock said:
It goes without saying that any free service, such as our Dynamic DNS service, can be used by certain types to perform illegal activities. DNS Inc. has been aware of this type of misuse for years now and vigilanty police our service as a result. We regularly review accounts for malicious activity and those which are being used for no good are immediately taken down.
If you see a hostname under our domain that is up to no good, just contact us by using the information at http://www.dyndns.com/about/contact/. We’ll promptly review your report and take apppropriate action. Use this contact information for botnets, phishing, hacking, copyright infringement, or to report any other illegal activities. We’ll generally reply within a couple minutes.
In the case of Kraken, we did our usual diligence of inspecting the listed hostnames for abuse and took down those that appeared to be malicious. The problem with Kraken for us is its random hostname generation. We don’t want to pre-block hostnames within our domains, because taken to the extreme, we’d end up blocking the entire *.dyndns.org domain, locking out our users from our Dynamic DNS service.
So, to summarize, we don’t deny that Kraken is using our Dynamic DNS service. We’ve taken our standard steps to mitigate the problem from our end within reason (by blocking confirmed Kraken hostnames) and are happy to continue to work with Damballa, LEOs, and others to stop the spread of this virus.