The Day Before Zero

As part of our investigation on The Command Structure of the Aurora Botnet. I took a deep look into two malware families that based on the CnC data we have, is related to Operation Aurora. Both of them fall under the Fake AV / Scareware Family of Malwares. They are Fake AV / Login Software 2009 and Fake Microsoft Antispyware Services.

I will summarize the deployment of these families below. For the full details of the analysis and how they relate to Operation Aurora, please read our full report on The Command Structure of the Aurora Botnet: History Patterns, and Findings.

Fake AV: Login Software 2009 Family

This set of malware is propagated through Fake Malware Alerts. The supposed AV installer is the actual malware dropper. Its main purpose is to drop and install the rest of the malware components. Upon execution of the dropper, it assigns a specific ID to the compromised host. It then registers it to its malware server website and downloads the rest of the malware to the compromised host.

To ensure that the malware is downloaded, the creator of this malware dropper uses redundancy in its malware serving web infrastructure. The dropper checks three different malware serving websites.

After the successful download of the main component, the main dropper generates a random name and copies the downloaded component to “C:\Documents and Settings\<User>\Local Settings” folder. It calls itself Login Software 2009. The dropped file is then executed to make it active in memory. For it to survive reboot, it uses the most common way to autostart by using the registry entry:

HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

The rest of the components are also downloaded and executed for them to be active. They are placed in the same folder as the first dropped file.  These components are exact copies of themselves with names that is designed to full the unsuspecting users that they are Windows executables or legitimate third party software.

These components are hidden from the user by hiding the folder where they are dropped and also setting the attributes of the dropped files themselves as hidden. To survive reboot, these components also are set to autostart using the same technique as the main dropped file.

A DLL file is also dropped in “C:\Windows\System32” with a random filename.  Aside from registering  (regsvr32.exe) the dropped DLL file for it to be active, the malware dropper also modifies the registry to set it up as a Browser Helper Object (BHO). It also sets up the DLL to autostart every boot up by using SharedTaskScheduler.

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\SharedTaskScheduler

This paves the way for tracking cookies to be downloaded for ads to be served to the compromised host. Take note that this DLL is not hidden unlike the other components.

After setting up all the dropped files, the main dropper sets the stage to protect the dropped files by manipulating the settings of Windows Explorer and Internet Explorer. See Protection Mechanism section for more details.

Once all of these “malware installation” is done by the main dropper, the main dropper activates a batch file to unload itself in memory and deletes both the dropper and the batch file.

The installed malware set are now all active and is actively attempting to communicate with their CnC.

Figure 1: Memory string dump shows the C&C the EXE component is reaching out to

Fake Microsoft Antispyware Services

This set of malware is also propagated through Fake Malware Alerts. The supposed AV installer is the actual malware dropper. Its main purpose is to drop and install the rest of the malware components. It basically drops and installs three components:

• EXE Component – This is the one that poses itself as Microsoft Antispyware Services
• VXD Component – It downloads and installs ntconf32.vxd, ntsys32.vxd, msimsg32.vxd
• SYS Component – It downloads and installs msconfig32.sys

Once the dropper is executed, it can easily bypass UAC since it is given explicit permission by the user that was made to believe that the installation is an AV product. The first thing the dropper does is to connect to its malware server domain to download its components. Unfortunately, as of this writing, the malware server domains are already down so no detail analysis of the other components were done.

The only component on hand is the EXE component.

But if we base it just on the name of the files it downloads, below are some associations of the files with known malware activity:

• VXD Components – These filenames are often related to malware families that have keylogging and spyware behavior. They are also found in some IRC bots.
• SYS Component – This is related to the publicly known and notoriously popular Aurora variant tied to the Google attack.

Concentrating the analysis on the EXE component, it disguises itself as Microsoft Antispyware Services. It basically sets itself to run on Startup using the tried and true method of the registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run

Because of the absence of some key files, the main functionalities of this malware family cannot be fully analyzed but they all point to one goal and that is to steal information.

Figure 2. Attempting to connect to Amazon EC2

Figure 3: Memory string dump shows the C&C the EXE component is reaching out to

The Allure of Fake AV Websites.

The bad guys find using Fake AV websites effective and have used it extensively. The prevalence of this vector earned it a separate name: Scareware. What makes this effective is the believability of the Fake AV website. It also appeals to the fear of uneducated users. The bad guys leverage this fear to create a sense of urgency and importance that urges the user to not waste any more time and download and execute the dropper immediately. Aside from unknowingly downloading a malware, the victimized user also is fooled into paying for the Fake AV. Not only will the user be charged for the cost of the Fake AV, there’s a high probability that the user’s credit card information has been captured since the website processing the payment is rogue to begin with.

