Get Ready for the First Wave of AI Malware

While viruses and malware have stubbornly stayed as a top-10 “things I lose sleep over as a CISO,” the overall threat has been steadily declining for a decade. Unfortunately, WannaCry, NotPetya, and an entourage of related self-propagating ransomware abruptly propelled malware back up the list and highlighted the risks brought by modern inter-networked business systems and the explosive growth of unmanaged devices.

The damage wrought by these autonomous (not yet AI-powered) threats should compel CISOs to contemplate the defenses to counter such a sophisticated adversary.

The threat of a HAL-9000 intelligence directing malware from afar is still the realm of fiction, so too is the prospect of an uber elite hacker collective that has been digitized and shrunken down to an email-sized AI package filled with evil and rage. However, over the next two to three years, I see six economically viable and “low hanging fruit” uses for AI infused malware – all focused on optimizing efficiency in harvesting valuable data, targeting specific users, and bypassing detection technologies.

• Removing the reliance upon frequent C&C communications – Smart automation and basic logic processing could be employed to automatically navigate a compromised network, undertake non-repetitive and selective exploitation of desired target types and, upon identification and collection of desired data types, perform a one-off data push to a remote service controlled by the malware owner. While not terribly magical, such AI-powered capabilities would not only undermine all perimeter blacklist and enforcement technologies, but also sandboxing and behavioral analysis detection.
• Use of data labeling and classification capabilities to dynamically identify and capture the most interesting or valuable data –  Organizations use these types of data classifiers and machine learning (ML) to label and protect valuable data assets. But attackers can exploit the same search efficiencies to find the most valuable business data being touched by real users and systems and to reduce the size of data files for stealthy exfiltration. This enables attackers to sidestep traffic anomaly detection technologies as well as common deception and honeypot solutions.
• Use of cognitive and conversational AI to monitor local host email and chat traffic and to dynamically impersonate the user – The malware’s AI could insert new conversational content into email threads and ongoing chats with the objective of socially engineering other employees into disclosing secrets or prompting them to access malicious content. Since most email and chat security solutions focus on in-bound and egress content, internal communication inspection is rare. Additionally, conversational AI is advancing quickly enough to make socially engineering IT helpdesk and support staff into disclosing secrets or making temporary configuration a high probability.
• Use of speech to text translation AI to capture user and work environment secrets –Through a physical microphone, the AI component could convert all discussions within range of the compromised device to text. In addition, some environments may enable the AI to successfully capture the keystrokes of nearby systems and deduce what keys are being pressed. Such an approach also allows hackers to be more selective of what secrets to capture, further minimizing the volume of data that must be egressed from the business, which then reduces the odds of triggering network-based detection technologies.
• Use embedded cognitive AI in applications to selectively trigger malicious payloads – Since it is possible for cognitive AI systems to not only recognize a specific face or voice, but also determine their race, sex, and age, it is therefore possible for a malware author to be very specific in who they choose to target. Such malware may only be malicious for the CFO of the company or may only manifest itself if the interactive user is a pre-teen female. Because the trigger mechanism is embedded within complex AI, it becomes almost impossible for automated or manual investigation processes to determine the criteria for initiating the malicious behaviors.
• Capture the behavioral characteristics and traits of system users – AI learning systems could observe the unique cadence, timbre, and characteristics of the users typing, mouse movements, vocabulary, misspellings, etc. and create a portable “bio-profile” of the user. Such “bio-profiles” could then be reused by attackers to bypass the current generation of advanced behavioral monitoring systems that are increasingly deployed in high security zones.

These AI capabilities are commercially available today. Collectively or singularly, each AI capability can be embedded as code within malicious payloads.

Because deep neural networks, cognitive AI, and trained machine language classifiers are incredibly complex to decipher, the trigger mechanism for malicious behaviors may be deeply buried and impossible to uncover through reverse engineering practices.

The baseline for defending against these attacks will lie in ensuring all parts of the organization are visible and continually monitored. In addition, CISOs need to invest in tooling that brings speed and automation to threat discovery through AI-powered detection and response.

As malware writers harness AI for cybercrime, the security industry must push forward with a new generation of dissection and detonation technologies to prepare for this coming wave. A couple promising areas for implementing defensive AI include threat intelligence mining and autonomous response (more on this later).

-- Gunter Ollmann

First published: SecurityWeek - April 9, 2019

Nitol and 3322.org Action by Microsoft

Reading this morning's blog from Microsoft about "Operation b70" left me wondering a lot of things. Most analysts within the botnet field are more than familiar with 3322.org - a free dynamic DNS provider based in China known to be unresponsive to abuse notifications and a popular home to domain names used extensively for malicious purposes - and its links to several botnets around the world. So it was a surprise to hear that Microsoft was able to team up with Nominum to usurp control of the 3322.org domain (zone) and effectively block the known malicious domains, while other regular users can carry on with their business or businesses.

Microsoft presented the need to take control of this cluster of malicious domains as a necessary action against the Nitol botnet and to protect and secure the supply chain. While I don't quite understand all of the logic behind this argument (there's just not enough info public at this point in time), at the end of the day Microsoft have managed to remove a thorn from the community's side.

The Nitol botnet is, in general terms, bothersome but not a wide scale threat. Damballa Labs has been tracking the threat for quite some time and, as botnets go, is a rather small and tired affair. If you're a victim of Nitol though, yes, it's a pain-in-the-bum DDOS agent.

The 3322.org angle is much more interesting to me than the Nitol botnet that formed the legal excuse for being able to seize control of the domain.

From a Damballa Labs perspective, we currently track around 70 different botnets that currently leverage 3322.org's DNS infrastructure for C&C resiliency - using a little over 400 different third-level domain names of 3322.org. With a bit of luck I'll have some size information about those botnets later today.

