Posts Tagged ‘botnet’

Botnet Building Campaigns

Tuesday, May 4th, 2010

The business of botnet building is precisely that – a business. When organizations look to the threat from a compromised asset perspective they too often fail to appreciate whats really happening. A typical reaction is thus “why are they targeting me?”

If you step back a little – somewhere between the proverbial 10,000ft and the weeds – you’ll begin to notice some of the intricacies of whats happening in the criminal botnet building world. Granted, there’s a lot of confusion as the security vendors throw about various threat terminology and often use them interchangeably depending upon their perspective, but in reality it’s not too complicated.

First off, don’t take it personally. The criminals aren’t necessarily targeting your organization because they’ve developed a certain dislike for who you are, rather they’re after the things your organization (and many others) contains. For example, rather than being focused upon stealing the digital keys to your particular corporate banking account – they’re after any keys they can find, and if they happen to stumble upon the mother lode then that’s damned lucky on their part. In all likelihood though they may not even recognize that they’ve obtained the keys until much later. You see, the vast majority of botnet building is automated and, as such, the successful criminal operators harvest so much information they often struggle to sift out the really valuable nuggets. That’s not to say that you can count on them to not recognize the inherent value of what they’ve obtained.

A critical component of modern “commercial” botnet building lies with “campaigns”. While some newbie or highly specialized botnet builders will seek to construct a botnet through a single vector (e.g. drive-by downloads from a cluster of Web sites they maintain), the majority of professional botnet building criminals launch and run multiple campaigns. These campaigns tend to use different delivery vehicles (e.g. drive-by downloads, spam, malicious binary seeding) and often leverage different campaign “themes” (e.g. pharmaceutical, keygens, free videos).

The purpose of launching multiple campaigns – most of which are launched and executed in parallel to one another – is to effectively “carpet bomb” a series of targeted organizations. The multiple vectors for exploitation and themes are there to increase the probability that some of the botnet malware agents will make it inside the targeted organizations – and it doesn’t matter which delivery vehicle or was successful. Well, actually, the delivery vehicles and campaigns do matter – but only in the sense of tuning future campaigns against other targets.

While the onslaught of multiple campaigns can be confusing to the victim organization, it can be just as confusing to the security vendors as they sift through threat intelligence  harvested from malware samples, spam traps, sinkholes, domain registrations, Web scan results, etc. As such, many of the successes in understanding the campaigns associated with a particular botnet operator occur after the campaigns have been underway for a few days.

Example of botnet building campaigns…

The diagram above depicts the complexity in understanding the various campaigns run by a team of professional botnet builders.

(A) The criminals have created a cache of new botnet agents. Each agent is unique and has be quality assured to guarantee that common host-based security defenses (e.g. anti-virus, IPS, behavioral engines, etc.) cannot currently detect them.

From their secure location, the criminals VPN in to a couple of hosting facilities (B) and (C). These hosting facilities have been chosen because they offer services that make it difficult for law enforcement to prosecute or takedown the servers that (A) are using. More than likely, the servers are hosted in multiple locations around the world.

Hosting facility (B) has its own local cache of botnet agents ready for deployment, and is currently running three campaigns in parallel. Two campaigns are spear phishing related, with the third executing a targeted Search Engine Optimization (SEO) campaign. Meanwhile, over at the (C) facility, two additional campaigns are underway – a pair of drive-by download sites (supported by social network related phishing messages).

Each of the 5 campaigns (D) are seeking to deliver the botnet agents and subsequently breach the targets network and host-based defenses. Once successful, the various botnet agents will connect to their command and control (CnC) servers and consequently become part of the criminals botnet. The CnC servers aren’t depicted in the diagram above. In most cases the CnC’s are situated within hosting infrastructures independent of (B) and (C) - for added resilience and flexibility.