On the technical side, using this vector saves the bad guys time in finding ways to bypass host protection such as UAC since the user gives the malware dropper explicit permission to execute.

-  Christopher Elisan, Senior Research Analyst

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

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

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

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

By now, if you’ve been keeping up with only a small fraction of the news stories related to the Google APT attack or project ‘Aurora’, you’ll have learnt that the Advanced Persistent Threat (APT) is a clear and present danger to your organization. Big or small, your business may be the ultimate target, or just the lowest-hanging fruit as the criminal operators route their attack through your organization to reach their real goal.

As such, I’ve been approached by quite a few Fortune-500 companies (and strategic vendors to the Fortune-500 companies) over the last few weeks as their technical teams scramble to baton down the hatches and scrutinize their networks to see whether they too have been an APT victim. In general, executive management within these organizations have failed to understand the nature of the threat and are having a very difficult time understanding why precisely their existing network security investments aren’t (or won’t) protect against the threat. As the first defense against malware, I’m sure all the antivirus vendors are feeling the heat and are under pressure to prove that this kind of attack can be thwarted by their solutions. Unfortunately, they will never be able to guarantee that level of protection – much less prove it.

So how can you tell whether you’ve fallen victim to an APT (or an enterprise targeted botnet)? By now the malware associated with the Google APT are thoroughly covered by the antivirus products (if not, you should ditch that vendor because they’re incompetent) , and every network inspection technology operating at the perimeter capable of supporting a blacklist will be able to detect or block the public list of the 27 or so known host names and possibly some of the non-public ones too. Which, all in all, should be enough to say whether or not you are are a victim of the same APT malware that Google suffered from. However, even armed with all this information and protection updates, what you’re not going to be able to do is say whether you’re the victim of another (or any other) APT attack, or whether the same criminal operators behind the public Google APT attack didn’t use a different piece of malware or simply upgraded you to a newer malware version first.

Which leads me to offer you something that may help confirm that you’re currently a victim of any number of APT attacks, targeted enterprise botnets, or simply a Remote Access Trojan (RAT) installed by a malicious insider – Damballa are offering a free APT Audit.

Damballa will work with your organization to conduct a free network audit designed to uncover APT’s, botnets and other remotely controllable agents. The audit doesn’t require you to install software agents on your hosts, it doesn’t actively scan your network, instead it will passively monitor your existing network traffic (not in-line) and show you live the victims within your organization – as well as catalog the evidence and packet captures you’ll need for understanding precisely what the criminal operators are doing and what information they’re targeting.

You can register for the free APT audit here.

– Gunter Ollmann, VP Research

Browsing the Web for online virus scanners will yield an increasing array of available services. Ranging from vendor-specific portals featuring their latest antivirus engine through to public testing portals offering 40+ different scanning engines, these online scanning services allow visitors to submit suspicious files and help identify their true malicious nature.

The bigger portals – the ones offering dozens of popular antivirus products to test against – are quite useful to corporate security teams. They allow the organization to not only inspect suspicious files without the need of building and maintaining a whole malware testing lab, but also allow the organization to get a better feel for specific product coverage of the threat. I’ve also seen many organizations using the portals as a convenient source of malware naming correlation – i.e. which vendor calls the sample what?.

This handy feature hasn’t gone unnoticed by the malware authors either. They use these online portals as part of their Quality Assurance (QA) process to guarantee that their latest malware creation will go undetected when deployed against their target. They’ve been doing this for nearly a decade now though.

Many of the biggest virus testing portals (such as VirusTotal) work with the major antivirus product vendors by handing over copies of the submitted files to them. Obviously, this process isn’t so cool for the actual malware authors and, as you’d expect, enterprising individuals now offer similar malware testing portals with guarantees that they will never share the files with anyone. Which, obviously, has resulted in the growth of testing portals that cater exclusively to cybercriminals and offer monthly subscription testing services optimized for batch processing of malware.

The malware portal scanning ecosystem is rather interesting, but perhaps the most interesting aspect is how it’s become a critical tool by which vendors keep pace with the latest malware threats. Because the portals have become popular vehicles for checking and verifying coverage, they’ve attracted mainstream attention (and adoption) as a vehicle for tracking the relative performance and effectiveness of the antivirus vendors themselves. It’s not what the portals were originally intended for, but nevertheless that’s what they’ve become.