Will the usurping of 3322.org kill these botnets? Unfortunately not. There may be a little disruption, but it's more of an inconvenience for the criminals behind each of them. Most of these botnets make use of multiple C&C domain names distributed over multiple DNS providers. Botnet operators are only too aware of domain takedown orders from law enforcement, so they add a few layers of resilience to their C&C infrastructure to protect against that kind of disruption.

Take Nitol for example - it employs multiple domains from several free dynamic DNS providers, including other four-digit .ORG domain services such as 6600.org, 7766.org, 2288.org and 8866.org.

Interestingly enough, the (former) owners of 3322.org are providing new support advice to their inconvenienced customers in how to bypass this interuption by Microsoft:

Or, after some Google translation:

Good to know that it's business as usual...

 The story isn't over yet!

Botnet Metrics: Learning from Meteorology

As ISP’s continue to spin up their anti-botnet defenses and begin taking a more active role in dealing with the botnet menace, more and more interested parties are looking for statistics that help define both the scale of the threat and the success of the various tactics being deployed. But, as I discussed earlier in the year (see “Household Botnet Infections“), it’s not quite so easy to come up with accurate infection (and subsequent remediation) rates across multiple ISP’s.

To overcome this problem there are several initiatives trying to grapple with this problem at the moment – and a number of perspectives, observations and opinions have been offered. Obviously, if every ISP was using the same detection technology, in the same way, at the same time, it wouldn’t be such a difficult task. Unfortunately, that’s not the case.

One of the methods I’m particularly keen on is leveraging DNS observations to enumerate the start-up of conversations between the victim’s infected device and the bad guys command and control (C&C) servers. There are of course a number of pros & cons to the method – such as:

• DNS monitoring is passive, scalable, and doesn’t require deep-packet inspection (DPI) to work [Positive],
• Can differentiate between and monitor multiple botnets simultaneously from one location without alerting the bad guys [Positive],
• Is limited to botnets that employ malware that make use of domain names for locating and communicating with the bad guys C&C [Negative],
• Not all DNS lookups for a C&C domain are for C&C purposes [Negative].

On the top of all this lies the added complexity that such observations are conducted at the IP address level (and things like DHCP churn can be troublesome). This isn’t really a problem for the ISP of course – since they can uniquely tie the IP address to a particular subscriber’s network at any time.
One problem that persists though is that a “subscriber’s network” is increasingly different from “a subscriber’s infected device”. For example, a subscriber may have a dozen IP-enabled devices operating behind their cable modem – and it’s practically impossible for an external observer to separate one infected device from another operating within the same small network without analyzing traffic with intrusive DPI-based systems.

Does that effectively mean that remote monitoring and enumeration of bot-infected devices isn’t going to yield the accurate statistics everyone wants? Without being omnipresent, then the answer will have to be yes – but that shouldn’t stop us. What it means is that we need to use a combination of observation techniques to arrive at a “best estimate” of what’s going on.

In reality we have a similarly complex monitoring (and prediction) system that everyone is happy with – one that parallels the measurement problems faced with botnets – even if they don’t understand it. When it comes to monitoring the botnet threat the security industry could learn a great deal from the atmospheric physicists and professional meteorologists. Let me explain…

When you lookup the weather for yesterday, last week or last year for the 4th July, you’ll be presented with numerous statistics – hours of sunshine, inches of rainfall, wind velocities, pollen counts, etc. – for a particular geographic region of interest. The numbers being presented to you are composite values of sparse measurements.

To arrive at the conclusion that 0.55 inches of rainfall fell in Atlanta yesterday and 0.38 inches fell in Washington DC over the same period, it’s important to note that there wasn’t any measurement device sitting between the sky and land that accurately measured that rainfall throughout those areas. Instead, a number of sparsely distributed land-based point observations specific to the liquid volume of the rain were made (e.g. rain gauges), combined with a number of indirect methods (e.g. flow meter gauges within major storm drain systems), and broad “water effect” methods (e.g. radar) were used in concert to determine an average for the rainfall. This process was also conducted throughout the country, using similar (but not necessarily identical) techniques and an “average” was derived for the event.

That all sounds interesting, but what are the lessons we can take away from the last 50 years of modern meteorology? First and foremost, the use of accurate point measurements as a calibration tool for broad, indirect monitoring techniques.

For example, one of the most valuable and accurate tools modern meteorology uses for monitoring rainfall doesn’t even monitor rain or even the liquid component of the droplets – instead it monitors magnetic wave reflectivity. Yes, you guessed it – it’s the radar of course! I could get all technical on the topic, but essentially meteorological radar measure the reflection of energy waves from (partially) reflective objects in the sky. By picking the right wavelength of the magnetic wave from a radar, it gets better at detecting different sized objects in the sky (e.g. planets, aircraft, water droplets, pollutant particulates, etc.). So, when it comes to measuring rain (well, lots of individual raindrops simultaneously to be more precise), the radar system measures how much energy of a radar pulse was returned and at what time (the time component helps to determine distance).

Now radar is a fantastic tool – but by itself it doesn’t measure rainfall. Without getting all mathematical on you, the larger an individual raindrop the substantially bigger the energy reflection – which means that a few slightly larger raindrops in the sky will completely skew the energy measurements of the radar – meanwhile, the physical state of the “raindrop” also affects reflectivity. For example, a wet hailstone reflects much more energy than an all-liquid drop. There are a whole bunch of non-trivial artifacts of rainfall (you should checkout things like “hail spikes” for example) that have to be accounted for if the radar observations can be used to derive the rainfall at ground level.

In order to overcome much of this, point measurements at ground level are required to calibrate the overall radar observations. In the meteorological world there are two key technologies – rain gauges and disdrometers. Rain gauges measure the volume of water observed at a single point, while disdrometers measure the size and shape of the raindrops (or hail, or snow) that are falling. Disdrometers are pretty cool inventions really – and the last 15 years have seen some amazing advancements, but I digress…

