Posts Tagged ‘botnets’

A Treasury of Dumps

Wednesday, May 5th, 2010

Most of the “popular” Internet botnets are quite adept at identity and credential theft. Granted, this is usually just the first phase of a successful botnet breach and the lowest hanging (digital) fruit, but it remains one of the more profitable data streams for the botnet’s criminal operators.

However there’s a big gap between criminals that know how to build a botnet and automatically steal tens-of-thousands of identities, and those that are capable of really monetizing the stolen credentials. In most cases the folks who can turn a stolen identity (or the keys to an online bank account) in to cold hard cash aren’t the same as the folks tuning the scripts behind the latest e-banking phishing scam or banking Trojan.

So, if you happen to be a semi-skilled botnet operator with control over 50,000 victim computers and along the way have managed to extract some 40,000 user identities and 2,000 online banking credentials, the question quickly becomes “how do I find someone willing to pay me for this data?”

You could go to any number of hacker or carder Web sites and offer your goodies up for sale there. That’s getting a little tougher nowadays though. Many of these “hacker” sites are run by (or cooperate with) law enforcement. Details about who you are, where you’re connecting from, how big a player you are, etc. are all up for grabs and, as such, these forums have increasingly become “less reliable” over the last 3-5 years.

Paste Bins

One increasingly popular vehicle for botnet operators and identity thefts to “advertise” their latest caches of stolen goodies are the paste bins. Paste bin sites were originally conceived as places where developers could conveniently share source code and other notes etc. without having to worry too much about the codes formatting getting corrupted, and to bypass many of the problems associated with trying to share code segments over email, HTML formatting, and long streams of source code.

Apart from the ability to host a lot of textual information for free – making it ripe for spam abuse – paste bins typically allow visitors to make anonymous postings, which is ideal for botnet criminals seeking buyers for their stolen data.

Anyhow, I was discussing this aspect of pate bins with a colleague here at the office earlier today and figured I’d share some information about how paste bins are being used to perpetuate crime, and how their popularity has been increasing.

Paste bins are also very interesting from a threat research perspective. Despite being anonymous, they typically have well indexed pages – which means that they’re very easy to search.

For example, if you’re in the market for some stolen credentials you’ll find thousands of advertising posts such as the following:

As you’d expect, there is plenty of information out there and up for sale and the sellers are easy enough to track down and engage in conversation – offering up email addresses, ICQ/IRC numbers, phone numbers, etc.

In general, credentials and stolen banking details are sold in batches (i.e. in bulk), and most of the advertisers provide a lot of detail about the quality/freshness/scope of their data. For example, the following depicts the level of detail associated with the credit cards that are available (in batches of 1,000 cards).

I’ve pixelated some of the example above (and below) to hide the real victims credentials that have been offered up by the criminal as a sample. In many cases the criminals doing the advertizing have so much data available for sale that they display swathes of samples – typically designed to show the depth of detail and “freshness” of the stolen credentials. For example, the following criminal is selling batches of stolen MasterCard credentials…

(Click to enlarge)

How do you uncover these details? Well, there’s the easy way and then there’s the hard way. The easy way is to visit the various paste bin Web sites and use their local search engine to hunt for key words such as “MasterCard” or “CardType:” etc.

Then there’s the hard way – you can use Google. OK, so it’s not really that hard. The point is that it’s easy to uncover these criminal advertisements. For example, the following reveals 800+ recent ads on the popular Pastebin.com site…

It’s important to point out that these advertisements aren’t exclusive to the various paste bin sites – they’re just another vehicle for the criminals to hook up with other criminals and sell their stolen goodies. For example, doing a search for just one of the stolen (but freely available) MasterCard numbers offered up in the earlier screen shot revealed another 127 different sites hosting the same criminal ad.

You’ll find the paste bins sites being abused in a lot of different ways, but they’re increasingly being used as a convenient source of anonymous criminal advertising and for sharing stolen data (both encrypted and unencrypted).

Meanwhile, simple Google searches such as “facebook.com site:pastebay.com” will yield lists of thousands of stolen Facebook credentials…

I’m hoping that the various paste bin providers will help clean up the situation – but I’m not planning on holding my breath while they do so.

– Gunter Ollmann, VP Research

Tags: , , ,
Posted in Threat Research | No Comments »

Cyber-protesting At Your Leisure

Wednesday, April 21st, 2010