Interestingly enough, while the targeted organization may have observed components of the 5 campaigns, it is unlikely that they would have initially been associated with a single criminal attack.The malware being used would have provided no hints to the nature of the real attack – in fact there’s a high probability that the various malware components would not have been attributed to the same (single) campaign, given how different they are from each other (read our paper on the topic of Serial Variant production).

Trying to track back a particular campaign (in isolation) would have just identified the particular hosting facility. Tracking back the CnC’s used by the botnet agents fortunately provides the glue to understanding the linkages between the various campaigns and makes it easier to understand the objectives of the criminals – which subsequently allows organizations to prioritize and order its remediation steps.

– Gunter Ollmann, VP Research

Changes in Attack Strategy

Wednesday, April 14th, 2010

Last week I was lucky enough to have the opportunity to present at the 5th International Conference on Information Warfare (ICIW) at the Air Force Institute of Technology, Wright-Patterson Air Force Base, Ohio.

As conferences go, it was fairly small but had a great mix of academic and operational security topics. I presented on the topic “Asymmetric Warfare: Challenges and Strategies for Countering Botnets” to a packed room (with much of the folks attending in military uniform). I’ll make the presentation material available shortly on the Damballa Research web site.

While I covered many different aspects of the threat, one particular aspect of the threat resulted in many follow-on questions that evening after my presentation – in particular, the concept encapsulated in the following slide:

The threat landscape has been changing at an accelerating pace. Access to botnet technologies (i.e. the ability to entice and corral thousands of victim computers under a single command and control infrastructure) has had a growing effect on attack tactics – in particular the “targeted” attack vector.

As the presentation slide tries to illustrate, in the old days a criminal would subtly reconnaissance a neighborhood -  looking for houses with the poorest lighting, the lowest fences, the most obscured backyard, mail stacking in the mailbox, etc. – before shortlisting the target homes. Next the criminal would pick an appropriate date and time of night to inspect the target house – checking for open windows, unlocked doors, keys under mats, unset alarm systems, etc. – looking for exploitable vulnerabilities, before finally breaking in to the home. In essence, the criminal was singling out the “lowest hanging fruit”.

Whether it’s a burglar trying to break in to a home, or a hacker trying to break in to the database of a global business, the same principles apply around reconnaissance and soft targets.

However, the “new way” is different. Consider the same neighborhood as above. This time the “criminal” is actually a mob of criminals (say, 2 or 3 per household in the neighborhood) and, instead of doing a reconnaissance phase, they simply choose a date and time convenient to themselves and attack all the houses at precisely the same time. Not only that, but they have an optimized list of tools and tactics for speed and efficiency. For example, instead of seeking out the one window that may have been left unlocked, they simply walk up to the front door with a couple of sledgehammers and smash the door down – making entry faster, and making it easier to remove the stolen goods.

In this case, there’s no prior warning of an attack – it’s more akin to a Blitzkrieg. Organizational efficiencies and a certain level of fearlessness means that they can conduct their crime rapidly and with high-levels of success. Precisely the things that botnets provide for organized cyber criminals.

Now, don’t get me wrong. This isn’t suddenly the default tactic for cyber-crime, but it is proving to be a very successful strategy for criminals that arm themselves with botnets to target an organization.

– Gunter Ollmann, VP Research

Update Your Bot Agent Using Fake Adobe Updater

Monday, March 29th, 2010

In February of 2010, when the Aurora Botnet specifically the Trojan Hydraq campaign was still the talk of the digital security world, little attention was put on other campaigns being conducted by the operators behind the Aurora Botnet. One such campaign is the Fake Adobe Updater. It used the noise created by the Trojan Hydraq campaign of the Aurora Botnet to operate silently. Everyone was in the mode of the need to update IE or not use it altogether so they won’t be victims of the exploit being employed by Aurora. And the advice given to corporate users was also to update all the software they have to ensure that they are protected from the vulnerabilities plaguing outdated versions. And one of the most popular software right now that is always being advised to be updated is Adobe so what a better way to infect unsuspecting users by disguising as an Adobe Updater.