How does this apply to Internet security and botnet metrics? From my perspective DNS observations are very similar to radar systems – they cover a lot of ground, to a high resolution, but they measure artifacts of the threat. However those artifacts can be measured to a high precision and, when calibrated with sparse ground truths, become a highly economical and accurate system.

In order to “calibrate” the system we need to use a number of point observations. By analogy, C&C sinkholes could be considered rain gauges. Sinkholes provide accurate measurements of victims of a specific botnet (albeit, only a botnet C&C that has already been “defeated” or replaced) – and can be used to calibrate the DNS observations across multiple ISP’s. A botnet that has victims within multiple ISP’s that each observe DNS slightly differently (e.g. using different static reputation systems, outdated blacklists, or advanced dynamic reputation systems), could use third-party sinkhole data for a specific botnet that they’re already capable of detecting via DNS, as a calibration point (i.e. scaling and deriving victim populations for all the other botnets within their networks).

Within their own networks ISP’s could also employ limited scale and highly targeted DPI systems to gauge a specific threat within a specific set of circumstances. This is a little analogous to the disdrometer within meteorology – determining the average size and shape of events at a specific point, but not measuring the liquid content of the rainfall directly either. Limited DPI techniques could target a specific botnet’s traffic – concluding that the bot agent installs 5 additional malware packages upon installation that each in turn attempt to resolve 25 different domain names, and yet are all part of the same botnet infection.

Going forward, as ISP’s face increased pressure not only to alert but to protect their subscribers from botnets, there will be increased pressure to disclose metrics relating to their infection and remediation rates. Given the consumer choice of three local ISP’s offering the same bandwidth for the same price per month, the tendency is to go for providers that offer the most online protection. In the past that may have been how many dollars of free security software they bundled in. Already people are looking for proof that one ISP is better than another in securing them – and this is where botnet metrics will become not only important, but also public.

Unfortunately it’s still early days for accurately measuring the botnet threat across multiple ISP’s – but that will change. Meteorology is a considerably more complex problem, but meteorologists and atmospheric physicists have developed a number of systems and methods to derive the numbers that the majority of us are more than happy with. There is a lot to be learned from the calibration techniques used and perfected in the meteorological field for deriving accurate and useful botnet metrics.

Threat Intelligence via Sinkholes

Over the last few months I've been seeing more and more folks pimping botnet victim intelligence feeds. Despite the obvious flaws in these feeds, the subscriptions are going up - despite most folks not really understanding how to use the intelligence.

Just about all the data being sold is harvested from sinkholes - which happens to be a rather crap way of gathering that kind of information. There are all kinds of limitations to the way the intelligence can be employed - especially from a protection perspective.

By way of education, I've pulled together an educational post covering the problems with sinkhole harvested data - from both technology and legal/ethical perspectives.

You can find the posting at the Damballa site - http://blog.damballa.com/?p=1342

Optimal Methods for Spam and DDoS Offender Discovery

As botnet threats go, Spam and DDoS are probably the most widely known and discussed tactics employed by criminal operators. Despite being some of the last things that career botnet operators employ their compromised victims for, and despite offering the lowest monetization rates for the criminals, DDoS and Spam volume have continued to rise annually.

A question was asked to me recently as to which techniques worked best for dealing with DDoS and Spam participation from within large enterprises or residential DSL/Cable networks – Network Anomaly Detection Systems (NADS) or botnet command-and-control (CnC) enumeration techniques (such as those employed by Damballa)?

It’s not the kind of question that can be answered succinctly. Both approaches are designed to scale to very large networks – and as such are components of a robust protection strategy. In fact the technologies are rather complementary – although I do think that the CnC enumeration approach is more elegant and efficient in the grand scheme of things.

The NADS approach to Spam and DDoS participation detection is simple enough – you monitor netflow (a compact summary of network packet flow – usually to/from IP address, port, protocol, date/time and packet size information), determine a baseline for traffic levels, set alert thresholds for potential anomalies, and define responses when a threshold alert is received. In the context of a simple DDoS threat, you set up a threshold for the volume of HTTP traffic directed at a single destination by a single IP host and label that host as initiating a DDoS attack. If multiple hosts within the network being monitored also reach the HTTP threshold(s) against the same target IP address, you label them all as being part of a DDoS botnet. The same basic principles apply to Spam botnet detection.

An alternative and generally complementary approach to the problem is to automatically identify hosts within the monitored network that are already infected with malware and/or engaged in conversations with botnet CnC servers. This can be achieved in a variety of ways, but one of the simplest ways is to merely observe the DNS requests made by the hosts and the responses from the resolving DNS servers. Having identified suspicious DNS request profiles along with DNS responses that have high probabilities of association with criminal hosting infrastructure, it’s possible to quickly match victims with particular botnets – and label the new (or previously known) CnC fully qualified domain name. Any other hosts exhibiting similar DNS resolution characteristics are members of the same botnet. The beauty of this approach is that this method of detection and botnet enumeration (and labeling) can be done before the botnet victims actually participate in any subsequent Spam or DDoS campaigns.

When it comes to mitigating the threat, the historical way is to effectively block the attack traffic by either firewalling off specific ports or destination IP addresses, or walled gardening the malignant hosts. So, while the botnet host is spewing spam or DDoS traffic, it’s not being routed to its final (target) destination.

That approach may have been OK in the past if you were only dealing with IP-based threat responses and could stomach the voluminous traffic internally, but with more advanced CnC and botnet enumeration technologies you’re able to bring to bear some additional (and more versatile) mitigation techniques. Since you’re constantly identifying and tracking botnet membership and you know which CnC’s these victims are being controlled by, you could perform one or more of the following actions:

1. As botnet members begin to participate in the DDoS attack or Spam campaign, traffic to and from the CnC server could be blocked. By doing so, no new commands are sent to the botnet victims and they typically cease their attacks. In addition, any other botnet members within the network who have not yet been tasked to participate in the attack will similarly not be able to receive instructions.
2. Walled Gardens can be selectively initiated around the infected botnet population – blocking just the ports and protocols being used (or likely to be used) in the attack against remote targets – without applying the same blocking to all hosts or subscribers within the network. For example, a botnet may be tasked with DDoSing a popular financial services web portal using a HTTP-based payload. It would therefore be important to only block the attack traffic and allow legitimate traffic through. A walled garden approach could be used in this scenario without having to utilize Deep Packet Inspection (DPI) to differentiate between the attack and legitimate traffic.
3. The ability to differentiate CnC server activity at the domain name level is important for botnets that utilize fast flux infrastructure to distribute command over large numbers of IP addresses. If recursive DNS services are provided by the organization to their enterprise hosts or subscribers, an alternative DNS response could be sent to the botnet victims – e.g. making botnet.badness.com.cc resolve to localhost (127.0.0.1).
4. If DPI or PCAP capabilities exist within the organization, they could be selectively deployed to catalog the criminal communications between the botnet members and the CnC server. This detailed evidence of the attack (including the commands being sent by the CnC) can be used for takedown or prosecution purposes.
5. If the botnet malware agent is relatively unsophisticated or if the CnC server itself is vulnerable to third-party takeover (e.g. a hacked server that the legitimate owner regains control and can now issue commands to the botnet, or if the Botnet CnC portal code contains remotely exploitable vulnerabilities), it may be possible to issue commands “on behalf” of the criminal operator instructing all the botnet members to stop their attack and to automatically uninstall the malware agent.

There are of course many other imaginative ways to use the knowledge of the botnet CnC and its members in preemptive protection strategies too.

I think that NADS-based botnet detection (or more precisely botnet attack traffic detection) is useful for identifying triggers for remediation action – but I think that botnet CnC enumeration techniques can provide greater flexibility in long-term threat management approaches.

Where are those botnet CnC's at?

If you're building or managing a botnet of more than a few thousand victim machines, where and how you host your command and control (CnC) servers is damned important.
Where were the bad guys hosting there CnC servers for the first half of the year? Damballa has just released a blog covering the top-10 worst offender service providers as well as a breakdown by country. Guess who's at the top of the lists...

Botnet Hosting (H1 2010) Blog

Botnet Operations: Running a Campaign

"One bullet, one kill" - isn't that some kind of sniper saying from the movies? If you're a professional botnet operator you're not going to want to loose control of your favorite botnet just because some damned whitehat managed to take down a single command and control (CnC) server.

With that in mind, you're also probably not going to want to build your botnet in a way that its growth is reliant upon a single infection vector or content distribution vehicle. The solution nowadays lies with the strategy of running multiple campaigns against your targets.

Just as political contenders running for office unleash a barrage of sophisticated and targeted campaigns to draw in supporters, professional botnet builders similarly unleash their own barrage of targeted campaigns - looking to sucker en mass their victims.

To understand botnet building campaigns a little better, I've thrown up a blog on the topic over at the Damballa site - Botnet Building Campaigns.

Botnet Prevention with DLP Technologies

Last week I was asked a couple of times how good Data Leakage Prevention (DLP) products are at protecting against botnets. Before I get started describing the pro's and con's of DLP in combating professional botnet operations, there are a few things I probably need to make clear - as it'll help add some perspective to the angle I'm coming from.

As you probably already know, I spent a fair amount of time developing and improving Intrusion Prevention System (IPS) technologies in my tenure with ISS (and then later, under IBM). During that time there were a number of market dynamics that required me to spend quite a bit of time reviewing, analyzing and evaluating the various DLP technologies - both at the host and then network levels. In general though, I was not impressed with the technology - and still aren't. From my perspective, DLP is a bit of a white elephant and is probably going to go down in the annuls of Security History in the chapter next to NAC. Don't get me wrong, as a concept DLP has its place, but in practice it fails to provide any compelling features that aren't (or can't be) delivered using other more common (and existing) enterprise security technologies.

Now, being a networking kind of guy, the thing I find most interesting about network-based DLP is the show and dance the various DLP vendors make about Deep Packet Inspection (DPI) - you'd almost think that they invented the technology and that it only to DLP. Lets get this straight from the beginning - DPI existed within IPS (and IDS) for 5+ years before even the first DLP companies became incorporated and, whats more, products like ISS' Proventia fully parse many hundreds of networking and content-level protocols - many times more than even the most mature dedicated DLP product out there.

So, if you're thinking DLP is a new and vital technology to roll out in your enterprise (particularly at the network layer), my advice would be to look to a top-tier IPS appliance instead because you'll find better protocol and content inspection coverage, and higher capabilities in inspecting traffic for critical data leakage. One day I'd love to see a head-to-head appliance review of the various vendors products detecting and defending against all the most common data leakage techniques/tactics.

DLP and Botnets
So, how useful is DLP in combating botnets? 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 leverage 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 - and 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 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.
  

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.
• 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
Well, I can't think of anything that DLP offers in this realm.

Clobbering Botnets with DLP
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.

In fact, as far as I'm concerned, I can't really see a reason for it existing as a separate security technology anyway. Existing IPS technologies and signatures include just about all of the data leakage detection features already.

That all said, DLP is probably adequate enough for detecting stupid user mistakes, but useless for combating professional criminals - whether they're botnet operators or insider threats.

Network ADS - Playing at Botnet Detection

With botnets and more recently APT's plastered across the news, you'll struggle to find a security vendor that hasn't spent a furious couple of weeks repositioning their preemptive detection technologies as "anti-botnet" or "anti-APT".