Participating in online cyber protests has always been easy. In some cases it’s as simple as opening a page in your favorite web browser and letting it instantiate a dozen embedded frames containing the target web site (as done successfully many times in the past for “virtual sit-ins” – and most spectacularly as part of the Iranian election protests).

Social networking portals and services are increasingly serving as the hub and aggregation point for protesting movements. Their ability to distribute protesting instructions and coordinate actions at a global level haven’t gone unnoticed. Another set of social networking functions and API’s hasn’t gone unnoticed either – the ability to dynamically coordinate tool-based protest functions (e.g. DDoS and Spam campaigns).

We’re now seeing the development of specialized botnets and, more precisely, the enticement of opt-in botnets. It may sound contrary given the massive awareness of criminal botnets, but specialized and “trusted” botnets can be successfully used for cyber-protesting movements.

Today, Damballa has released a new whitepaper covering this concerning trend – and the implications the the technology on business. The paper, titled “The Opt-in Botnet Generation” is now available on the Damballa web site.

– Gunter Ollmann, VP Research

Tags: , , , , , ,
Posted in Threat Research | No Comments »

Operation Aurora Resized

Wednesday, March 31st, 2010

Last night my attention was drawn to a couple of blog entries relating to Google and the attacks they fell victim to earlier this year. These attacks were eventually labeled as “Operation Aurora” by McAfee (based upon the presence of the “aurora” keyword embedded within some of the malware).

First off, Google blogged about analysis of a new botnet that broadly targets Vietnamese computer users around the world. The intent of the botnet appears similar to the one that apparently involved surveillance of email accounts belonging to Chinese human rights activists – spying upon their victims and attempting to squelch opposition to bauxite mining efforts in Vietnam.

This post apparently prompted a follow up blog from McAfee detailing how their identification and analysis of this particular Vietnamese-speaker targeted botnet harkened back to their “Operation Aurora” analysis in mid-January. McAfee states that their original “Operation Aurora” analysis was incorrect and that this particular botnet (and the malware associated with it) shouldn’t have been bundled as part of their earlier threat report about the attacks that breached  Google and 20+ other organizations last December . McAfee stated that this Vietnamese-targeted botnet did not use sophisticated malware, which may have fueled general confusion as to whether the “Operation Aurora” attack (as a whole) was sophisticated or not.

“Aurora Lite”

As a close knit community, security researchers and investigators share a lot of threat intelligence and information about attacks. Since McAfee named the attack “Operation Aurora”, security researchers have been using McAfee’s definition of what was likely part of it (or not) as the seed for further research and criminal pursuit. McAfee have subsequently redefined what they call “Operation Aurora” and focused upon the most sophisticated attack of the formerly disclosed collection of attacks that targeted (and breached) many large, well known, US businesses. This is obviously going to cause a lot of confusion – especially in light of all the different analysis reports floating around that have been published over the last couple of months covering the “Google attacks” and “Operation Aurora”. While I’m sure McAfee would prefer that the industry adopt a new definition of “Operation Aurora”, given the massive amounts of research already published to-date I’m afraid that train left the station a while ago and, to save on future confusion, I’m going to refer to this revised definition of “Operation Aurora” as “Aurora Lite”.

This morning I reached out to McAfee to get a better understanding of how they differentiate between “Operation Aurora” and “Aurora Lite”. Apparently everything except one particular malware family (which is VNC centric and contains the “aurora” variable), has been dropped, along with all the other Command-and-Control (CnC) domains – leaving just the one CnC linked to [obscured].ftpaccess.cc, which is a dynamic DNS provider-provisioned service. According to the McAfee folks I spoke with (who said they’re OK with me sharing this with you), the attack that I am now terming “Aurora Lite”,is attributed to the targeted compromise of approximately two-dozen companies, with a total footprint of four or five dozen compromised hosts. It consisted of a rapid, in-and-out attack rather than a long-running or persistent campaign – which sounds more like a standard criminal hack.

McAfee also shared that they are updating their “How can you tell” document to reflect the aspects of “Aurora Lite” (the version I just checked is dated 1st March and lists all of the CnC domains – not the reduced list).

Botnets – They’re Still Out There