The Fake Adobe Updater is usually delivered via a fake Adobe Update website, which is a tried and true vector for successful infection. A typical update website looks like the real thing, except for the web address. So as not to be fooled, Adobe advises that legitimate updates will only come from adobe.com. For the full write up of this advisory, visit Verifying Adobe Installers.

The infection usually starts by visiting a rogue website and getting a pop-up similar to the one below.

Figure 1. Typical Pop-up for Fake Adobe Updates

Clicking Continue will redirect you to a Fake Adobe Website, which looks exactly like the real thing. Once the user is led to believe that he is indeed downloading and executing a legitimate update, all UAC warnings displayed by the OS will be bypassed as the user will just continue to give explicit permission to the malicious file. Since the dropper now has access to the PC, it can easily overwrite the legitimate Adobe Updater found in the system.

This dropper is different from other dropper since it is not a self deleting dropper. It stays in the infected system, disguising itself as a legitimate Adobe Update Manager, to continuously phone home for new versions of bot agents.

Figure 2. Fake AdobeUpdater malware dropper

The Fake Adobe Updater is notable in a sense that it utilizes Amazon EC2 to serve and control its bot agents. Amazon EC2 stands for Amazon Elastic Compute Cloud. This is Amazon’s web service that provides resizable compute capacity in the cloud.

Figure 2. Attempting to connect to Amazon EC2. This compromised service is already down.

To add resiliency, it also uses another malware serving domain. It does not rely solely on Amazon EC2 given that Amazon is responsive and can easily take the service down as what it has done so in the past.

Figure 3. Other malware serving domains the Fake Adobe Updater is connecting to.

Once the Fake Adobe Updater is sitting pretty in the system and replaced the real Adobe Updater, it downloads another component known as adobe-update.exe. This is the fake Adobe Flash Player Plugin installer that the pop-up was touting to the user.

Figure 4. Fake Adobe Flash Player Plugin Installer.

Other files were also attempted to be downloaded and installed in the system but they are not present in the malware server domains anymore. But judging from the names only, they are known keyloggers and backdoors.

This sample was obtained in February of 2010 and as of this writing, the Fake Adobe Flash Player Plugin Installer, after being around for almost 2 months, is only detected by 4 out of 42 AV host solutions according to VirusTotal.

Figure 5. VirusTotal Result. Source: www.virustotal.com

Waging War Against the Botnet Operators

While the well known Trojan Hydraq is being operated on and scrutinized by everyone in the security industry, the Fake Adobe Updater campaign was slowly working its way into new systems. This shows us that botnet operators can wage malicious campaign after malicious campaign without much difficulty. And for every campaign the good guys take out, it does not even dent their capability to wage a new one. The botmaster’s mindset: Give the good guys a campaign to defeat so they will be happy but while they are celebrating, let’s move on to the next. After all, the botmasters already got what they came for. They have already extracted whatever information they can monetize.

We at Damballa believe that this is not the right way to take down a botnet. We use our extensive data sensors and intelligence to correlate each campaign that would enable us to track and identify the operators behind them. We are not concentrating on winning small battles or campaigns but on employing strategies that will win the war.

-          Christopher C. Elisan, Senior Research Analyst

Yet another Facebook Spam – From Russia with Love

Friday, March 26th, 2010

A new spam pretending to be coming from Facebook is going around the Internet.

The non-password protected ZIP file is a dropper that installs a bot agent that connects to a C&C in Russia.

Take note that no two spammed malware droppers are alike. They are serialized variants. For more on this topic, read our whitepaper on Serial Variant Evasion Tactics.

Why Social Networks?

The rise in popularity of social networks has prompted the bad guys to use this as an effective social engineering tool to fool regular users in installing their bot agents.  The more popular a social network is, the higher the number of user population, thus, improving target coverage for the bad guys. The number of users of some social networks actually exceeds population of certain countries.