Now, because of this “competition” in coverage, samples submitted to popular portals like VirusTotal seem to have a higher probability that vendors will ensure some level of detection coverage – especially if at least one other vendor detected the sample or flagged it as suspicious. This was discussed a little in yesterdays blog on Kaspersky’s blog – On the way to better testing – in which they describe how the system can be rigged and abused (i.e. creating fake malware detections and watching who is copying who).

Anyhow, there’s another aspect of this ecosystem that’s both worrying and fun to explore at the same time. Given the mix of different detection engines and strategies all the antivirus products within these portals use, many files get marked as suspicious or incorrectly flagged as malicious. This applies especially to files that have been compressed, packed or armored to speed up Internet transfers or prevent the loss of intellectual property through reverse engineering. As such, the whole “signature copying” system is ripe for abuse.

To give you an example (names of the perpetrators/victims intentionally left out), I remember someone a year back intentionally grabbing the DLL’s of the most current version of a popular antivirus product and submitting them to one of these portals. Low and behold, by a few days later there was news about XXX vendor’s product killing/quarantining YYY vendors product.

Which I guess brings me to this blog’s title – Killing Antivirus, One DLL At A Time. Anyone can abuse these feedback-loop systems – and some people already do (for fun). If anyone wanted to cause a degree of havoc to the antivirus vendors that rely upon these testing portals as a crutch for their detection, here are some of the things that would likely have them tripping over their tails…

• Every time antivirus vendor XXX updates their engine, the antagonist submits the newest DLL’s and EXE’s for vendor XXX’s product to a testing portal. They’d likely see all kinds of false positives immediately (especially for DLL’s), but after a few days they’d also discover increased “coverage” amongst other vendors – and maybe a news story that vendor YYY accidentally killed vendor XXX’s product.
• Each time Microsoft or a major software vendor releases an new update of their product, they could submit the latest files and observe which vendors false-positive on them. They’re probably not a vendor you’d want to consider deploying in a large enterprise though.
• Packing antivirus vendor XXX’s key DLL’s and EXE’s with popular “known bad” packers that also have well covered unpacking solutions will likely increase the immediate number of false positives – which may in turn result in a quicker turn around of vendor YYY’s signatures for detecting the new “threat”.
• Binding vendor’s brand new (and critical operation) DLL’s and EXE files with known malware samples, or adding them to popular droppers will likely increase the “guilt by association” detection systems – and similarly result in more false positives.

I could probably think of many more ways that evil-doers could mess this signature generating ecosystem up, and even then I’d probably miss several that the bad guys are already doing or in the process of testing out.

Some may argue that by having pointed out the frailties of this ecosystem I’m in turn exposing the antivirus industry and their customers to more risk. But lets face facts, this stuff already happens. This is not rocket science. I can just as easily see some computer science under-grad over the road at GATech conducting his own tests and publishing a great paper on the topic. Perhaps he already is?

Regardless, there are lessons to be learned here and the ecosystem exposure is real. I’d be curious to see what the effect would be of criminals actively and persistently conducting the “attacks” described above – would that cause pain to enterprises that intentionally run multiple antivirus products together to help weed out false-negatives and improve overall coverage? Or would consistent abuse of these testing and submission portals result in lowering the probability that real malware submitted to them would eventually be covered in signature updates at a later date?

– Gunter Ollmann, VP Research

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

The recent Google Advanced Persistent Threat (APT) dialogue has been hogging the press for a week now, and each day reveals new (and often conflicting) insight. As I mentioned on Thursdays blog – “Preemptive Protection” Isn’t – If You’re Battling APT’s – this particular attack doesn’t represent some new shift in tactics. It’s not the first APT in the world, in fact I’m pretty sure it’s not Google’s first exposure to APT’s, and I’m certain it isn’t going to the last. In fact I’d say its a safe bet to say that there are several other equivalent APT successes currently operating within Google’s networks waiting to be discovered. Such is the state of the threat.

So, while the Google APT hogs the limelight, I found it rather topical to note the story on the CSMonitor.com site – US oil industry hit by cyberattacks: Was China involved? – covering other successful APT campaigns going back a few years victimizing Marathon Oil, ExxonMobil, and ConocoPhillips. If you have the time, the story is worth the read and you’ll get a better understanding of the breadth of attack vectors.

Given these timely public disclosures of successful APT’s and the additional claims of Chinese involvement in the attacks, I thought it would be valuable to share my own experiences and insight in to the threats facing the major oil and petroleum organizations.