Before I get started about the particular aspects of “Aurora Lite”, let’s get a few things straight though. All the badness that was disclosed earlier this year hasn’t magically gone away – it still happened. All those various analysis reports covering the multiple aspects of “Operation Aurora” and how the botnet campaigns and attacks were orchestrated, controlled and successfully breached that long list of corporate victims (and the China angle) are still correct. What’s changed is that “Aurora Lite” analysis now is focused upon just one of the attacks that breached those 30+ organizations (as disclosed by Google in January). McAfee is now honing in on apparently the most sophisticated one (in a relative context).
I’ve seen the term “Advanced Persistent Threat” (APT) being thrown about, along with “state-sponsored” attacks and, based upon our analysis of “Operation Aurora”, this level of sophistication was not evident. In fact the opposite appears to be true. The attackers behind several of the botnet campaigns that breached their targeted victims did not use advanced malware techniques nor did they invest in robust CnC infrastructures – and are clearly not in the same ballpark as the professional criminal botnet operators Damballa tracks day-in and day-out focused upon breaking in to enterprise networks.

Interestingly enough, before McAfee released their “Operation Aurora” analysis, Damballa was already tracking these botnets and botnet building campaigns. At the time, we had attributed the botnets to four separate criminal entities (these are Damballa assigned names used for tracking purposes) based upon their shared CnC domains and infrastructure, as well as their malware and historical delivery techniques:

  • YellowWarlockBoys
  • CrazyTreeSaints
  • NaiveGloveTroop
  • OneAlienAvengers

Based upon the original “Operation Aurora” definition from McAfee, we subsequently chose to cluster these four different criminal operators together as a single criminal consortium (customers wanted to refer to “Operation Aurora” within the management consoles of our deployed solution). Now that McAfee has described “Aurora Lite,” we can break them back up again in to the four different criminal groups, since the only “linking” factor between them is the data McAfee originally released, which they now say was incorrect. And yes, as you’ve probably already guessed, only one of these criminal botnet groups relied upon the [obscured].ftpaccess.cc for CnC.

Observations & Analysis

One of the features of the Damballa FailSafe solution is the interception of new malware and suspicious binaries traversing enterprise networks. As such, Damballa managed to obtain many malware samples related to each of the botnet campaigns encapsulated in “Operation Aurora.” We then clustered the samples based upon their specific CnC management requirements. From our perspective, it didn’t matter that zero-day exploits in Internet Explorer were used to infect the victim – just as it didn’t matter that other campaigns made use of social engineering, spear phishing emails or fake antivirus packages. We capture and identify the malware components as they cross the network to the victim system. Consequently, regardless of the limited number of victims attributed to “Aurora Lite” and the implication that serial variant versions of the malware were distributed to each victim computer, Damballa manages to obtain the malware samples used in the attacks targeting our customers.

So, is “Aurora Lite” the sophisticated attack that McAfee and Google originally meant to portray? Going by the redefined scope of “Aurora Lite” that now focuses in on just one of the previously discussed attacks, it’s probably one of the more sophisticated (and smallest) campaigns of the “Operation Aurora” bunch. But frankly I’m going have to hold out for more evidence to be provided if I’m to be expected to support some of the sophistication claims that have been made in recent months. Unfortunately I see this kind of stuff every day, and based upon our analysis of the [obscured].ftpaccess.cc usage for CnC, I’d need more convincing. The malware used by professional cyber criminals today is generally more feature rich and sophisticated than things such as Trojan.Hydraq and the malware that McAfee have stated as being part of “Aurora Lite” – but at the end of the day it’s just a tool for those criminals, and typically a disposable tool at that. Making use of dynamic DNS provisioning of CnC is a popular tactic for some clusters of learner/amateur botnet operators, and as a way of hackers trying to disguise the true source of their attacks.

Obviously, Damballa is focused upon detecting and mitigating the CnC channels employed by botnets, APTs, targeted attacks and insider threats, and have great visibility in to the infrastructure built by criminal operators to perpetuate and support their attacks. However, we’re not focused on the per-host forensic examination of individual victim machines. To recycle a visual metaphor I’ve used before, Damballa tracks and identifies the criminal’s getaway van along with its driver. What happened inside the bank (who fired the first shot, they type of gun they used, what was stolen, etc.) isn’t something we focus upon. But if you want to know the make and model of the getaway van, the route they drove to get to the target and where they drove off to afterwards, well, that we can do as a matter of course.

That isn’t to say that we aren’t aware of what happens though. Most of the research team have extensive experience conducting these kind of forensic analysis – along with conducting penetration attacks just like “Aurora Lite” (in the guise of professional security services and ethical hacking).

Learn & Adapt