Source: http://royal.pingdom.com/2009/03/13/battle-of-the-sizes-social-network-users-vs-country-populations/

- Christopher C. Elisan, Senior Research Analyst

Top-10 TLDs Abused by Botnets for CnC

Thursday, February 18th, 2010

Wrapping up this week of 2009 Top-10 botnet analysis, I’d like to share with you information related to the command and control (CnC) channels used and abused by criminal botnet operators. While I’m sure you’ve seen plenty of news throughout the year related to the abuse of .cn (China) domain registrations for all kinds of malicious attacks (in particular Phishing and drive-by-download site hosting), I thought it would be valuable to look at all the Top Level Domains (TLDs) used for botnet CnC.

Damballa looked at all of the CnC domains used and abused by several thousands botnets targeting enterprise networks in 2009.

As you can see from the table above, the generic commercial TLD “.com” accounts for 19 out of 20 botnet CnC command channels. While “.cn” domains are commonly employed for all kinds of fraud attacks, they account for less than 1 out of 1,000 botnet CnC domain registrations.

Topping out the Top-10 are the four most popular generic TLDs (.com, .org, .info and .biz). The remaining 6 TLD’s (.cn, .tw, .cc, .ws, .ru and .tt) are commonly associated with cheap and easily abused country registrars that conduct little validation and verification of the people purchasing domains from them. It will be interesting to see whether “.cn” domains remain in the Top-10 for 2010 since the China domain registration authority is supposedly hardening it’s registration process and clamping down on abuse.

Readers should note though that the country-level TLDs do not necessarily represent where the CnC servers for the botnet are actually hosted. Anyone, in any country, can register a new domain with these country registrars – which is one of the reasons why they are so popular to criminals and are frequently abused for fraud and botnet CnC purposes.

What is perhaps surprising is the high level of “.com” use for botnets. There are many influences as to why this is the case – factors such as the following:

  • Practically every domain registrar on the planet provides a convenient portal for purchasing and registering “.com” domains.
  • “.com” domains are the most popular domains used by legitimate companies, so their is an air of additional credibility to suspicious domains which may attract less attention by causal inspection.
  • Free dynamic DNS providers (DYN DNS) are popularly employed for CnC domains. Most of these DNS providers use “.com” TLD’s – so they have a heavy influence on “.com” usage for botnet CnC.
  • “.com” domains have no country associations – therefore they help to anonymize the location of the CnC and likely draw less attention than say a “.ru” or “.cn” domain names if for example law enforcement were reviewing logs of an attack against the US government.

Watch out for CnC’s hiding in plain sight!

– Gunter Ollmann, VP Research

Top-10 Botnet Malware Families of 2009

Wednesday, February 17th, 2010

Botnets aren’t malware and not all malware is useful to botnet operators. So what malware families proved to be most popular for those criminal botnet operators targeting enterprise business networks in 2009? Following on from this weeks earlier post covering the Top-10 Botnet Outbreaks in 2009, today I’d like to share with you Damballa’s analysis of the thousands of individual botnets we identified and tracked last year, along with the tens-of-millions of victim computer systems that were usurped in to joining these botnets.

Note that the analysis here relates to the malware components that were successful in joining and participating in botnet command and control activities from within enterprise networks – and does not include “malware infections” that were caught/intercepted/removed beforehand.

Based upon our observations of botnet activity with enterprise networks (which are obviously different from the Internet at large), we found that the most frequently encountered malware used by botnet operators in 2009 was Koobface. Much of the success of this particular malware family had to do with its delivery technique, rather than any particular sophistication of the malware itself. The three major variants of the Koobface family (B, C, and D) dominated the Top-10 largest botnet infections of 2009 (as discussed in the previous blog).