Needless to say, digging a little deeper in to these technologies - beyond their cursory marketing spin - is probably a good idea, especially if your company executives are thrashing about looking to take any steps that'll keep them from being the next Google-like victim and making headline news.

Yesterday I pulled together my thoughts on the use of network-based Anomaly Detection Systems (ADS) in their capacity as botnet detection tools. In a nutshell, NADS is fine for dealing with those big and noisy Internet botnets that everyone writes about in the news, but not much chop against the types of botnets normally found successfully operating within enterprise networks.

My thoughts and analysis can be found on the Damballa blog - Detecting Botnets with Network ADS - and is also cross-posted below...

-------

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.

Tethered Espionage

News of corporate espionage amongst the Fortune-100 - with targets like Google and Adobe - has been breaking all day. It's interesting to note the thoughts of the different commentators and their take on the China slant.

Earlier today I blogged (rather extensively) on my take of the news. You can find those comments posted here - Corporate Espionage and Tethered Criminal Actions - and copied below...

--------------------

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.

Database of DIY Trojans and Bots

What does it take to search, locate and acquire free copies of the current generation of Trojan and Bot DIY construction kits? Practically nothing nowadays.

I noticed that its actually getting even easier to get your hands on these kinds of nefarious technologies this morning with the public availability of an online database from the folks over at Indetectables.
This new DIY Trojan and Bot database is currently online and serving up multiple public versions of the popular kits - such as Bifrost and Poison - along with a growing selection of plugin's for them. For example, if you're a Poison Trojan developer, the site hosts multiple versions ranging from 0.0 through to 3.2, along with the "free" plugins - such as "Firefox password recovery", WiFi scanning, host power controls and remote port scanning (to name a few).

If you're thinking of downloading the DIY kits and using them, remember the following:
1) Using them against a system you're unauthorized to access is illegal in most countries.
2) The probability that the DIY kits and/or the malware agents they create are backdoored is typically very high.
3) Your traffic to this database (and other similar sites) is logged, and those logs may be requested by legal authorities in the future.

The Botnet Helpdesk

So, you're planning on building your own botnet and despite all the how-to videos on YouTube you're still having problems building your botnet malware agent and getting your command & control to work like the videos said ti would. What do you do? Well, if you purchased your DIY botnet creation kit from one of several "commercial" botnet providers, you'd contact their help-desk.

I kid you not. Several crimeware service providers go beyond 24x7 IRC and email support - now offering full online help-desks; complete with ticketing systems for tracking your "incident" and live virtual advisers.

For a full analysis of one of these botnet service providers - check out my latest blog entry over on the Damballa site - The Botnet Distribution and Helpdesk Services.

Enterprise Botnets - Targeted or What?

Whats the difference between these massive botnets gobbling up sizable chunks of the Internet and those found inside the enterprise? Quite a bit actually.

Over the last couple of months I’ve been talking at a number of conferences and speaking with customers about the kinds of botnets we observe within enterprise networks as opposed to whats generally seen propagating the Internet at large. As you’d expect, there are a number of differences – partly because of the types of bad actors targeting businesses, and partly because enterprise perimeter security is considerably more advanced than that found at the end of the average DSL Internet connection.

From a cross-network visibility perspective, the types of botnets regularly encountered operating within enterprises in 2009 can best be divided (and described) as follows:

Internet Targeted – or “broad-spectrum” attack for want of a better description – account for approximately half of all botnets regularly encountered inside enterprise networks. These botnets aren’t targeted at any particular network – just at the average Internet user – but they typically manage to infiltrate enterprise networks due to lax security policies and as bleed-over from the other networks (and devices) employees may connect to. I discussed some of this in the earlier blog – Botnet bleed-over in to the enterprise – in which botnets designed to steal online gaming authentication credentials often appear within the enterprise. Just about all of these broad-spectrum botnets can self-propagate using an assortment of built-in worming capabilities. Fortunately, just about every one of these botnets are easily detected with standard host-based antivirus products.

What this means in practice however is that hosts “not quite” adhering to the corporate security policy, or which are a little behind in apply the latest patches (including not running the very latest signatures for their antivirus package), are the first to fall victim – and no organization I’ve observed in the last 20 years has ever managed implement their security uniformly throughout the entire enterprise.

I foresee that these “broad-spectrum” botnets will continue to appear within enterprises and be a nuisance to enterprise security teams. That said though, just because they aren’t targeted and fixes are available, it doesn’t mean that there’s no threat. If a particular botnet agent doesn’t yield value to its original botnet master (e.g. a botnet focused on obtaining passwords for social networking sites), it is quickly passed on to other operators that can make money from it – repurposing the compromised host and installing new malware agents that will yield value to the new owner.

Enterprise Targeted botnets are botnets that are hardly ever found circulating the Internet, and are designed to both penetrate and propagate within enterprise networks alone. Around 35% of botnets encountered within enterprise networks are this type. They are typically based upon sophisticated multi-purpose Remote Access Trojans (RAT); often blended with worming functions capable of using exploits against standard network services (services that are typically blocked by perimeter firewal technologies). Perhaps the most visible identifier of a botnet targeted at enterprises is the native support for network proxies – i.e. they’re proxy-aware – and capable of leveraging the users credentials for navigating command and control (CnC) out of the network.

In general, these “targeted” botnets aren’t targeted at a specific organization, but at a particular industry (i.e. online retail companies) or category of personnel within the organization (e.g. the CFO).The botnet agents tend to more advanced (on average) than most botnet malware encountered within enterprise networks – offering greater flexibility for the botnet masters to navigate the network and compromise key assets, and to be able to extract any valuable information they manage to obtain.

