Extracting CnC from Malware

I've been asked quite a bit about the risks and value of automatic malware analysis within the enterprise over the last few months. There are of course a lot of technologies that enterprise can purchase and deploy withing their network to take in suspicious samples and classify them as benign or malicious.

Most of these technologies use a mix of signature and behavioral engines, although there's been a greater push recently to use virtual/sandboxing technologies as well (or as a replacement). I'm not convinced this is such a smart idea. The tools being used to create new families and serial variants of malware tend to be more sophisticated nowadays that whats being used to thwart them at the perimeter network. In fact practically anyone with the ability to use Google and permissions to install software on a computer can download many of the DIY malware construction kits and start generating crimeware thats guaranteed to defeat most of these commercial VM/Sandboxing technologies - some will even enable the would-be cybercriminal to use exploits to break out of the sandbox.

Anyhow, I've pulled together a whitepaper discussing the use of such technologies in obtaining botnet command and control information - and the limitations of such technologies within the enterprise.

"Extracting CnC from Malware" is now available on the Damballa web site.

Bonet SQL Injection & Conficker

Nowadays most organizations are familiar with SQL Injection - even if only as a "critical" vulnerability that happens to get the techies hot under the collar. Most CxO's I encounter understand the significance of the threat, even if they have no idea as to it's nature.

That said, even amongst most techies, the general perception is that SQL Injection is difficult and noisy - i.e. you need to understand the database/table structures to successfully hack it, and the repeated attempts to hack/enumerate the database would quickly be detected. Which, to my mind, is a rather strange (and sorry) state of affairs if that's their argument counterpoint to investing in more advanced protection.

Regardless, the real situation concerning the threat is that both arguments (or "defenses") are flawed - particularly so when you understand how botnet-based SQL Injection attacks occur.

Many people are unfamiliar with the current state of botnet-based attacks and just how advanced they've become over the last couple of years. So, with that in mind, I wanted to chat about the state of SQL Injection attacks launched from botnets.

Older SQL Injection Bots
Mid-2008 saw a number of press alerts and media stories covering the Asprox botnet (at the time estimated to be between 200k-600k bot agents) getting updated with a new module called "msscntr32.exe" which contained a automated SQL Injection attack kit. The Asprox botnet had gained notoriety the previous year due to its robust fast-flux command and control (C&C) structure that made it an incredibly reliable spam source.

At the time, the Asprox botnet was using the SQL Injection module mainly for injecting new drive-by-download iframes into vulnerable websites - thereby helping to build a bigger botnet.

The general process for Asprox (and several subsequent copy-cat botnet engines) was:

1. Armed with a "seed" SQL vulnerability (e.g. a known page type or URL parameter structure), the attack engine queries Google for other pages that contain the key words/structures.
2. A list of potentially vulnerable pages are identified within the returned search findings.
3. A preformatted SQL Injection string is constructed, and the attack engine iterates through each search finding - sending the SQL Injection exploit to each page/host.
4. Part of the exploit string contains the content that the attacker wants to inject in to the vulnerable application database - typically an iframe containing a URL that would direct potential drive-by-download victims to a host that botnet operator has prepared specially to serve Web browser exploit material and install bot agents.
   

In general, the attacks were unsophisticated. Each bot agent was largely left to its own devices to locate and attack vulnerable Web applications, and there was no intelligent load-balancing between bot agents via the C&C - so many vulnerable sites fell victim multiple times. While unsophisticated, they were quite successful - with some botnets successfully compromising hundreds-of-thousands of vulnerable Web applications.

Botnets agents like Conficker have been regularly updated with modules capable of operating in this fashion and have been observed launching these kinds of unimaginative SQL Injection attacks. Check your HTTP Web logs for User-Agent strings such as "NV32ts" to see if someone's pointed the botnet at your Web application.

Newer SQL Injection Bots
As is so typical in botnet development, "cool" features mature and morph really quickly. While the first Asprox botnets (and their clones) operated more akin to Zombie agents than bot agents, their botnet operators quickly added better centralized control of the SQL Injection mass attacks.

The SQL Injection attacks conducted by the more advanced bot agents (or downloaded malware) make better use of scripting engines and consequently are much more versatile attack platforms. A limitation of early generation bot SQL Injection resulted in the same vulnerable Web applications being hit multiple times by the same botnet - better scripting language use and more coordinated CnC overcomes this.

Consider the newer twist on the attack...

1. The bot master conducts a Google search for Web applications/sites potentially vulnerable to a new SQL Injection vulnerability. Typically this would be done via an open proxy or sacrificial bot agent so that the CnC doesn't give away it's position.
2. The bot master divides the list of potentially vulnerable sites in to batches (of the order 10-20 hosts) and allocates the sub-list to a particular bot agent along with the specific attack string.
3. The bot agent itterates its way through the batch it was given and reports its status/success to the CnC server - whereupon it is given a new batch to attack.

In this model, there is no duplication of effort and the botnet operator can change the dynamics of the attack (and iframe details) at anystage.

Blind SQL Injection
Given the pace of evolution its probable that the threat is already evolving to include blind SQL Injection tooling as well. With blind SQLi, the resultant enumeration or alteration of the backend database are not visible directly from the page's content - and the attack must effectively "brute force" it's way through an enumeration process.