Finally, I think it’s valuable to point out that Damballa researchers have been in constant communication with customers that have been (and continue to be) targeted by the “Operation Aurora” criminal campaigns, and we’re providing our expertise to several of the victims that also fell prey to the newly redefined “Aurora Lite” attacks. Our experience with CnC discovery and how dynamic DNS is abused for CnC management, combined with the historical information necessary for building attack timelines, has proven very useful for tracking down the criminal operators behind the threat. Oh, and as security professionals in the field we share this information with the folks working deep inside the “Aurora Lite” victim organizations doing the forensic examination of the breached networks and systems.

A goal for both my team and myself is to further educate people about the true state of the threat. The arsenal of tools, techniques and malware that professional criminal operators can employ in their attacks, and the way in which they can rapidly grow and manage take-down resistant hierarchical CnC infrastructures, is pretty amazing – if not daunting – and it’s accelerating. Despite this redefinition of “Operation Aurora” let’s not forget about all the pain-old-vanilla botnet breaches that occurred earlier this year (and continue) and learn from them. If average or amateurish criminal botnet building campaigns can be so successful against these large organizations, it should be little surprise that the professionals have got such an easy ride nowadays.

– Gunter Ollmann, VP Research.

Tags: , ,
Posted in Threat Research | 1 Comment »

Detecting Botnets with Network DLP

Tuesday, March 30th, 2010

Data Leakage Prevention (DLP) solutions have attempted to occupy a niche area of security for a handful of years now. In general though they’ve been largely unsuccessful in carving out a unique portion of the information security landscape (and corresponding security spend). This doesn’t mean that DLP is a redundant technology, nor does it mean that some enterprise security teams haven’t invested in the technology – merely that pure-play vendors and products have struggled to differentiate themselves from other more established security technologies.

DLP has its place within enterprise networks. Host-based DLP can provide a high degree of content filtering before confidential data hits the network along with detecting and stopping user-initiated content transformations of protected data (e.g. prevent a user from copying financial spreadsheet data in to a PDF file, and encrypting it within a password-protected ZIP file, before attaching it to an outbound email).

Network-based DLP – which is typically deployed at the perimeter of the enterprise – is great for detecting confidential information leakage related to well structured data (e.g. credit card details, social security numbers, etc.), specific file types (e.g. Microsoft Excel files, C development files) and specially constructed data canaries (e.g. data files containing data on specific watch lists – some of which will be fake and/or should never be accessible to legitimate business users).

The problem with DLP is that it’s pretty much already an existing part of the security fabric – especially at the host level. Most popular security suites have had these core capabilities for quite some time, but weren’t called out specifically because they are embedded parts of other detection technologies.

At the network-level, any of the established security technologies employing “DPI” capabilities (Deep Packet Inspection) probably has a better pedigree for performing perimeter identification of confidential data egress. For example just about every successful commercial IPS product has DPI capabilities and, because they’ve been dealing with network protocols and content-layer files for a much longer time, have greater inspection capabilities for a broader range of protocols and file formats.

There are of course problems with DLP. Whether the technology is represented as a standalone solution or embedded within more established security technologies such as IPS, the ability to inspect and identify (and stop) the leakage of confidential data is extremely limited. There are literally an infinite number of ways to bypass and thwart DLP protection technologies. DLP is great for stopping stupid and accidental leakage, but sucks at stopping intentional data theft.

Botnet Detection via DLP

So, the question arises every few weeks or thereabouts, “how does DLP protect me from botnets?” – the simple answer is “it doesn’t really”. But let’s investigate just how useful is DLP in combating botnets anyway. First of all, we obviously need some degree of clarification about “combating botnets”. Lets break this down in to three separate botnet attack phases:

  1. Preventing hosts from becoming botnet victims,
  2. Detecting and stopping the leakage of confidential corporate information,
  3. Cleanup and remediation of bot infected victims.

Preventing hosts from becoming botnet victims

In order to understand DLP capabilities in preventing hosts from becoming botnet victims (from a network perspective), we need to bear in mind the limitations of DPI and the most common mechanisms hosts succumb to being compromised and joining a botnet.

  • Criminals employ a broad spectrum of attack vectors in order to compromise their target – with the most common being spam/phishing emails that convince the user to infecting themselves, malicious drive-by-download sites the exploit vulnerabilities in the Web browser and removable media worming (e.g. USB devices). Unless the DLP solution is configured to watch inbound network traffic and scrutinize URL’s (perhaps using a URL blacklist for checking against), the probability of detecting the malicious payloads is remote – any anti-spam and perimeter Web gateway technologies would be a much more effective solution here. IPS technologies would also excel in dealing with the exploits being used to compromise the Web browser vulnerabilities.
  • Inspection of the HTTP/FTP/etc. downloads or email attachments is of course possible – but it will be a struggle to identify the malicious intent of the binary files, but should best be dealt with using anti-virus technologies – particularly products with good behavioral analysis engines and, in a pinch, virtual/sandbox dynamic-analysis of malware (not my favorite technology – especially when employed within the enterprise).