Running a close second behind Koobface, was the Zeus malware family. The popularity of this particular malware DIY construction kit cannot be under estimated. While the largest individually operated botnet found within enterprise networks during 2009 utilized the Zeus malware, many other smaller botnet operators also relied extensively on the same malware family. As such Zeus-based botnets were the most frequently encountered botnets found to be successfully operating within enterprise networks (i.e. most enterprises have several distinct botnets operating within their networks – and Zeus-based botnets were found to be operating in almost all enterprise networks studied by Damballa).

It is interesting to note that the Top-10 botnet malware families uncovered within enterprise networks in 2009 all had fairly standard antivirus names. Unlike the majority of botnets that use custom/unique malware families that typically have no antivirus name, the most frequently encountered malware families had fairly good antivirus coverage. This perhaps speaks to the fact that many of the largest botnets are focused upon fast propagation and infection – therefore their samples of their malware are easily obtained and are available for antivirus vendors to develop signatures. Unfortunately, many of these large (and efficient) botnet operators are increasingly focused upon monetizing their botnet acquisitions by carving them up for sale or sub-leasing their operation. When this occurs, they simply push down the preferred malware components of the new owner/operator of that botnet segment – and subsequent antivirus coverage is poor or (more commonly) non-existant.

It is for this very reason that the Top-10 botnet families of 2009 doesn’t (and can’t) include all those “unnamed” malware used by the more specialist and focused botnet operators. For example, the malware family now associated with the “Aurora” APT and referred to as Trojan.Hydraq didn’t have an antivirus name until a forensically acquired sample was obtained and the antivirus vendors had a chance to disect it and develop a signature for it. In the months leading up to the public disclosure, the botnet operators and the malware family they spawned simply didn’t have a name – and would have never had an opportunity for consideration in a Top-10 malware families report. Just something to think about.

– Gunter Ollmann, VP Research

Top-10 Botnet Outbreaks in 2009

Tuesday, February 16th, 2010

2009 saw many many new botnet outbreaks and advancements in their criminal management. Throughout the year Damballa  tracked thousands of distinct criminal operated botnets and identified millions of newly compromised enterprise systems each day. This week I’m going to share some of our findings from the year now that we’ve finished analyzing terabytes of unique Command and Control (CnC) data. First on the list: the Top-10 largest botnet outbreaks of 2009.

In 2009 the top-4 botnets accounted for half of all botnet infections within enterprise networks. The largest botnet accumulated 19% of all new botnet victims within corporate enterprise networks and was based upon the popular Zeus family of crimeware. At its peak, the criminal entity managing this particular botnet had interactive control of over 600,000 victims at any single point in time – and had managed to breach the security of several millions of additional hosts. It is important to note that Damballa has tracked hundreds of similar botnet operators who also prefer to use the Zeus malware as their bot agent of choice – however, only one such operator made it to the Top-10 largest botnet outbreaks of 2009.

Koobface appears three times in the Top-10 – with Koobface.B accumulating 15% of the new botnet compromises within Enterprise networks in 2009, Koobface.D came in with 5% and Koobface.C accounting for 4%. Koobface managed to successfully leverage social networking platforms and hijack their victim’s accounts to worm their way between systems, and breach millions of unsuspecting hosts.

Coming in an number three, “ClickFraudBotnet” is a single botnet operated by a criminal team that focused on sophisticated click-fraud attacks – and conducted their activities within enterprise networks. The team used many hundreds of different types of malware, from many different malware families. Unlike many other large botnet infections, they did not stick to a single family of malware – e.g. Zeus, Koobface, Conficker, etc. As such, many of the malware they used do not (and continue not to) have any antivirus names, nor are they detected by current antivirus products. Damballa tracked dozens of similarly focused click-fraud botnets in 2009.

The “SpamfraudBotnet” was one of several botnets that focused on sending spam emails from within breached enterprise networks. This class of botnet is operated by seasoned cyber criminals that provide spam services to third-parties as a paid-for offering.

