Botnet « SecureThinking

Posts tagged Botnet

Friday, August 6, 2010

Part 3: Kraken and Storm Redux: Rebirth of Botnets and Recidivism of Participating Hosts

By Rob Jamison, Manager, Network Intelligence, Managed Security Solutions Group, BT Global Services

In the previous two posts, we discussed the reuse of malware and host recidivism. In this article, we will focus on how pirated software is making the problem all the worse [piracy proportional to botnet size].

While there are many reasons for unsecure configurations, one of the most compelling reasons has to do with using unlicensed — and hence — unsupported software. Yet I don’t believe it would be an overgeneralization to say that those running pirated software are not overly concerned with the confidentiality and integrity of their systems — at least, not as concerned as they are about the licensing cost of those systems. While this is less of a threat to assets residing in a reputable enterprise environment, it is still a compounding issue that grows the ranks of botnets and adds amplification to DDoS attacks.

Most sites offering pirated media and cracked applications are vertically integrated with organized crime-owned botnets. The re-up process (marginal node = marginal $) is partially funded by recruiting unwitting visitors and asking for a virtual handout. Perhaps it is Lady Gaga today, instead of Britney Spears of 1998 — whatever the reason or taste, the content will be offered, loaded with the same core seed – it will compromise the system that downloads it, have that system phone home and put that system to work.

Users unwilling to pay for licensed operating systems in the first place (or unsophisticated enough to know the difference) are more likely to download other pirated software. In doing so, they are positioning an inferior OS (one that has not been patched or even configured prudently) directly in contact with malware-laden content. Often this is audio and visual media – formats in which myriad additional root level exploits exist.

It is difficult to even fathom how many instances of pirated Windows XP are online. Despite Microsoft’s attempt at an amnesty program three years ago, it is doubtful there has been much reduction in percentage, let alone total number, as of today. Some estimates quote as high as 40% of worldwide software is being pirated. Of the counterpoints listed in this blog against RIAA and enforcement of IP statutes, not a single argument attempts to refute that installing pirated software on a system diminishes its security posture. Perhaps the most ludicrous argument for removal of IP enforcement would be that piracy is “safe” for the user and the internet at large.

To move to a technical direction — if the argument that security and piracy aren’t compatible at an application layer (e.g., sharing pirated DVDs via P2P software), it would even be more ludicrous to make it at the Operating System layer. If the OS is counterfeit — either not eligible or the user is in fear of receiving security updates — there is little chance that it will remain a sovereign host. Once compromised, there is much more of a chance that that the keyboard user (to contrast from the remote r00t user) cannot regain control and hence will be unable to restore the ability to update the host. Even if the system owner wishes to legitimately restore state to a time prior to infestation, it’s often impossible. Most of the Trojan software installed on compromised systems today either poison DNS such that the infected computer is browsing to a non-security site, or it injects itself somewhere in the process of the host trying to patch the OS or load current definitions into the A/V application. Once compromised, access to the handful of sites that could offer the user assistance in cleaning up the rootkit isn’t possible without strong technical skills or intervention of a third party.

Here, recidivism is made worse because an initially compromised system will continue to prevent updates and A/V software from being updated, even if the botmasters are behind bars, the C&C nodes have been turned dark, and the user wants to turn over a new leaf and pay for a legitimate OS license key.

For the reasons above, the botnet problem is not getting any better. The resurgence of Storm/Kraken can be chalked up to reuse of code within isometric parameters where their ancestors existed. The confusion over the name of which botnet has conscripted which node when is much less important than addressing the underlying environmental conditions that allow the continued presence of 10^8 node botnets driven by kids with learner permits.

As a parting allegory — the illusion of IT progress was shattered several years ago when the Conficker botnet spread through LANs in the same manner as the Sasser worm (leading to Bobax and eventually Kraken). Today, the Stuxnet Trojan is spreading to systems riding on the same USB drives that Conficker.C did more than a year back (remember past cries to disable autorun?).

The more the security world changes, the more it stays insane!

For more information, please visit:

Original Kraken [Damballa, Royal]: http://www.darkreading.com/security/perimeter/showArticle.jhtml?articleID=211201307
Current Kraken [Damballa, Royal]: http://www.darkreading.com/vulnerability_management/security/antivirus/showArticle.jhtml?articleID=225701438&cid=RSSfeed_DR_News
Original Storm [F-Secure Video and Commentary]: http://www.youtube.com/watch?v=kH8cS1AkqiI
Current Storm [Felix Leder]: https://www.honeynet.org/node/539
Mariposa Demise; Technical Ability of Mariposa Botmasters [Panda, Defence]: http://www.pandasecurity.com/homeusers/media/press-releases/viewnews?noticia=10085