I think you would be hard pressed to use DLP technologies as an effective tool for preventing hosts from becoming botnet victims.

Detecting and stopping the leakage of confidential corporate information

Detecting the information leakage from bot infected hosts should be an easy task – after all, that’s supposed to be DLP’s bread and butter. Unfortunately it’s not quite as easy as it sounds.

  • The signatures (or “fingerprints”) DLP devices use are generally tuned to specific forms of structured data. For example, SSN’s, credit card details and address details have a specific structure. As such, DLP solutions are generally good at spotting this kind data being transmitted across a network and leaking from the enterprise (just as IPS’s can too). As such, DLP appliances can easily detect the “clear text” transport of these kinds of data.
  • Unfortunately, botnet operators tend not to transport/extract confidential data past perimeter inspection/detection technologies in “clear text”. Obviously, if the bot agent chooses to transport the data to a remote server over HTTPS, then all the traffic will be encrypted. But botnet operators don’t even need to do that…
  • Purchasing, managing and configuring Web server certificates for HTTPS can be tedious and can often result in “invalid certificate” alerts – which would in turn alert the user of any folks inspecting the system logs. As such, many botnet operators have decided to not use HTTPS – instead they extract their stolen data over un-encrypted HTTP, but they compress and encrypt the data they’re stealing from on the victims machine before sending. I.e. the transport is unencrypted, by the file being transferred is itself encrypted and cannot be inspected by DLP (or any other DPI technology).
  • Armed with a blacklist of known botnet Command and Control (CnC) channels or file drop-boxes, the DLP solution could keep watch over who the victim system is communicating with and block those – but there are already plenty of IP/Domain/URL blocking technologies already out there that are more efficient. Besides, blacklist approaches to botnet CnC detection are generally of little value when the professional botnet operators are registering thousands of new ones each day and employing them against targeted victims.
  • It’s important to understand that many professional botnet operators have moved away from stealing classic datasets (e.g. credit card details, SSN’s, etc.), and towards more valuable datasets (e.g. software source code, CFO banking credentials, prototype designs) – which happen to be considerably more difficult to detect with DLP technologies (especially if the data is encrypted of course).
  • DLP is limited to specific protocols and specific file/attachment types for inspection. To evade detection, the criminal botnet operator just needs to use an “unsupported” protocol/format.

Cleanup and remediation of bot infected victims

I can’t think of anything that DLP offers in this realm.

In general, DLP makes for a very poor anti-botnet technology. DLP is adequate enough detecting the simple stuff – e.g. a user sending an email with 10,000 credit card details – but is ill positioned to detect an automated bot agent obfuscating or encrypting a compressed file of corporate secrets (which is where today’s threat actually is).

Use DLP to protect against stupid, but don’t be naive.

If you’re interested in understanding how other technologies fare in combating botnets (and APT’s), check out an earlier posting on “Detecting botnets with ADS“.

– Gunter Ollmann, VP Research

Tags: ,
Posted in Threat Research | 2 Comments »

Locking Botnet Agents to Thwart Malware Analysis

Wednesday, March 17th, 2010

Earlier this week, a customer asked me what was the smartest and most sophisticated thing I’d seen malware authors doing recently. He was probably expecting me to mention some new toolset feature such as auto-cracking CAPTCHA‘s for webmail spamming or the custom advertiser routines for redirecting in-browser advertising… instead, I discussed the new host-locked malware versions that are being experimented with by a number of professional botnet operators.

Three years ago I wrote a paper covering the one-of-a-kind exploitation techniques that were being adopted by drive-by-download distributors and exploit delivery systems. The paper – X-Morphic Exploitation – covers the generation of one-off “custom” exploits and malware that are created for each potential victim visiting the attackers malicious Web site. One of the techniques covered related to the creation and delivery of serial variant malware and how each unique sample was only ever served to a single victim – all as a means of defeating signature-based protection technologies (and, to a smaller extent, bulk analysis of malware samples).