The Monkif family of malware grew to fame in the later stages of 2009. Damballa observed that the Monkif.A variant managed to compromise several hundred thousand enterprise systems – accounting for 8% of all botnet infections during the year. Meanwhile the later variant, Monkif.B, was less successful operating within enterprise networks and only managed to account for 4% of system breaches.

Damballa also observed a handful of different botnet operators using and recycling the Tidserv family of malware. The largest of these Tidserv botnet operators managed to reach 7th position with 5% of system breaches in 2009.

Finally, coming in at 10th place is Conficker.A. While there was much media coverage of Conficker at the beginning of 2009, and the Conficker.C variant garnered most of the limelight, in practical terms Conficker.A was the most successful variant of 2009.

Tomorrow I’ll be covering the Top-10 most successful malware families used by botnet operators in 2009.

– Gunter Ollmann, VP Research

More Than Changing Frequencies

Monday, February 8th, 2010

Nothing ever stands still on the Internet. Like life on the African Savannah, the old and the sick are easy prey to those who are faster and more agile. Old and vulnerable software, along with aging infrastructure, quickly fall prey to swift and orchestrated attacks from around the world.

Which brings me to the discussion over three of the most important changes on the Internet for quite some time – all of which appear to be reaching their crescendo at the same time. While I’m silently hoping that most people are familiar with the three, I suspect that very few people are as up to speed as they need to be. Which three? IPv6, Internationalized Domain Names (IDNs) and DNSSEC.

Incremental testing and roll-outs of these three technologies has been ongoing for way too long – but it seems that they’re all hitting the Internet (and consequently the Enterprise) at round about the same time. DNSSEC, the late starter, would appear to be in pole position to reach widespread deployment first. Meanwhile IPv6, a technology that has been on the drawing board for over a decade, is finally finding its feet as prophets predict the end of the Internet as old-style IPv4 addresses run out.

From a security perspective, DNSSEC is most strongly affiliated with “making the Internet better” – that is to say, it was designed to overcome many of the security weaknesses and failures of past DNS specifications, implementations and deployments – in particular, certain types of attacks directed at cache poisoning. For enterprise environments, DNSSEC strengthens the overall security of DNS servers and will make them more resilient to many of the attacks that have plagued the Internet for the last couple of decades. There is even talk about how this technology, once deployed widely and mandated for Internet use, will help reduce persistent threats such as spam and phishing. That said, it’s one of the technologies I’d class as important from a security perspective, but isn’t really going to affect the criminals adversely. Great defensive advances from a hacker/cyber-war perspective, much less so from a criminals perspective.

The two other technologies – IPv6 and IDNs – on the other hand are much more interesting from a security and criminal perspective, as they potentially open the doors to many new forms of abuse and attack vectors. I use the term “potentially”, but in reality I mean that they will obviously enable new forms of attacks and enhance many of the existing attacks that have plagued the Internet throughout the last decade.

I’m not going to go in to the technical details of these technologies – if you’re interested in finding out more about them, go HERE for the IPv6 information and HERE for the IDNs information. What I will point out though is that these two technologies have a far reaching impact upon both the vectors through which the bad guys can attack an enterprise through, and upon the security technologies used to detect and analyze subsequent attacks.

IDNs and IPv6 shouldn’t be thought of as an upgrade to existing Internet standards or networks – i.e. migrating from Internet 1.0 to 2.0 – but could conceivably be thought of as a parallel universe where things are kind of familiar, but different at the same time.

How could I describe the changes between IPv4 & IPv6 and the traditional domain system & IDNs? By way of analogy, think about good, old fashioned, radio. The traditional domain name and registration processes (with all the 2LD and 3LD definitions), along with the traditional IPv4 networks can be thought of as operating over AM Radio. Meanwhile IDNs and IPv6 can be thought of as FM Radio. That is to say, moving from one to the other isn’t the same as just turning the dial left or right in search of a new station or frequency. Rather, we’re talking about a kind of change that requires a different kind of receiver – and without the right receiver (AM or FM) you’re not going to be able to pick up the new channels.