The tools to conduct this class of attack have been available for a couple of years within the pentesting community - however, beyond proof-of-concept, they've never really amounted to much because it's a time consuming attack. However, given the capability to batch attack processes to distributed bot agents and improvements in CnC management systems it's now become much more feasible for criminals to launch blind SQL Injection attacks against vulnerable sites.

I haven't been asked to investigate any notable database hacks for a while now so I've not seen evidence of botnets bening used in this way to date - but from following discussions on various underground boards, the potential for attack hasn't been lost on the bad guys, so it's only a matter of time (if not already happening).

For the timebeing though, the bad guys will probably persist with single string SQL Injection attacks (i.e. send GET/POST a single string of SQL Injection commands to a server with an embedded iframe) rather than more sophisticated enumeration and data egress attacks - mainly because it's easier and there's still money to be had that way. However, I'd expect some of the more cutting edge botnet operators to up their game and pursue the data theft route in the later stages of the year - mainly because it's becoming more profitable and they've almost perfected their systems.

Bot Counting via Hijacked C&C Portals

So, the question is "can you accurately size a botnet by hijacking the Web C&C portal and counting the bot agents under management?"

The obvious answer should be "yes", but I'm sorry to say that the answer is almost certainly "not really". Not meaning to rain on Finjan's parade, but just because a C&C portal has a 'total' figure - doesn't mean that's how big the botnet actually is.

Original response is over on the Damballa site... "Caution Over Counting Numbers in C&C Portals"...

C&C Portal Counting

It’s always a struggle to get definitive information about the size of the global botnet infestation. The typical way in which security researchers build the big picture is either through extrapolation of an existing dataset (e.g. there are 1,000 infections within this class-A, therefore there are probably 250,000 infections globally) or through the summation of confirmed reports.

The former method has always struck me as fraught with uncertainty, and I wouldn’t even consider it a reliable estimating method since there are way too many factors at work. The later method tends to underestimate the global number – but is a more accurate reflection of what we know.

So, it was with interest I read today’s blog by Finjan - How a cybergang operates a network of 1.9 million infected computers – which details their investigation of a Web-based C&C platform that they stumbled upon which appears to have been managing a little over 1.9 million bot agents. It’s an interesting walk through of what they found (and well worth the read), however I think it’s important that followers of these kinds of numbers (and supporting evidence) keep a critical eye open.

Some things to bear in mind with these kinds of notable finds:

1. The absolute number quoted within these C&C portals doesn’t necessarily mean that there were (or are) as many bot agents out there.
   a. Depending upon the age of the portal, the number is probably an aggregate of all the infected hosts over time. Some hosts may have been infected and then remediated or just “lost” by the botnet herder.
   b. Just like the way in which new companies tend to start their invoices with a number other that one (e.g. start with 10000) so that their first customers don’t realize that they are so small/new, botnet herders aren’t just as inclined to start at a higher number – after all, a big number looks cool.
   c. In the majority of cases the counter increments upon the addition of a new infected host. In many cases each reinfection of an infected host (e.g. the user falls victim to the same drive-by-download attack) overwrites the malware that was first installed and creates a fresh registration to the C&C server.
   d. DHCP – an oldie, but a goodie – means that an infected host will be assigned different IP addresses (and host names if they’re subscribers of a mainstream ISP), which means that the same host can (typically) get counted each time it connects to the C&C from a different address. In conjunction with that, “new” infections that happen to reuse an older infected IP address registration may not get counted at all.
2. A basic business model has developed over the last 18 months revolving around building large botnets as fast as possible, inventorying them for low-hanging-fruit authentication credentials and network-orientated configuration info (e.g. speed of network connection, VPN, NAT and enterprise network settings), and then carving them up for sale to other botnet operators. As such, the carved off botnet subsets (often sold in the realm of $50-400 per thousand hosts) may be removed from the C&C portal. I say “may” because the large botnet herder may not bother removing them from the count (It’s only a counter after all), or that he still keeps a backdoor open to bots that have already been sold off.
3. In most cases, to gain access to the C&C portal, you need to supply login credentials. Depending upon which country you happen to be living, accessing the C&C portal without permission may constitute a legal offense – and be subject to jail time. Just because the bad-guys were operating a botnet doesn’t mean that the good guys are allowed to break in to their systems – sorry, but it’s true whether we like it or not. Some may argue that the good-guys are just breaking in to a system owned by the bad-guys, so that’s fair game. Unfortunately, theres no guarantee that the C&C server is actually running on a host that the bad-guys own – in fact there’s a higher probability that it’s running on a server they’ve p0wned (i.e. it’s another victims computer). Therefore, by proceeding with an unauthorized access to the previously-compromised computer, the good-guys could be prosecuted by the real owner of the system… and things can get really ugly of that host also has important/confidential files on it belonging to the host owner.

One last observation about this type of botnet C&C discussion - you’ll note that there are multiple malware samples associated with the botnet. This is a common modus operandi as botnet herders use their C&C channel to force down new malware packages to be installed – often from various organized cyber-crime malware distribution gangs – for a fee (this is part of the money making process) – and the infected host may subsequently be remotely controllable by a whole bundle of different botnet operators. As a consequence of this multiple-install process, the infected host is effectively “sub-leased” my multiple tenants – and disagreements can often result in mini-battles as the various botnet herders try to wrestle ultimate control of the host away from the other operators. There’s no trust amongst criminals.