Truly big business attracts truly big crime. In fact, as I mentioned to a colleague here in the office today, it’s practically impossible to separate big business from government and separating state-sponsored (or endorsed) actions from corporate espionage can be more a definition of semantics than anything else at that level . For many countries, big business doesn’t get much bigger than that of the major oil companies. As such, the big oil and petroleum organizations are under a perpetual barrage of sophisticated attacks.

As the target of a long-term, well funded and well organized APT attack, the compromise of perimeter defenses is measured in weeks or campaigns, rather than success probability metrics.Think of an APT as a campaign of well researched attacks spread over an extended period of time, coming from a broad spectrum of perceived sources.

Sophisticated malware lies at the heart of a successful APT compromise. It’s the primary tool for navigating the victims network, targeting specific hosts and information, and extracting the critical data. Unfortunately for the good guys having to defend these networks, “sophisticated” doesn’t mean exclusive nor hard to acquire. Getting hold of the malware components necessary to carry out this kind of attack is child’s play – literally! If you’re capable of using a search engine and running a software package you’ve just downloaded, you have all the skills necessary to craft, build and distribute a custom malware agent used in the APT attacks that have made the news recently. In fact you’ve had that very same capability for at least the last 3-4 years.

In my time dealing with oil and petroleum companies in Europe, I found that ATP’s were orchestrated from a variety of country sources – from first-world through to third-world – often with a heavy regional weighting. For example, oil and gas companies installing new pipelines in and around the Mediterranean at the time seemed to attract RATs (Remote Access Trojans) developed from DIY construction kits and delivered by innovative drive-by-download vectors that had a healthy dose of Cyrillic typefaces. Meanwhile some self-propagating worms that had eventually made it to various UK offices (and were intercepted there) appeared to try to use Windows exploits that that were optimized for other regional flavors of the operating system (i.e. memory offsets and keylogging keywords were for different language editions).

While the recent CSMonitor.com posting discusses APT’s focused on the theft of oil exploration and discovery data, the targets of other attacks I’ve seen (or heard about) are just as broad again. In fact, some of the targets may not even be information – they may be to lay the groundwork for a more damaging physical interruption of business. For example, worm-based malware is a particular concern to the oil and petroleum companies. Vast swathes of their network encompass mechanical and industrial control systems – and embedded operating systems are a fundamental feature of modern processing plants (and oil delivery). Unfortunately it’s rather tricky to update 5+ year-old valve controller systems everytime there’s a new security patch (multiple that problem every 50 meters of a 1,500 km oil pipeline for example). Irrespective of all the SCADA problems you may have heard about over the last few years, unpatched embedded operating systems that can be exploited using off-the-shelf hacking kits and remotely controlled using standard botnet management tools will give even the best security consultant prolonged heartburn.

Again though, and I’ve said this several times since Google’s public announcement, APT’s aren’t a particular piece of malware or an attack vector – they are coordinated attacks by motivated and professional criminals. They will succeed in breaching their targets perimeter. They will compromise internal hosts and embedded systems. Their criminal operators are myopically focused on achieving their business objectives.

Detecting when they’ve breached your network defenses, when they’ve circumvented your preemptive protection technologies, and when they’ve compromised your computing systems is critical. And you know what? I know how to detect them. Command and Control (CnC) communications are the APT’s soft underbelly – whether you’re a search engine company, a global petroleum company with revenues that rival the GDP of many small countries, or just a company that holds the keys to secrets that someone else wants and is determined to acquire – identification of their cyber-polling or interactive digital chatter will unearth their presence.

– Gunter Ollmann, VP Research

Control of an enterprise network is a high commodity for botmasters. Aside from the wealth of information that can be stolen, access to corporate hosts can be sold for higher values to other botmasters. This is why enterprises are being targeted more. Let me sum up the advantages of enterprise network infection against home PC infection. I call it the ABC advantage.

1. Availability – Availability of a bot agent to a botmaster is very important. This means that anytime the botmaster wants to do something with a herd, the numbers are always there. Corporate hosts are usually on all the time, making it more available to the botmaster compared to home PCs.
2. Bandwidth – Corporate networks have higher bandwidth, which means faster internet connection. This means better communication between C&C and the bot agents and higher reliability when it comes to executing commands and updating itself with new binaries.
3. Confidentiality – Most of the time, corporate infections are not reported and is just kept within the enterprise. This makes mitigation harder. This is what botmasters like the most. They want to remain invisible, which is why enterprise botnets are less noisy than internet botnets that target home PC’s. If the enterprise is able to discover and mitigate the infection, the details are shared only within a handful of people in the company. This is good for the botmaster since he will just target the next enterprise in his list with the same tactics

- Christopher Elisan – Senior Research Analyst