Deep Knowledge botnets are a completely different beast. Accounting for 10% of the botnets encountered within typical enterprise networks, these botnets tend to rely upon off-the-shelf malware components (more often than not, being built from commercial DIY malware creator kits). Depending upon the investment made by the botnet master, the features of the botnet agent can be very sophisticated or run-of-the-mill. What makes them so dangerous though is that the creator (who is often the botnet master) has a high degree of knowledge about the infiltrated enterprise – and already knows where to find all the valuable information. In some cases specific people or systems are targeted as beachheads in to the organization, while in others key organization-specific credentials are used to navigate the network.

Where this “deep knowledge” comes from can vary considerably. Each botnet within this category tends to be unique. I’ve come to associate these botnets with past or present employees (rather than industrial espionage) – as it’s not uncommon to be able to associate the CnC server of the botnet to a DSL or cable Internet IP address in the same city as the office or building that has been breached. In some cases I wouldn’t be surprised if the installation of these botnet agents were conducted by hand as a means of (semi)legitimate remote administration (think back to the problem in the mid-1990’s when people were installing modems in to their work computers so they could access them remotely). The problem though is that most of these commercial DIY malware construction kits have been backdoored by their creators (or “partners” in their distribution channel) – which means that any corporate assets infected with the botnet agent will find themselves under the control of multiple remote users.

“Other” represents the catch-all for remaining 5% of botnets encountered within enterprise networks. These botnets (and the malware they rely upon) vary considerably in both sophistication and functionality, and don’t fit neatly in to any of the previous three categories. They include the small botnets targeted at an organization for competitive advantage, through to what can only be guessed at as being state-sponsored tools targeting specific industries and technologies.

It’ll be interesting to see how the distribution of these four categories of botnets change in 2010. I suspect that the proportions will remain roughly the same – with the “other” category decreasing over time, and being largely absorbed in to the “Enterprise Targeted” category rather than “Deep Knowledge”.

==> Reposted from http://blog.damballa.com/

Software Piracy and Host Compromise

This last week has seen quite a bit of public discussion concerning the effect of software piracy on compromise rates, based upon Monday's release of a report titled "Software Piracy on the Internet: A Threat To Your Security"by the Business Software Alliance (BSA) - pages 6-12 are definitely worth a read (the rest is a little too self-serving of the BSA).

I don't believe the report actually holds any surprises for most security professionals, but it's always handy to have some independent (and current) validation.

I can remember back to the old 1980's BBS days where piracy was just as rampant with online games and even the base BBS software being backdoored by folks looking to make a quick buck through their leeched warez. The only thing that has changed has been the channels for distribution.

In the past I've conducted a number of studies related to pirate distribution channels - looking at both the exploits and malware being embedded in the content. For example, back in 2001-2002 when image file exploits were all the rage (e.g. JPEG/PNG/GIF/etc. file parsing vulnerabilities) I set up an experiment to analyze the content of several popular binary newsgroup channels (ranging from some of the heavily trafficked porn groups through to celebrity and disney image groups) and found that upwards of 5% of the copyrighted images being distributed contained exploit material (one popular vector was for the bad actors behind the attacks to respond to Repost Requests and Fills for missing images of popular collections).

A couple of years ago I repeated part of the experiment - but instead focusing on binary files (mostly games, Windows applications and keygens) and found almost two-thirds of the newsgroup content was backdoored with malware. I'm pretty sure that if I was to run the experiment again today I'd find the malicious file percentage to be higher. And thats just the newsgroup distribution channel. The P2P networks tend to be worse because its so much easier for others (potential victims) to stumble upon a malicious version of the pirated software - largely because it's a more efficient channel for criminals to operate under and they have a greater chance of enticing their victims (i.e. using faster P2P servers, constantly monitoring what's hot in file sharing, exploiting their own reputation systems, using botnets to saturate/influence, etc.).

What does this all mean? Well, it can probably be best summed up as "you get what you pay for" in most instances. While the motivations behind the BSA releasing this specific report are pretty obvious, so too is the fact that software piracy has, and always will be, a viable vector for criminals to make money both directly and indirectly through their pirated warez - i.e. selling "discounted" software, and through the use of the botnet infected hosts of their victims.

Dancho Danchev over at ZDNet has an interesting view on the problem by taking a look at the patching perspective - which I wholeheartedly agree with too. I covered the angle of patching (specifically Web browsers) in a whitepaper mid-2008 - Understanding the Web Browser Threat - that still applies today.

Ollmann speaking at the ZISC Workshop

This week I'll be in Zurich speaking at the ETH ZISC workshop on Security in Virtualized Environments and Cloud Computing.

The title of my talk is "Not Every Cloud has a Silver Lining" - and it's meant to be a fun (but insightful) look at the biggest and baddest cloud computing environments currently in existence - the botnets.

If you happen to be in Zurich on Thursday morning, by all means, please drop by for the talk. The workshop runs Thursday to Friday.

Need more details on what I'm covering? Below is the abstract...

What’s the largest cloud computing infrastructure in existence today? I’ll give you a hint. It consists of arguably 20 million hosts distributed over more than 100 countries and your computer may actually already be part of it whether you like it or not. It’s not under any single entities control, it’s sphere of influence is unregulated, and its operators have no qualms about sharing or selling your deepest cyber secrets.

The answer is botnets. They’re the largest cloud computing infrastructure out there and they’re only getting bigger and more invasive. Their criminal operators have had well over a decade to perfect their cloud management capabilities, and there’s a lot to learn from their mastery.

This session will look at the evolution of globe-spanning botnets. How does their command and control hierarchy really work? How are malicious activities coordinated? How are botnets seeded and nurtured? And how do they make their cloud invulnerable to shutdown?

Rent a DDoS botnet

Over recent weeks there has been a lot of interest in DDoS botnets – that is to say, rentable botnets that provide DDoS as a managed service. I’ve spoken to a number of people about how easy this is to do, and how practically anyone who happens to know how to use a popular Internet search engine can probably locate the sellers or the hacking message boards they hang around. Perhaps one of the finer points missing about the discussion of renting DDoS botnets pertains to the size.