To read the full paper on Kraken, click here.

Thursday, August 5, 2010

Part 2: Kraken and Storm Redux: Rebirth of Botnets and Recidivism of Participating Hosts

By Rob Jamison, Manager, Network Intelligence, Managed Security Solutions Group, BT Global Services

In yesterday’s post, we discussed the reuse of malware. In today’s article, I want to focus on how botnet “breaking” is effectively a zero-sum gain, as most nodes previously rendered benign by DNS sinkholing have rejoined some other botnets [host recidivism].

The sophistication of the botmasters pales in comparison with the persistence of the problem. An owner unable or unwilling to secure these hosts affords their systems to be cyber-magnetically drawn into some future botnet. Call it magic or fate — no compromised system just sits there and serves up the connected monitor web advertisements for timeshares and Viagra, without simultaneously offering other services to a Botmaster. Just because a host has not been engaged in a SPAM campaign or doesn’t have an active keystroke logger installed doesn’t mean that the ability is not resident within the rootkit installed. In today’s market, ignoring bot earning potential is akin to leaving money on the table, from an organized crime point-of-view.

A system not patched against MS09-123 is likely not going to be patched against MS10-123. This is primarily because the decision to patch is most typically made by implementing and enforcing a policy that stipulates the process of perpetual patching for the lifecycle of that piece of software. The merits of an individual patch and the situational risks surrounding the vulnerability at hand are less likely to come into play since so much software needs patching so frequently. Modes of interaction of a vulnerability in a distinct piece of software cannot always be anticipated because the instantiations of that vulnerability (no matter how minor) in custom configurations and interactions with other objects are too numerous to fathom.

End users are not typically engaged in formal policy adherence to their home systems — that is not the claim here. However, the principle carries forward as those end users who roughly follow a best practice configuration seek out and engage offering by the specific vendors they use, most notably the automated processes allowing for silent and automatic patching of the software. Whether the software belongs to Adobe, Microsoft or Apple, most major vendors offer means for systems online to update themselves before or shortly after vulnerable binaries are executed by the user.

These (and formally documented) processes are made for repeatability. So a missed patch is rarely as much as an oversight as it is another in a pattern of computer activity (really, lack thereof) that’s put into motion by actions that the responsible party made at the original installation of the software, up to and including the OS installed on that host.

An example shown in a 2008 Computerworld article (“Update: Two-thirds of Oracle DBAs don’t apply security patches” [1/14/08]):

“The results, which come even as Oracle is scheduled to release its next batch of quarterly Critical Patch Updates tomorrow, showed that 206 out of the 305 surveyed said they had never applied any Oracle CPUs. Just 31 said they had installed the most recent security update from the company. In total, only one-third said they had ever installed an Oracle CPU.”

Considering this survey deals with administrators who are skilled in technology, but may be fearful of uptime consequence by introducing the patch, it doesn’t bode well for end users who feel ambivalent towards their responsibility to update their systems. Whether the cause of the updated state erosion is active or passive, recidivism is high for all of these hosts.

To read the full paper on Kraken, click here.

Wednesday, August 4, 2010

Kraken and Storm Redux: Rebirth of Botnets

By Rob Jamison, Manager, Network Intelligence, Managed Security Solutions Group, BT Global Services

Last month, we posted an article on the return of the Kraken botnet. In addition to Kraken, the Storm botnets have also made a slight comeback on hosts once belonging to the recently decimated Mariposa Botnet. Over the next several days, we will examine the technical issues surrounding the return of these botnets, with a focus on the following areas:

The reuse of malware by persons of less technical sophistication than the original authors [lowering barriers to field entry]
That botnet “breaking” is effectively a zero-sum gain, as most nodes previously rendered benign by DNS sinkholing have rejoined some other botnet [host recidivism]
Pirated software is making the problem all the worse [piracy proportional to botnet size]

In this commentary, we’re covering the first area since there is plenty of evidence to support the claim that people of less technical sophistication than the original authors are reusing the malware. Consider the attestation of Panda Security’s Pedro Bustamante:

“Our preliminary analysis indicates that the botmasters did not have advanced hacking skills. This is very alarming because it proves how sophisticated and effective malware distribution software has become, empowering relatively unskilled cyber criminals to inflict major damage and financial loss.”

If the case were that Mariposa was a low tier botnet (say only 100,000 nodes), perhaps it could be explained away that script kiddy botmasters got lucky for a while. They inherited well, or knew the “right people” in lieu of the “right stuff.” However, this was not the case. Mariposa was a 10^8 node botnet, and that, by any estimation, is a really big number.