Well, as you’d expect, the threat has moved on. While the X-Morphic exploit delivery platforms have grown more and more popular over the last three years, it would seem that the botnet builders have adopted an additional new (and rather powerful) technique that makes it even more difficult for malware analysts and bulk analysis tools to deal with their malicious bot agents – and it taken right out of the commercial anti-piracy cookbook.

To explain whats going on, it’s probably easiest to step through a botnet infection that makes use of the new technique:

  1. The would-be victim/user is browsing the Internet and stumbles upon a drive-by-download Web page. The page cycles through a number of Web browser vulnerabilities – locates an exploit that will work against the users browser – exploits the vulnerability – inserts a shellcode payload and causes the newly introduced (and hidden) process(es) to execute.
  2. A hidden process downloads a “dropper” file on to the victims computer, and causes it to execute. The dropper may be a custom package created just for this victim (i.e. X-Morphic generated) or one that is being served to all potential victims for that day/week.
  3. The dropper unpacks itself – unraveling all of the tools, scripts and malware agents it needs on to the victims computer – and then proceeds to hide the malicious payload components (e.g. disabling the hosts antivirus protection, turning off auto-updates, modifying startup processes, root-kitting the botnet agent), cleans itself up by removing all redundant files and evidence of the installation activities, and finally starts up the actual botnet agent.
  4. The first time the botnet agent starts up, it does a number of checks to see whether or not it has Internet access (e.g. deciding whether a corporate proxy is in use) and whether or not its running on a “real” victims computer (i.e. that it’s not running in a sandbox or virtualized environment – which would indicate that someone is trying to analyze and study the malware itself). If everything looks good and the coast is clear (so to speak), the botnet agent does a quick system-level inventory of the victims computer (e.g. CPU ID, HDD serial number, network card MAC, BIOS version, etc.) and then makes its first connection to the botnet’s Command and Control (CnC) – registering the victims computer as a member of the botnet, and sending through the unique system inventory data.
  5. In response, the botnet CnC immediately sends an updated bot agent to the victims computer – uninstalling the old agent, and installing the new agent. However, this new agent is specifically created and “locked” to the victims computer – i.e. it is unique to this particular victim and will not run on any other computer.
  6. Once the new “locked” bot agent is installed, it connects to a different CnC server – and the victim’s computer is now fully incorporated in to the criminals botnet, and under their remote control.

Those last three steps are what’s new and innovative, and what’s going to spell the ruin for many of the most important malware analysis tools and techniques antivirus vendors use to combat the malware plague.

By infecting their victims computer with a unique and “locked” version of bot agent (or malware), and ensuring that it will only ever run on that particular victims computer, it means that any samples that may eventually be acquired by the antivirus vendor(s) wont actually be useful to them. Automated analysis systems that take in malware samples from spam traps, web crawlers, etc. and execute them in virtual environments or sandboxes etc. will not yield the real botnet agent for study nor details of the true botnet CnC. Meanwhile, malware samples obtained from forensic retrieval processes or submitted by antivirus customers will not work (e.g. they will either not function maliciously or not execute at all in an analysis environemnt) – because they are encoded and locked specifically to the victims machine.

This “locking” process isn’t new in itself. Many commercial software vendors use this technique – for example, Microsoft uses the same technique for detecting pirated versions of their operating system and enforcing their licensing policy.In fact many manufacturers of DIY malware construction kits use the same techniques to protect their toolkits from being both pirated and falling in to the hands of security vendors. However, in this case the botnet operators are using it as a technique to ensure that samples of their malicious bot agents are useless to antivirus vendors.

Sure, a skilled malware reverse engineer could manually work around this kind of software locking mechanism, but its a slow and tedious process even for the most experienced folks – and manual analysis done in this way doesn’t remotely scale in any meaningful way to counter this threat. That said, if the (real) botnet agent also sends through an updated system inventory to the botnet CnC server each time it connects, and the “signature” no longer matches the one that the bonet operator originally associated with that particular botnet agent, then the botnet operator will know that someone is tampering with their software and disconnect the victim from the botnet (or perhaps launch an attack at the investigators/analysts computer)

As botnet operators (and general malware authors) further adopt this kind of victim-specific locking practice to protect their malware investment, and as the sophistication of the locking increases (as it inevitably will), the antivirus industry is going to have to rethink many of the techniques it currently relies upon for sample analysis and signature generation. There is no easy option for countering this new criminal practice.

– Gunter Ollmann, VP of Research

Tags: , , ,
Posted in Threat Research | No Comments »

Why Didn’t The Aurora Botnet Operators Use DIY Malware Kits?