A fairly typical rate for DDoS botnet rental hovers around the $200 for 10,000 bot agents per day. The rate per day is fairly flexible, and influenced by the actual size of the botnet that the bot master is trying to section off for DDoS services and where those hosts are physically situated. For example, some DDoS providers make a virtue of allocating bots that are located within a particular country and their average Internet bandwidth. Meanwhile, you’ll find providers at the other end of the spectrum offering DDoS services at substantially lower rates. For example, here’s a DDoS botnet for rent at the moment over at Ghost Market…

As you can see from above, this particular operator is offering a botnet of between 80k and 120k hosts capable of launching DDoS attacks of 10-100Gbps – which is more than enough to take out practically any popular site on the Internet. The price for this service? $200 per 24 hours – oh, and there’s a 3 minute try-before-you-buy.

By way of another example, the following screenshot is from another botnet master offering a 12k botnet for rent – for the price of $500 per month. Screenshots like this appear to be popular as a means of validating the sellers claims of the size of their botnets – despite the fact that all of this information can be trivially forged. Notice that only a handful of bots appear to be online and currently accessible? (this ties in to what I was saying the other day about counting botnets).

There are of course plenty of other operators that work this way – offering DDoS managed services – and there’s lots of competition amongst them. What’s perhaps most amusing about this botnet market to me is the fact that so few sellers have “good” reputations – and the message boards are rife with competitors throwing mud about the quality of the service or that the “seller” is actually just running a scam on newbie buyers.

I’d encourage readers to keep an eye on these kinds of hacking portals – just make sure you only access the sites from VM/sandboxed disposable hosts since many of the sites attempt to hack your Web browser. You’ll uncover lots of information about the mainstream botnet seller/renter market and, just as importantly, details about many of the newer or popular DIY botnet creation kits out there.

--Repost from blog.damballa.com.

Opt-in Botnets and hacking from the office

An area of personal interest for me over the last couple of years has been the evolution of cyber-protesting - in particular the development of what could be best called "opt-in botnets".

While the last 12 months have seen numerous stories covering politically motivated DDoS attacks targeting government institutions and country-specific brand name multi-nationals, several aspects to the evolution of this threat have been lost in the noise.

I'm planning on writing a handful of papers and articles covering both the emergence and evolution of cyber-protesting (from a security practitioners view), and how social networking sites are a game changer for the nature and breadth of attacks we can expect over the coming years.

That said, an important aspect of this cyber-protesting threat I believe lies with the increasing acceptance of opt-in botnets. In particular, the capability of a social group to create/access customized attack tools that can be harnessed for collaborative attacks against a shared target - where the software agent is intelligently linked to a centralized command and control infrastructure - and the distributed agents can be coordinated as a single weapon. All this with the consent of their cyber-protesting supporters.

Some aspects to this botnet-based cyber-protesting have already manifested themselves - in particular the way social networking sites like Facebook were used to incentivize supporters to visit external sites and download tools that would target Hamas or Israeli government sites at the beginning of this year.

That said, and why I bring up this topic now, there was an interesting column piece on SecurityFocus yesterday by Mark Rasch - Lazy Workers May Be Deemed Hackers. Mark examines the very important issue that many corporate entities may have unintentionally exposed their employees to some pretty severe legal ramifications - i.e. potentially exposing them to criminal prosecution if they misuse their work machines. This is important in the context of opt-in botnets.

If an employee decides to install any out-in cyber-protesting software on to their work machine and allows it to launch an attack against some target, while it may be a fire-able offense (i.e. inappropriate use of corporate systems) it could also lead to criminal hacking charges. Which, as Mark's column points out, is a pretty harsh offence for the employee - but also means considerable work (and distractions) for the employer in having to be involved with law enforcement and their prosecution process, whether they want to or not.

Malware of the Day

It seems that most malware served up by cyber-criminals has a shelf-life of only 24 hours. PandaLabs said that 52% of the 37,000 virus samples they get each day will never be seen again on any other day.

I'm not surprised. Serial variant production lines have been pumping out new malware samples in industrial quantities. Back in early 2007 I released a whitepaper for IBM covering the mechanisms many of the drive-by-download sites were using to create and deploy "unique" malware samples on a per victim visit basis. I'm just glad that one of the anti-virus companies has "confessed" to the problem.

Unfortunately the problem is only going to get worse, and these "cloud-based" service proposals are probably going to provide as much protection against the real botnet threat as a real fluffy-white cloud does against a bullet.

I blogged in more detail on the topic over at the Damballa site. Half of New Viruses Only Useful to Cyber-criminals For A Single Day.

Root of all Evil Kicks off Cyber War...

It's been a ridiculous week reading the papers about the pitched battle that North Korea has kicked off against the USA and South Korea. Those juggernauts of the internet have supposedly begun a 21st century cyber war... or so some politicians would have you think. Oh, and "we" have to retaliate too.

Nature abhors a vacuum, and it looks like more that a few heads have been filled with cyber-war nonsense.