The analogy only goes so far though. But just like the electromagnetic waves of radio transmissions are undetectable without the correct receiver and the right tuning, the same concepts apply to IPv6 and IDNs advancements. Without ensuring that your security technologies can actually handle these changes to the Internet or enterprise network, there’s no way you’re going to be able to detect them being abused for malicious and criminal purposes.

A likely question from readers is going to be “Are the bad guys abusing these technologies already?” From casual observation and perhaps being tainted by too many years having to think and act out as one of the bad guys, the answer has got to be “Yes”. But, on the plus side, not to a noticeable or damaging level yet. The bad guys are still in an experimental and prototyping phase – examining the potential vectors for abuse – and largely waiting for the time when it becomes worthwhile launching meaningful attacks that abuse IPv6 and IDN rollouts. I have no doubt that many of the criminal service providers are priming themselves for the new revenue models and competitive edge.

The question I’d leave for readers in return though is “do you think your security systems are capable of detecting and reporting abuse of IPv6 and IDNs?”

Think about it. Which systems and processes do you have in place capable of detecting a brand new phishing site hosted as www.eBay.com where the “B” is the Cyrillic letter Ve and just happens to look exactly like the ANSI “B” character? and what if the SSL/TLS certificate matches, etc. Would you notice that a botnet agent is propagating and establishing peer-to-peer relationships between infected hosts within your own organization over IPv6? Would you be able to scan for, and uncover, a botnet Command and Control service running on a compromised host with an IP address of 2001:db8:85a3::8a2e:370:7334?

While DNSSEC works to close down several vulnerabilities, IPv6 and IDNs open the doors for additional forms of attack and attack vectors. Now would be a great time to double-check that your existing systems are capable of handling these changes – particularly new internationalized domain names such as www.günterollmann.com.

– Gunter Ollmann, VP Research

Detecting Botnets with Network ADS

Saturday, January 30th, 2010

Many businesses have already deployed Anomaly Detection Systems (ADS) within their enterprises whether they know it or not. Most ADS technologies can be discovered operating at the host-level – typically integrated in to the popular desktop antivirus suites of the major security vendors – where they can be often be found functioning in a hybrid detection mode somewhere between a personal firewall and a behavioral analysis engine.

Network-based ADS (NADS) on the other hand serve a different purpose within large enterprises. Their deployments are far fewer than host-based ADS, and are often used by security teams to detect major changes in network activity – typically analyzing and regulating traffic flow. Optimized to view high volumes of network traffic across an enterprise as fast as possible (in real-time in many cases), they rely upon specially crafted abstract protocols of the traffic – such as NetFlow, JFLow, NetStream, etc. – where content visibility is sacrificed for analysis speed.

Over the last 2 years NADS technologies have increasingly been positioned as having an anti-botnet capability – which has caused much confusion amongst those responsible for managing ADS deployments and those responsible for enterprise-wide security. NADS do in fact have some value as an enterprise-level botnet detection tool, but their capabilities are all too often misrepresented.

How capable are NADS in detecting and mitigating botnets? What are their strengths and weaknesses? The following is a summary of my observations and experiences (garnered over the last 5+ years) in using NADS as an enterprise security technology – warts and all.