Thursday, March 11th, 2010

Does anyone really believe that the botnet operators behind the Aurora attacks chose to use the most basic and amateurish malware they had on hand because they didn’t need anything more advanced? That sounds about as silly as a bank robber choosing to leave his gun at home in favor of taking an 18 inch wooden baton along because he hears that the guards are only armed with 16 inch batons.

But, nevertheless, you’ve got to wonder why the botnet operators in question ended up using such unsophisticated and dated malware tools – especially when much more advanced tools are easily accessible. The output from any number of commercial malware creator kits (e.g. Zeus, Butterfly, SpyEye, Turkojan, etc.) are more sophisticated and capable than Trojan.Hydraq – and those are what I’d term “average” tools for a learner botnet operator. Compared to something like Conficker.C, Trojan.Hydraq had only recently stepped out of the primordial soup – and Conficker.C is over a year old already.

Then of course there’s the question as to why the malware didn’t employ any kind of armoring (e.g. packers, cryptors, anti-VM, anti-debugger, etc.). It’s not as if you have to go far to find or obtain them. Nor could you be blind to their existence – since practically every hacker site in existence contains extensive references to them (and guides on their use).

I’ve also heard a few people say that the botnet operators were so smart that they may have created the malware to look like it was developed by a bunch of amateurs. It’s all beginning to sound like a conspiracy theory – next we’ll hear that aliens have landed and are subtlety infiltrating online businesses as they proceed with their plan for world domination…

What we do know is that the botnet operators were running multiple botnet building campaigns simultaneously, and employing a number of different delivery techniques that targeted a bunch of similar businesses. The campaigns they ran made use of different families of malware and were slowly evolving in sophistication (but not by much) by the time they made the news in mid-January. It also appears that the various malware families were developed by different authors.

One question I’ve got to ask though is “Why didn’t they just use a DIY kit?” Malware generated using one of the kits would have offered greater functionality, armoring, and would generally have had less likelihood of detection. Some possible reasons for not using a DIY kit:

  • They didn’t trust the kits that are out there. Many of the free and pirated kits are backdoored – meaning that any malware created from them have hidden CnC’s built in, and report back to the kit author/pirate.
  • Just about every kit I tend to come across is menu driven and relies upon English, Portuguese or Spanish (sometimes Catalan) to use properly. Perhaps the botnet operators couldn’t find a kit that supported their language preference and they couldn’t understand them? (sounds like a market opportunity for some would-be DIY kit author)
  • The malware authors may have wanted to “learn on the job” and treated the whole thing as a learning experience. As crazy as it seems, this is a popular experiment amongst the newbie hackers and computer science undergrads.
  • Perhaps the malware authors have led a sheltered life and naively thought they could do it better than the professionals.

Regardless, the botnet operators did what they did and they were successful enough with it. I think they were a little lucky in their attacks and I’m a little surprised they managed to run their campaigns for as long as they did. That said though, it’s a valuable lesson for big businesses out there; if a bunch of amateurs can reap this much havoc with outdated unsophisticated tools and a pinch of luck, how easily do you think an experienced criminal crew can break their defenses?

– Gunter Ollmann, VP Research

Tags: ,
Posted in Threat Research | No Comments »

Corporate Espionage and Tethered Criminal Actions

Wednesday, January 13th, 2010

The media is buzzing with the latest news concerning Google and Adobe and the targeted attacks directed at their corporate systems. While it’s news, it’s important to understand that this isn’t something that’s only just happened – rather it’s been something that both these organizations (and dozens more) have been subjected to for quite some time; it’s just become public, and they’re admitting to be the victims. But this is important.

I’ve been providing security consultancy advice for a couple of decades. I’ve been pulled in to do post attack forensics along with specialized pentesting, bug-hunting and reverse engineering for the majority of the Fortune 500 companies and in all that time, unless they were required to by law, not one have gone public about the attacks they were subjected to and the losses they have incurred. That’s why this Google/Adobe/etc. news is so significant – some Fortune-500 companies are actually saying “hey, enough already, we’re under constant attack – we need to do something collectively about this!”

Whats the primary vehicle for these (ongoing) attacks? You’ll hear plenty of discussion portraying viruses and malware as being the problem, and plenty of implications that the Chinese government lies behind the attack(s). But let’s be clear – that’s a fantastically simplistic view of the threat. Implying that the threat lies with targeted malware and China is like saying that drunk driving deaths are due to poor car design, and that the underlying cause is a particular beer brewery.