The position of the botmasters being N stages removed from the original authors supports the arguments that a botnet in itself is mercenarily a commodity. To compare, entities that own the most barrels of petroleum at any given time are neither producing nor consuming petroleum. They are “possessing it” in an assumption of risk (and hence profit) that comes from stewardship between the time it is made available and the time it is consumed by a refinery. They don’t need to know details of either the production or distillation of the content, and they have no special skills (or at least display none) in either area. This is similar to why these botmasters don’t need the same technical abilities that the authors of the original code exhibited. Would a case be heard where the writer of Trojan software would sue a botmasters for financial loss or defamation??

It would be difficult to defend this position if Mariposa was not the single biggest documented botnet in the world back in January. As skeptical as we are about actual numbers of nodes reported as participating in a single botnet — if the actual number was only 1/100 of the touted number (which would be one hundred-thousand) — it would still be greater than the total number of computers in each of half the world’s countries. Just consider that several people lacking technical sophistication, unaligned with any foreign government, were harnessing the power of a 3-gigawatt-per-hour computing center.*

* Calculations for emphasis only; assume 300W PSUs, 10 Million hosts online at a single time.

To read the full paper on Kraken, click here.

Wednesday, July 14, 2010

Kraken is Baaaaaaaack

By Senthil Venkatachalam, Product Manager, and Tom Le, Director of Research and Development, BT Managed Security Solutions Group

Botnets, in general, are very dangerous and difficult to extinguish. Within the past several weeks, we’ve learned the Kraken botnet has returned from the dead and is gaining strength yet again.

According to a recent Dark Reading article, the botnet—despite being dismantled last year — has recently compromised more than 318,000 systems. That is nearly half the number reported at Kraken’s peak!

How does Kraken work?

Kraken came to the fore in 2008, after infecting hundreds of thousands of computers and causing them to send enormous numbers of spam emails. While the authors of Kraken were arrested in 2009 and the network was disabled, the new Son-of-Kraken seems to be a variation which re-uses Kraken’s malicious code. This code is propagated by a botnet framework – or butterfly framework – which is known for its efficiency in spreading such malware. Some of you might remember another famous and large botnet, the Mariposa botnet, which also used the butterfly framework.

Detecting the “classic” Kraken

Botnets are difficult to prevent, and, once a network is infected, are even more difficult to detect. If you are using anti-virus tools, Kraken is nearly impossible to detect. AV defenses and anti-malware defenses are often disabled by bots during the original infection. Therefore, IT professionals must gain network level detection applications. Suspicious activities that can be used to detect a botnet include:

DNS lookups to certain domains
Traffic on unusual (typically high) port numbers
Connections (or attempts) to IPs in a known range
Network protocol violation in datagrams or sessions traversing firewall (e.g., encrypted traffic over port 80, or non-SSL over port 443)
Excessive outgoing emails or other activity not usually associated with business traffic

But to assume you don’t have a botnet infection because there are no visible symptoms is a mistake. Because bots seek to avoid detection, you need to constantly check firewall and IPS logs to unearth an infection.

Preparation is key

George Hulme said in a recent InformationWeek article, “One thing is certain: current methods of bot detection and remediation are not getting the job done.”

It’s essential that companies ensure they have maximum and continuous early-warning security measures in place to protect the integrity of their assets and mitigate risks. For BT Managed Security Solutions Group (MSSG) customers, the good news is that a botnet detection module is a standard Managed Secure Monitoring service available to all customers.

BT MSSG has had significant success in using its customers’ firewalls to detect botnets through log analysis and event correlation. Based on a fundamental understanding of botnet behavior, the BT team reasoned that since every botnet needs to call home at some point in order to be activated, outbound messages traversing a firewall will create detectable patterns of behavior that accurately indicate botnet activity before it has the opportunity to take over your network.

One question remains — is your company prepared for the Son-of-Kraken?

Tuesday, May 18, 2010

The Worm That Turned, and Turned Again: Conficker Exposed

By Pete Russo, Senior Marketing Manager, BT Global Services

It’s not often that cybersecurity gets its moment in the sun in the mainstream media. Sure, we get sound bites on the latest credit card breach, VA breach, or password protection strategies. But this report from The Atlantic is full-on investigative journalism at its best!

Mark Bowden, an Atlantic national correspondent, wades deep into the battle being waged by the cybersecurity community to stem Conficker’s spread and defeat the worm entirely.

To read Mark’s article and learn why Conficker would cause trouble for Captain Kirk, click here.