I blogged on Friday about the topic on the Damballa site (and I've reposted it below), but I forgot to mention much about the DDoS threat angle. In a nutshell, DDoS is a common occurrence across the internet. Major web sites - particularly government and international conglomerates - are constantly under DDoS attacks of some degree or other. Unfortunately it's just a fact of Internet life nowadays - a bit like Spam taking up 80+ percent of email traffic.

What about the major sites that got hit and became unoperational? Unfortunately, this too is an ongoing problem. As the bandwidth to home internet users increase, the number of hijacked connections needed to take out big corporate Internet pipes gets lower and lower. While it's true that the sites under attack can work on mitigation strategies to prevent (or more likely reduce) the outages due to DDoS - they are increasingly reliant upon upstream ISP's to do the real work in preventing the attack. The strength of their relationship, is evident in the speed to responding to DDoS attacks.

Lets face it though - if only 10% of the worlds computers outside of the US decided to initiate a coordinated DDoS attack against any site or organization in the USA, that site will be toast. Volume trumps network security magic.

Reposting -

North Korea Kicks-off DDoS Cyber War?

For all the headlines these last few days you’d have thought cyber-war had kicked off and we’re on the cusp of Armageddon. Depending upon which news channel you’ve been listening to or which newspapers you’ve been skimming you could have hardly missed this latest nonsense that North Korea has instigated a cyber war against the USA and South Korea. Its even got to the point that I’ve had to get on the TV myself and try to explain the situation.

As such, I spent a few minutes this afternoon on CNN International News talking about this supposed North Korean cyber-attacks – trying to correct some of the madness that the conspirators and ill-informed have been spouting.

Here’s a 20 second summary of whats been happening in the news:

1. On July 4th, a handful of US websites (5) came under DDoS attack from a botnet consisting of a high proportion of bot agents (i.e. victims) based within South Korea.
2. Initial estimates placed this particular botnet at about 20,000 agents.
3. Over the following days the list of targeted web sites grew to 26, with a mix of US and South Korean sites.
4. The targets were a mix of government, financial and news media Web sites – more heavily weighted towards government sites.
5. The bot agents were launching a mix of HTTP GET requests, UDP packets and ICMP ECHO requests at each listed target – repeatedly cycling through the list in a round-robin fashion. Depending upon the victim computer being used, this could represent around 100 “attacks” per second.
6. Estimates of the botnet size range from 20k through to 100k – with most public news media estimating the size to be 50-60k bot agents.
7. Some Web sites didn’t cope well with their unwanted DDoS traffic and went down for a period of time – most noticeable the FTC Web site.
8. The bot agent in use (and the samples Damballa have collected) are based upon MyDoom – a worm-based bot agent dating back to 2004.

Oh, and the biggie, 9. it seems that a number of politicians have jumped on to this DDoS and portrayed it as the first foray in to cyber-war by North Korea… we’re all doomed… and, since this is an act of war, “we” need to strike back!

So, let me try to inject some sanity in to all this madness and, in my best Scouser accent, shout “calm down, calm down!”

While a lot of the analysis is still ongoing – and likely to continue long after the public looses interest – I’ve come to the conclusion that this DDoS attack has very little to do with North Korea and only consipiritory theorists could conclude that this is a state-sponsored kick off to cyber-war. Why not?

1. The bot agents being used in this attack are ancient. They’re not stealthy, they have limited attack capabilities, they’re detectable by just about every anti-virus product out there (and have been for over half-a-decade), and it makes no sense for any professional to use them – even if they were handed over as a free-be. We’re not even talking about someone taking the cyber-equivalent of arming a few farmers with 40 year-old AK-47’s, it’s more like arming a troupe of girl-scouts with water-balloons and Nerf guns.
2. The DDoS attacks came from bot victims scattered around the globe – with perhaps the highest concentration in South Korea. As far as I’m aware, there was no noticeable collection of bot agents from North Korea. In fact it even looks like the command and control servers for this botnet weren’t even based in the region – and were most like compromised already.
3. The list of targets doesn’t make sense. Sure, a handful of the Web sites have some significance from a government perspective – but they’re only Web sites, and nothing special happens there. If you’re going to target a nations infrastructure and do cause any level of pain, “these are not the droids you are looking for”.
4. The fact that the list grew over multiple days and only leached over to include some South Korean sites latter suggests to me that the “mastermind” behind this attack is more likely to be some crazy South Korean college student who thought it would be cool to strike out at the US – then told some of his mates over the weekend what he was doing – and subsequently ended up following their advice to include some additional sites that would be “cool” to throw sticks at. Then, on the last night, they all grabbed a few beers and decided to chuck in a few local Web sites for good measure since they’re now making the news (”Hi mom!”).
5. I’d also have to conclude that the botnet operator(s) are amateurs. A DDoS attack is only successful if you throw enough traffic at a targeted Web server to overwhelm it. To take a (relatively) small botnet and to split it’s target range over multiple sites means that the per-target attack volume is going to decrease. To split the target pool amongst 26+ Web sites was going to be a wasted effort – and most likely the operator(s) have little understanding of network security and the protocols they were playing with.
   OK, so I hear you say “but some of the US Web sites went down”… yes they did, but early on in the attack. This means two things to me – (a) later on they targeted more Web sites, so the volume of DDoS traffic to the affected sites dipped after a few days, and (b) the system administrators of those Web sites managed to read the first few chapters of “Network Security for Dummies” and actioned the anti-DDoS advice they were given.
6. Why South Korea? Let me temporarily slip on my blackhat and explain it from a bad-guys perspective. Why not? I’m hardly going to launch the DDoS from computers I own or from the place I work. South Korea is known to have a top-notch Internet infrastructure – with most of the population having high-speed Internet access (higher on average that the US) – yet it’s online population typically has one of the highest infection rates of anywhere in the world. So it’s a great place to build a high-speed botnet from scratch.

OK, so for all those reasons above, I don’t think that this is a North Korean cyber-war. And I also don’t think that North Korean sympathisers have infiltrated South Korea and are masking their attack from within – as suggested by a handful of politicians (wasn’t that some Tom Clancy plot?).

My advice for those politicians and conspiracy pundits out there thinking that cyber-war is upon us by the evil North Koreans – think again. Even if you’re right and this is a state-sponsored attack, then by the nature of the attack exhibited thus far you might as well invest in some umbrellas to avoid the water balloons – rather than consider retaliatory cyber attacks.

Note: I thought the image of Worzel Gummidge was appropriate for this blog. For those unfamiliar with this 1979 TV series – it stared Jon Pertwee of Dr Who fame and his scarecrow character had to change his head whenever he needed to do some thinking…