Malware is just a tool. The fundamental element to these (and any espionage attack) lies with the tether that connects the victim with the attacker. Advanced Persistent Threats (APT), like their bigger and more visible brother “botnets”, are meaningless without that tether – which is more often labeled as Command and Control (CnC).

The methods for getting a malware agent into an organization and on to key/critical hosts are incredibly diverse but, most importantly, can best be phrased as “trivial”. If someone wants to infect systems within a targeted organization and is willing to spend more than a few thousand dollars worth of effort to do so, it’ll happen – simple as that. Just as importantly, the malware being distributed and used in these kinds of attacks can be thought of as a Swiss Army knife with Klingon cloaking capabilities.

I jest only in part about the Klingon cloaking part – but it actually works well as a visual metaphor. Just as the Klingon Warbirds must decloak in order to launch their attack with photon torpedoes etc., APT’s and botnets must decloak themselves at the network level in order to maintain their CnC connections and be successful in harvesting espionage data. While APT’s are more surreptitious when it comes to CnC connectivity, their weakness lies in their network communications. At the host level, the probability of detecting an installation prior to actual financial/legal damage lies largely in the realm of dragons and mermaids.

Looking at the botnets we identify and track at Damballa that target enterprise networks, many of them fall in to the classification realm of APT’s. The malware component is under constant change – often being updated on a daily basis. Meanwhile the low-and-slow stealthy CnC traffic navigates the corporate network, weaves it’s way through fast fluxing networks and stratified levels of command relays, and makes it back to the team who’s really in control of the compromised assets – a bunch of contracted criminals located somewhere safe and far away. I use the term “team” on purpose because this is an organized collective of professional operators – each with their own skills and specialties.

I see a lot of discussions about preventing systems from being compromised – in fact most of the security business today is exclusively focused on threat prevention. But, you know what, every year (for the last two decades at least) as antivirus vendors release their annual threat reports the percentage of hosts known (or suspected) of being a victim and running malware has increased. As we launch in to 2010, I think the percentage most industry experts and veterans would throw about would be 35-40 percent of all Internet connected systems are compromised and currently running malware. Despite the terrific advances in detection, mitigation and cleanup – the numbers continue to go up. Despite the new detection technologies, the bad guys retain their lead. APT’s related malware lie in a particular niche, but they aren’t being prevented from getting in to an targeted organization. Let’s just face facts – if someone wants in on your organization and are willing to invest time and resources to do so, the probability that they will be successful in doing so certainly favors them.

Detecting and mitigating the CnC – breaking that tether of control – lies at the heart of dealing with this threat. By blocking those CnC channels, the bad guys can’t remotely control your enterprise systems, and they can’t extract the secret data they want. Tracing back who lies at the end of the CnC communication ultimately leads to he contracted criminals running the operation. The fact that those criminals happen to be located in a particular country is only part of identifying the instigators of the threat – but it’s probably as far as we’ll get.

Like I said earlier, I’ve had to deal with many of these threats before. In the UK, it appeared that many of the corporate espionage attacks were masterminded by French or US entities. In Taiwan it appeared to be China and South Korea. In China it appeared to be Taiwan and Australia. In Greece it appeared to be Turkey and Egypt. And so on… but those are only my specific experiences. [unfortunately, not a single corporate victim ever went public about the attacks they fell victim to - and probably never will... sigh]

With regards to the APT’s and botnets that Damballa tracks, detects and mitigates… well, those CnC’s are spread around all over the world and most likely reflect the locations of the professional teams that contract out there services, rather than the location of their their ultimate customers.

My advice to organizations being targeted with APT’s, botnets and unauthorized remote control of corporate resources? Focus on the network CnC – and mitigate there. By all means protect your perimeter and clean up your hosts – that’ll keep the unsophisticated script-kiddies and rif-raf off your systems – but it means very little to the pros. Success in dealing with this threat – the threat that Google, Adobe, and most global businesses (and governments) face constantly – is to identify which assets are currently compromised and “nuke-and-pave” them asap. I.e. identify systems that are trying to connect to their remote CnC, immediately cut that tether, and rapidly rebuild that system from a known good state (which is increasingly looking like a bare-metal state). If you can get that notification-to-rebuilt process down to 20 minutes or less, you’ll be in a good position to deal with this class of threat long term. Until then, you’re just messing around at playing detective.

– Gunter Ollmann, VP Research

Tags: , , , , ,
Posted in Threat Research | 2 Comments »