Botnet detection & mitigation strengths:

  1. A correctly configured and baselined NADS deployment is capable of detecting the high-volume attack output from certain classes of botnets. By identifying voluminous email sending (e.g. spam agent or spam proxy operation) or crafted port-specific traffic (e.g. DDoS agent operation) and tracking that back to specific hosts, the infected systems operating in this manner can often be classed as being a member of a botnet.
  2. Many general-purpose Internet botnet malware make use of worming capabilities to propagate around enterprise networks by exploiting unpatched software flaws in vulnerable hosts. If a NADS solution has been correctly baselined, it can be relatively easy to spot the anomalous traffic this propagating threat creates – thereby alerting security teams to a new malware outbreak.
  3. By configuring the NADS system to account for “normal working hours”, different detection thresholds can be utilized to aid in the detection of hosts that are actively communicating with botnet Command and Control (CnC) nodes. For example, if a host suddenly commences HTTP or IRC communication with an IP address located in Tibet at 3:00am in the morning – this will likely be very suspicious.
  4. If an organization has suffered a sudden and large botnet infection, the constant polling of some botnet malware variants will quickly become apparent and will aid in the identification of those bot infected hosts.
  5. If the NADS system supports the use of blacklists, a list of known botnet CnC’s can be used as a means of tracking the volume of data that has been sent or received by enterprise hosts that are part of the botnet. Study of this logging can help reveal the scope of a breach and the types of information the criminal botnet operator is targeting.

Botnet detection & mitigation weaknesses:

  1. Very few botnets encountered within enterprises nowadays are noisy and spew copious volumes of spam or participate in devastating DDoS attacks. Botnet masters have largely moved on from this activity – and will only order bot infected hosts to operate this way if they’ve already exhausted all other value from the compromised hosts, or if they never bothered to figure out the infected hosts were actually located within an enterprise (in which case, if they had, they would have probably sold them to someone else for a good price). Therefore, basing detection of a botnet infection on copious volumes of attack traffic is either too late in the botnet lifecycle or was just bothersome (and not a security risk) to begin with.
  2. By basing botnet detection upon the identification of outbound malicious traffic, the enterprise security team have failed to preempt the malicious operation of the botnet and are forced to deal with the voluminous output of an ongoing attack. Detection and mitigation of the botnet control instructions that instructed the attack to begin would have been more efficient and less damaging.
  3. Baselining an enterprise NADS deployment – and keeping that baseline current – is almost impossible in the vast majority of businesses. New application deployments and software updates, along with roaming users and peer-to-peer communications, mean that enterprise network traffic is not as consistent and predictable as it was even only half-a-decade ago. As such, it becomes increasingly difficult to spot the worming traffic generated by botnets attempting to propagate around the network. This has become further complicated by the fact that the malware authors themselves have learned much from past attacks and have intentionally become more stealthy and deliberately slowed their propagation pace to avoid anomaly detection systems.
  4. Botnet malware is more often than not designed to function only when the infected host is actually in operational use by its authorized user. As such, it is increasingly difficult to identify anomalous traffic from real traffic as the user goes about their regular Internet surfing.
  5. Most botnet malware found within enterprise networks are proxy aware. This means that they borrow the users credentials and funnel all their CnC traffic through the corporate proxy servers – i.e. they do not use non-standard ports or protocols to navigate out to the Internet or between internal systems. The vast majority of botnet malware rely upon HTTP or HTTPS for communication.
  6. Timing is everything for botnet operators nowadays. No sooner has a host been compromised through a drive-by-download vector or Trojan file download, that it connects back to its CnC ready to receive both a updated malware package and a new set of instructions. As such, unless the NADS solution is configured to react in real-time to the identification of a new botnet infection, the threat will have either moved on or already become more severe.
  7. Many of the more commercially-minded botnet operators invest in fast-fluxing and domain-fluxing CnC technologies. The unrelenting changes in CnC IP addresses and hosts names can quickly overwhelm NADS systems.

So, in summary, I’d say that NADS does have a role to play in botnet detection – but only a very minor one, and even that’s diminishing all the time. NADS deployments make for capable enterprise-wide network health monitoring systems, but have faltered against advanced threats like botnets and even more stealthy threats such as Advanced Persistent Threats (APT’s). I’d liken NADS to a school nurse – constantly overseeing the health of the entire student population and dealing with the odd knee scrape and cut lip – but not trained or equipped to deal with major head trauma or the results of a shooting spree.

– Gunter Ollmann, VP Research