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

A cynic’s view of 2015 security predictions (first part)

Better late than never, but the first of a series of blogs from me covering my ever cynical view of security predictions has now been posted to the NCC Group website.

Check out https://www.nccgroup.com/en/blog/2015/01/a-cynics-view-of-2015-security-predictions-part-one/ today. And more to come later this week.

I think yo'll enjoy it ;-)

Consumer Antivirus Blogs

OK, I give up, what's up with all the blog sites run by the antivirus vendors - in particular the consumer-level antivirus products? Every day the post essentially the same damned blog entries. What is the purpose of those blogs?

You know the blogs I mean. Day-in, day-out, 20+ antivirus companies post the same mind-numbing blog entries covering their dissection of their latest "interesting" piece of malware or phishing campaign. The names of the malware change, but it's the same blow-by-blow step through of another boring piece of malware, with the same dire warnings that you need new detection signatures and offering up the same recommendations readers should follow to protect themselves.

I guess my question is "after a decade producing essentially the same blogs each day, who the hell do they think they're writing these blogs for?" I'm pretty damned sure that the end user isn't reading them the day they're churned out. I'm guessing that a couple hundred die-hard information security folks around the world have configured their RSS readers to download each day's worth of posting - but I'm pretty sure that all but a tiny fraction of those guys actually read more than a handful of the entries on any day.

I suspect that most of the blog entries are merely mandated responses to some marketing initiative to generate new content for the websites and help maintain a certain SEO presence. The content doesn't really matter. It's not like real people are using the data in a meaningful way... its for the machines.

I sometimes wonder if half the malware or phishing blog entries are completely made up. They may as well be generated by an automated routine for all the value they contribute to the community - let alone the actions they initiate for the end users of the vendors products.

I'm sure some marketing weenie or sub-junior malware analyst is prepared to justify the 2 hour investment in writing and posting the blog... and how someday someone will search for that particular piece of malware and the details will be online surrounded with their branded material and links back to the download page for the product... but come on, is the effort worth it? The antivirus vendor blogs would be a thousand times more interesting if the posted a photo of Grumpy Cat every day... it could even be the same photo every day...

Can we stop this farce, this joke, this waste of time that is the daily postings of yet another totally uninteresting piece of malware or phishing email and stop pretending it's news?

Trend Micro - You're doing it wrong!

In my Monday morning blog catch-up I stumbled upon Trend Micro's blog "Big Data Analytics and the Smart Protection Network". I don't normally bother reading or commenting on such self-serving marketing crud, but I worry that Trend Micro may starting to believe their own marketing fluff.

There are a number of things that are worth commenting upon, but the following is more dire than many...

"Every day, we receive 430,000 files for analysis, of which 200,000 are unique. That results in 60,000 new signatures for detection every day."

Trend Micro - you're doing it wrong! Who in their right mind still pumps out 60,000 new signatures for yesterdays malware? The fact that any vendor is forced to write signatures for each new threat is obviously a depressing aspect of the whole legacy approach to antivirus. There are considerably smarter ways in dealing with this class of threat. From my own past observations those 200,000 unique samples are more than likely serial variants of only a handful of meaningful malware creations. A ratio of 200:1 or 500:1 is pretty common nowadays - and even then more modern "signature" approaches could shrink the ratio down to between 4000:1 or 10,000:1 by the time you start interpreting the code contained within the malicious binary.

Why is all this important? Firstly, perhaps it's my German heritage, but inefficiencies can be grating. Just because you're been pumping out the same crud the same way for decades, doesn't mean you can't learn something from the younger dogs at the park. Secondly, these 1:1 transformations of signature to unique malware sample are redundant against the current state of the threat. The bad guys can generate a unique malware variant for every single visitor every time they get infected or receive an update. Thirdly, the signature you're pushing out is redundant - it's a marketing number, not a protection number, it wouldn't even serve as a SPF number on a bottle of sunscreen. Finally (and it's only "finally" because I've got a day job and I could go on and on...), "200,000 are unique" - I think you've missed more than a few...

"Thanks to our leadership in the reputation and correlation area, we get many requests from law enforcement to help them identify and jail criminals."

I suppose blind self-promotion works best if evidence is contrary. I'm sorry, but there's a lot more to reputation than blacklisting URL's and whitelisting "good" applications nowadays - and there's an ample list of companies specializing in reputation services that do this particular approach much better. The problem with these (again) legacy blacklist approaches is that the threat has moved on and the criminals have been able to ignore these dilapidated technologies for a half-decade. Server-side domain generation algorithms (DGA), one-time URL's, machine-locked malware, Geoip restrictions, blacklisting of security vendor probing infrastructure, etc. are just a sampling of tools and strategies that the bad guys have brought to bare against this legacy framework of reputation blacklists and correlation.

Don't get me wrong, the data you're gathering is useful for law enforcement. It can be helpful in identifying when the criminals screw up or when a newbie comes on to the scene, and it can be useful in showing how much damage has been done in the past by the bad guys - it's just not too effective against preemptively stopping the threat.

Speaking of the data, I'd love to know who's buying that data from Trend Micro? From past experience I know that most governments around the world pay a pretty penny for knowing precisely what foreign citizens are browsing on their computers, what type of Web browser they're using and what's the current patch level of their operating system... it's traditionally useful for all kinds of spying and espionage but, more importantly nowadays, for modeling and optimizing various cyber-warfare campaign scenarios.

DGA-based Botnet Detection

There are essentially two types of magic in the world – those that deceive an audience in to believing something impossible has occurred, and that which is best defined by Arthur C. Clarke as “any sufficiently advanced technology is indistinguishable from magic”.

The antivirus industry is rife with the former – there’s no shortage of smoke and mirror explanations when it comes to double-talking “dynamically generated signature signature-less engines” and “zero false-positive anomaly detection systems”.

I’m going to introduce you to the later kind of magic. Technological approaches so different from traditional approaches that, for many folks out there in Internet-land, it’s indistinguishable from magic. More than that though, I’m going to try to explain how such techniques are reversing the way in which threat discovery has occurred in the past. However what I’m not going to do is to even try to explain a fraction of the math and analytics that lies behind that magic – at least not in a blog!
Oh where, oh where should we start?

Let’s begin, for arguments sake, by classifying malware as a tool; a weapon to be more precise. In the physical world it would be easy to associate “malware” with the bullets from a gun, and the gun in turn likened to perhaps a drive-by download site or a phishing email. In response to that particular physical threat, there are a number of technological approaches that have been deployed in order to counter the threat – we have metal detectors and x-ray machines to alert us to the presence of guns, sniffing technologies to identify the presence of explosive materials, CCTV and behavioral analysis systems to identify the suspects who may be hiding the gun.

A fundamental premise of this layered detection approach is that we’ve encountered the threat in the past and already classified it as bad – i.e. as a “weapon”. Gun equals bad, knife equals bad, metal corkscrew equals bad, and so on. Meanwhile everything else is assumed to be good – like an ostrich egg – until it happens to be used as a weapon (such as when “Russell pleaded guilty to assault using an ostrich egg as a weapon, assault, and breaching a protection order“) and inevitably some new detection technique is proposed to detect it.

Traditionally the focus has been on “preventing” the threat. In particular, detecting the presence of a known threat and stopping it from reaching its target. In the physical world, in general, the detection technologies are pretty robust – however (and it’s a big “however”), the assumption is that the technology needed to provide this prevention capability is ubiquitous, deployed everywhere it could potentially be needed, and that it works every time. Sure, at high value targets (such as airports) you’ll find such technology employing its optimal capability, elsewhere though (such as the doorway into your home) it’ll not be encountered. There are obvious parallels with the cyber-world here – except arguably the Internet-equivalent technologies are a little more ubiquitous, but considerably less capable in preventing the malware threat.

For the mob hitman, serial killer, or other kind of mass murderer, the threat of sparsely deployed metal detectors is an easily avoided problem. Subversion or avoidance of the detection systems is pretty easy and, more importantly, an appropriate choice of location negates the problem entirely. Even then, such a detection strategy, operated in isolation, isn’t a serious inhibitor for new murders. If such a technology exists to only detect the guns and bullets, but is not capable of providing attribution (e.g. this gun was used in 16 different murders over the last 2 weeks and the owner of this gun is the murderer), then the criminal only ever loses a tool each time they get caught – since the prevention technology is divorced from association with the victims (past or prospective).

But there’s an entirely different side to dealing with that kind of threat – and that’s the forensics element. While our not-so-friendly murderer can avoid the detection technologies, they’re much less capable of avoiding the evidence of violent past actions. Starting from the first murder, it is possible to build a case that points to a specific criminal by analyzing the components of the crime scene(s).
I know, the argument is that everything should be done to prevent the crime in the first place. That’s clearly very difficult in the physical world, but you’re basically living in a fantasy land of Goblins and Unicorns if you’re expecting it to work better in the cyber-world.

Which basically brings me to the discussion (and subsequent detection) of the latest generation of sophisticated malware – malware that uses domain generation algorithms (DGA) to locate their command and control infrastructure and upload their stolen data. Malware with this capability are designed to evade all those conventional prevention technologies and, once successfully deployed within their victim populace, evade all other methods of traffic filtering and takedown processes. Even if a malware sample is accidentally captured, its DGA capabilities will go undetected.
Detecting DGA-based malware is, as I implied earlier, both “magic” and a reversal of conventional prevention approaches. In order to detect DGA-based threats early on, you start with the victims first…

DGA-based malware use an algorithm to pick out candidate domain names in order to hunt for their prospective C&C servers. The vast majority of the domain names they’re looking for simply don’t exist. In the world of DNS, attempting to resolve a domain name that doesn’t exist will result in a “no such domain” (i.e. an NX) response from an authoritative DNS server somewhere down the line. So, in essence, DGA’s are noisy if you’re watching DNS activity – and lots of NX responses are a key feature of an infected host. Unfortunately, the average Internet-connected device typically tries to look up lots of things that don’t exist, and there’s often a lot of legitimate NX traffic which can disguise the flapping of the malware.

Assuming some kind of algorithmic basis to the domain candidates being created by the malware, you could suppose that it would be possible to develop a unique signature for them. If only it was that easy – the criminals are smarter than that. And you’re also assuming that you’ve already encountered a copy of the malware before in order to create a signature for that particular DGA-based malware.

Instead there’s a much better way – you monitor all your DNS traffic and NX responses, and you identify clusters of devices (or IP addresses) that are generating roughly similar domain name requests. This first pass will provide a hint that those devices share some kind of common ailment (without ever needing to know what the malware is or have ever encountered a sample before). In a second pass you focus upon identifying just the domain names that are structurally very similar across all the afflicted assets and classify that DGA based upon a number of features. Classifying the DGA makes it easier for attribution and uniquely tracking a new threat.

At this point you’re pretty much sure that you have a new malware outbreak and you know who all the victims are, and you can easily track the growth (or demise) of the botnet within your network. Unfortunately you’re also dealing with a brand new threat and you probably don’t have a malware sample… and that’s where an additional layer of analytics comes into play and more “magic” happens as you automatically begin to identify the domain names that are tried by the DGA-based malware that actually succeed and engage with the criminals server.

Let’s work through a simple example uncovered last week by Damballa Labs. Over the weekend one of our NX monitoring tools identified a few thousand IP addresses within our customer base that were generating clusters of NX DNS traffic very similar to the following:

9ftor9srimbna-q.com, 0sso151a47nztrxld6.com, 0ubpccgkvzrnng.com, dq2yl1zxcmvko2.com, wfj-5i5p4uhq8tylhiz.com, 1sj4rh1i5l8-4tca.com, zv7dfcgtusnttpl.com, om2air5ah5lisj7.com, qmyuvaftpgve2tzwhcjr.com, fndskzqmsob5r2bzby.com, f5p2vxn7dcdkujhbguqb.com, 6q5sigkfu3fl3q.com, zpbm3emcuosopagdttxi.com , trsmw3wceik79krk5.com, qtxfmfyulnnjpxwqo.com, ikh9w-3vdmlndafja.com, udf-szhubujmuhp1jj.com, 4v8hohrphizcas.com, nhb72anz8ifdyzgckqf.com, rcu4n0lzoghuj2.com, dklfebjexiabttkwvgos.com, fjg56xwoupqpdxr.com, drxyuezdllerpd.com, t407bqgh56jbkv4ua.com, 49ubufqnjzvhct.com, n7c3qfpslcjosy-5.com, nvnzihl6krkyfo8zp.com 

While you’d be hard pressed to write a “signature” for the domain names that wouldn’t cause false positives out the wazoo, the features of the combined victim’s traffic (frequency, distribution, commonality, etc.) work fine as a way of associating them to a shared new threat.

Armed with this knowledge, it is then possible to identify similarly structured domain names that were successfully resolved by the victims that also shared timing elements or appeared to alter the flow of NX domain responses. For example, if the DGA-based malware is designed to locate a “live” C&C server, once it’s found a server it probably doesn’t need to keep on looking for more and will likely stop generating NX domain traffic for a period of time.

Based upon our observations of this particular botnet outbreak, it was possible to identify the following C&C servers being operated by the criminals:

• ###.133. ###.247 – idpd1y###-elywj.com
• ###.133. ###.247 – k7-cwubgsrqj###rb.com
• ###.133. ###.247 – omz###1k1vgrqf.com
• ###.133. ###.247 – taqwucpzj###an.com
• ###.133. ###.247 – vhrey###-ooz6ig.com
• ###.133. ###.75 – o###pp1k1vgrqf.com
• ###.133. ###.75 – rm6dol7###cxje-ajl.com
• ###.133. ###.191 – id###yzib-e###j.com
• ###.133. ###.191 – k7-c###gsrqjebzrb.com
• ###.133. ###.191 – ###gpp1k1vgrqf.com
• ###.133. ###.191 – rm6dol###wcxje-ajl.com
• ###.133. ###.191 – taqwucpzj###an.com
• ###.133. ###.191 – vhreyveh-ooz###.com

[NOTE: We've temporarily obfuscated some of this data while we continue to investigate and enumerate the global pool of victims. We'll release the technical details of this particular DGA-based botnet soon…]


So, by this point we know who the victims are, how many C&C servers the criminals are operating, what their IP addresses are and, subsequently, which hosting facilities they are operating from:

• AS13237 LAMBDANET-AS Lambdanet Communications Deutschland GmbH

What about the malware piece? While we know who the victims are, it would be nice to know more about the tool that the criminals behind this botnet prefer and ideally to get to know them more “personally” – if you know what I mean…

As it happens, there are some malware samples that have been discovered in the very recent past that also like to contact C&C’s running upon the same hosts at this facility. For example:

• d977ebff137fa97424740554595b9###

Fortunately, while the malware sample wasn’t detected by any antivirus products, it had previously been automatically executed within our dynamic analysis environment and we’d already extracted all of its observable network features, including an additional (successful) C&C engagement:

• m8###ecc9lsnks6kbcrv7.com using ###.133. ###.75, ###.133. ###.191, and ###.23. ###.139

This, in turn, helped identify the following additional hosting facility based in the Netherlands:

• AS49981 WORLDSTREAM WorldStream

There’s obviously much more to this particular threat, and if you’d like to get involved digging into it and helping with the attribution please let me know…

But, getting back on track, this approach in identifying brand new threats – while sounding like magic to many – works really well! We’ve found it to be immensely scalable and fantastically accurate.

However, there’s one fly in the ointment (as it were)… the approach identifies new threats long before the malware component is typically uncovered by the security community and is independent of the the vector used to infect the victims,the malware tool that was deployed and ultimately the actual endpoint device type.

Think of it this way. Based upon the forensics of the blood splattered bodies and evidence left in the room that the murderer left behind, we know that the victims were bludgeoned to death with an ovoid object approximately 6 inches in diameter, weighing 3 pounds and composed of a calcium shell. We also know that the murderer was 5 foot 11 inches, weighed 240 pounds and wears size 11 Reeboks.

You can keep your metal detectors for all the good that’ll do in this case…

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.

Computer Herpes

The other day I came across a rather nice dissection of the HerpesNet malware agent (sometimes referred to as Mal/HerpBot-B) – carried out by the crew at malware.lu. Apart of the rather interesting name given to the malware and an associated remote C&C panel, there’s nothing particularly special about the functionality of the bot agent – it offers all the malicious features you’d expect the criminals to want.

What makes the malware.lu dissection so interesting is the enumeration of remotely exploitable vulnerabilities within the C&C tasked with controlling all the botnet victims. This in itself isn’t unexpected – since the majority of malware authors are pretty poor coders – priding themselves on the features they include rather than the integrity and security of their coding practices. In fact, bug hunting malware and botnet C&C has practically become its own commercial business – as many boutique security firms now reverse engineer the bad guy’s tools and sell the uncovered remotely exploitable flaws they find to various law enforcement and government intelligence agencies.

The 80kb crimeware agent for this small botnet (7000-8000 victims) attempts some level of obfuscation by encoding its control strings with 00406FC0h – revealing the following command related domains and URLs:

• http://dd.zeroxcode.net/herpnet/
• http://www.zeroxcode.net/herpnet/
• http://frk7.mine.nu/herpnet/
• ftp.zeroxcode.net
• upload@zeroxcode.net

Armed with information about the location of the C&C server and the method of communication (HTTP POST commands) the crew at malware.lu performed a free security assessment of the www.zerocode.net server and uncovered a number of remotely exploitable SQL vulnerabilities which not only allowed them to enumerate the entire content of the botnet’s data (e.g. victim data) storage area, but to also uncover the criminals passwords for the server. Armed with that information, malwware.lu proceeded to gain full interactive control of the host – including the C&C management console for the botnet.

As is so typical for small “starter” botnets such as this, their criminal overlords tend to make a number of critical mistakes – such as using the server for other non-botnet-related tasks and infecting themselves with their crimeware agent and forgetting to remove their own stolen data from the C&C database. Easily half of the botnet’s C&C servers encountered by Damballa Labs contain key identifying information about the servers criminal overlord due to them testing their malware agents on themselves and forgetting to remove that data from the database. As you’ve already guessed, this Herpes botnet mastermind was no different… Say hello to “frk7″, aka “Francesco Pompo”.


Image courtesy of malware.lu.


I’m guessing life has suddenly become much more complicated for Francesco. His botnet has been hijacked, all of his aliases and online identities have been enumerated, both he and his girlfriend have had their personal photos accessed and plastered over the Internet, and his passwords to his accounts have been disclosed. I think his Twitter account has now been suspended too.

As someone who’s come from a penetration testing and vulnerability discovery background, it’s amusing to me how the malware.lu hack proceeded. There’s nothing groundbreaking in what they did – they followed a standard methodology that dates back a decade to the early editions of the Hacking Exposed books – tactics and methods many professionals use on a routine basis, with one exception… somehow I doubt that poor Francesco gave his permission for this unscheduled evaluation of his server. I’m hoping that the countries in which malware.lu crew members live are a little more flexible on their anti-hacking laws than they are in any of the countries I’ve lived in over the years. I suspect that while I’d get a pat on the shoulder with one hand if I was to have done this, I’d also be getting adorned with some unflattering steel bracelets and whisked off to a cold room with little in the way of scenery or comfort.

Analysis of the Flame, Flamer, sKyWIper Malware

The world is abuzz this week with some flaming malware – well “Flame” is the family name if you want to be precise. The malware package itself is considerably larger than what you’ll typically bump into on average, but the interest it is garnering with the media and antivirus vendors has more to do with the kinds of victims that have sprung up – victims mostly in the Middle East, including Iran – and a couple of vendors claiming the malware as being related to Stuxnet and Duku.

A technical report on sKyWIper was released by the Laboratory of Cryptography and Systems Security (CrySys Lab) over at the Budapest University of Technology and Economics yesterday covering their analysis of the malware – discovered earlier in May 2012 – and they also drew the conclusion that this threat is related (if not identical) to the malware described by the Iran National CERT (MAHER) – referred to as Flamer. Meanwhile, Kaspersky released some of their own analysis of “Flame” on Monday and created a FAQ based upon their interpretation of the malware’s functionality and motivations.

There is of course some debate starting about the first detection of Flamer. Given the malware’s size and number of constituent components it shouldn’t be surprising to hear that some pieces of it may have been detected as far back as March 1st 2010 – such as the file “~ZFF042.TMP” (also seen as MSSECMGR.OCX and 07568402.TMP) – analyzed by Webroot and attributed to a system in Iran.
While it’s practically a certainty that the malware was created and infected a number of victims before it was “detected” in May, I’d caution against some of the jumps people are making related to the attribution of the threat.

Firstly, this behemoth of a malware pack is constructed of a lot of different files – many of which are not malicious; with the package including common library files (such as those necessary for handling compression and video capture) as well as the Lua virtual machine. Secondly, when you’re limited to an 8.3 file naming convention, even malicious files are likely to have name collisions – resulting in many spurious associations with past, unrelated, threats if you’re googling for relationships. And finally, why build everything from scratch? – it’s not like malware authors feel honor bound to adhere to copyright restrictions or steal code from other malware authors – nowadays we see an awful lot of code recycling and simple theft as criminals hijack the best features from one another.

As you’d expect from a bloated malware package developed by even a marginally capable hacker, there are a lot of useful features included within. It’s rare to see so many features inside a single malware sample (or family), but not exceptional. As Vitaly Kamluk of Kaspersky stated – “Once a system is infected, Flame begins a complex set of operations, including sniffing the network traffic, taking screenshots, recording audio conversations, intercepting the keyboard, and so on,” – which is more typical of an attack kit rather than a piece of malware. What do I mean by “attack kit”? Basically a collection of favorite tools and scripts used by hackers to navigate a compromised host or network. In the commercial pentesting game, the consultant will normally have a compressed file (i.e. the “attack kit”) that he can shuttle across the network and drop on any hosts he gains access to. That file contains all of the tools they’re going to need to unravel the security of the (newly) compromised host and harvest the additional information they’ll need to navigate onto the next targeted device. It’s not rocket science, but it works just fine.

I’m sure some people will be asking whether the malware does anything unique. From what I can tell (without having performed an exhaustive blow-by-blow analysis of the 20Mb malware file), the collection of files doesn’t point to anything not already seen in most common banking Trojans or everyday hacking tools. That doesn’t make it less dangerous – it merely reflects the state of malware development, where “advanced” features are standard components and can be incorporated through check-box-like selection options at compile time.

For malware of this ilk, automated propagation of infections (and infectious material) is important. Flame includes a number of them – including the commonly encountered USB-based autorun and .lnk vulnerabilities observed in malware families like Stuxnet (and just about every other piece of malware since the disclosure of the successful .lnk infection vector), and that odd print spooler vulnerability – which helps date the malware packaged. By that I mean it helps date the samples that have been recovered – as there is currently no evidence of what the malware package employed prior to these recent disclosures, or what other variants that are circulating in the wild (and not been detected by antivirus products today).

Are these exploits being used for propagation evidence that Stuxnet, Duku and Flame were created and operated by the same organization? Honestly, there’s nothing particularly tangible here to reach that conclusion. Like I said before, criminals are only too happy to steal and recycle others code – and this is incredibly common when it comes to the use of exploits. More importantly, these kinds of exploits are incorporated as updates into distributable libraries, which are then consumed by malware and penetration tool kits alike. Attack kits similar to Flame are constantly being updated with new and better tool components – which is why it will be difficult to draw out a timeline for the specific phases of the threat.

That all said, if the malware isn’t so special – and it’s a hodgepodge of various public (known) malicious components – why has it eluded antivirus products in the victim regions for so long? It would be simple to argue that these regions aren’t known for employing cutting-edge antimalware defenses and aren’t well served with local-language versions of the most capable desktop antivirus suites, but I think the answer is a little simpler than that – the actors behind this threat have successfully managed their targets and victims – keeping a low profile and not going for the masses or complex setups.

This management aspect is clearly reflected in the kill module of the malware package. For example, there seems to be a module named “browse32″ that’s designed to search for all evidence of compromise (e.g. malware components, screenshots, stolen data, breadcrumbs, etc.) and carefully remove them. While many malware families employ a cleanup capability to hide the initial infection, few include the capability of removing all evidence on the host (beyond trashing the entire computer). This, to my mind, is more reflective of a tool set designed for human interactive control – i.e. for targeted attacks.

Detecting Malware is Only One Step of Many

Dealing with the malware threat isn’t a Boolean problem anymore. By that I mean being able to detect (and block) a malicious binary isn’t the conclusion to the threat, but rather it’s a perspective on the status of the threat – a piece of evidence tied to the lifecycle of a breach.

Following on from yesterday’s blog covering the Antivirus Uncertainty Principle, I believe it’s important to differentiate between the ability to detect the malware binary from the actions and status of the malware in operation. Antivirus technologies are effective tools for detecting malicious binaries – either at the network layer, or through host-based file inspection – but their presence is just one indicator of a bigger problem.

For example, let’s consider the scenario of the discovery of a used syringe lying on the pavement outside your office entryway. It is relatively easy to identify a syringe from several yards away, and closer you get to it, the easier it is to determine if it has been used before – but it’ll take some effort and a degree of specialization to determine whether the syringe harbors an infectious disease.

That’s basically the role of commercial antivirus products – detecting and classifying malware samples. However, what you’re not going to be able to determine is whether anyone was accidentally stuck by the needle, or whether anyone is showing symptoms of the infectious disease it may have harbored. To answer those questions you’ll need a different, complementary, approach.

In the complex ballet of defense-in-depth protection deployment, it is critical that organizations be able to qualify and prioritize actions in the face of the barrage of alerts they receive daily. When it comes to the lifecycle of a breach and construction of an incident response plan, how do you differentiate between threats? Surely a malware detection is a malware detection, is a malware detection?

First off the bat, the detection of malware isn’t the same as the detection of an infection. The significance of a malware detection alert coming from your signature-based SMTP gateway is different from one coming from your proxy ICAP-driven malware dynamic analysis appliance, which is different again from the alert coming from the desktop antivirus solution. The ability to qualify whether the malware sample made it to the target is significant. If the malware was detected at the network-level and never made it to the host, then that’s a “gold star” for you. If you detected it at the network-level and it still made it to host, but the host-based antivirus product detected it, that’s a “bronze star”. Meanwhile, if you detected it at the network-level and didn’t get an alert from the host-based antivirus, that’s a… well, it’s not going to be a star I guess.

Regardless of what detection alerts you may have received, it’s even more important to differentiate between observing a malware binary and the identification of a subsequent infection. If the malware was unable to infect the host device, how much of a threat does it represent?

In the real world where alerts are plentiful, correlation between vendor alerts is difficult, and incident response teams are stretched to the breaking point, malware detections are merely a statistical device for executives to justify the continued spend on a particular protection technology. What really matters is how you differentiate and prioritize between all the different alerts – and move from malware detection to infection response.

Take for example a large organization that receives alerts that 100 devices within their network have encountered Zeus malware in a single day. First of all, “Zeus” is a name for several divergent families of botnet malware used by hundreds of different criminal operators around the world – and comes in a whole bunch of different flavors and capabilities, and are used by criminals in all sorts of ways. “Zeus” is a malware label – not a threat qualification. But I digress…

Let’s say that your network-based antivirus appliance detected and blocked 40 of those alertable instances (statistically signature-based antivirus solutions would probably have caught 2 of the 40, while dynamic malware analysis solutions would catch 38 of the 40). From an incident responder’s perspective there was no threat and no call to action from these 40 alerts.

That leaves 60 Zeus malware that made it to the end device. Now let’s say that 5 of those were detected by the local-host antivirus product and “removed”. Again, from an incident responder’s perspective, no harm – no foul.

Now the interesting part – what if you could differentiate between the other 55 Zeus malware installations? How does that affect things?

If we assume you’ve deployed an advanced threat detection system that manages to combine the features of malware binary detection and real-time network traffic analysis with counterintelligence on the criminals behind the threat, you could also identify the following communications:

1. 5 of the infected devices are attempting to locate the command and control (C&C) infrastructure of a botnet that was shut down ten months ago. While the Zeus malware may be caching stolen credentials and data on the victim’s device, it cannot ever pass them to the criminals.
2. 20 of the infected devices are attempting to reach old and well known criminal C&C infrastructure; however your content filtering and IPS technologies operate with blacklists that are now blocking these particular domains.
3. 8 of the Zeus installations are old and not “proxy-aware”, and are incapable of reaching the bad guys C&C while those devices are within your network.
4. 6 of the Zeus infected devices are communicating with an external C&C that has been “sinkholed” and is under the control of a security vendor somewhere. While the original criminal operators no longer have control of the botnet, the infected devices are still managing to navigate your network defenses and upload stolen data somewhere – and there’s no guarantee that the remote security vendor isn’t selling that intelligence on to someone else.
5. Of the remaining 16 Zeus infected devices that are successfully navigating your network defenses and are engaging with the remote criminals, 3 belong to a botnet operated by a criminal organization specializing in banking Trojans based in the Ukraine, 6 belong to a botnet operated by criminals that focus upon click-fraud and DNS manipulation based in the Netherlands, and 7 belong to a botnet operator that targets US-based financial sector organizations based in China.

Armed with that kind of insight, any incident responder worth his (or her) salt can easily figure out how to prioritize the next call of actions. While detecting malware is necessary, detecting infections is more important. Moreover, being able to rapidly enumerate the risk posed by an infection and prioritize a response is critical with today’s diverse and agile threat landscape.

Spotting a used syringe is one thing. It’s quite another to identify and support someone who’s been infected with the disease it contained.

Malware Uncertainty & False Positives

The antivirus industry has been trying to deal with false positive detection issues for a long, long time -and it’s not going to be fixed anytime soon. To better understand why, the physicist in me draws an analogy with Heisenberg’s Uncertainty Principle – where, in its simplest distillation, the better you know where an atom is, the less likely you’ll know it’s momentum (and vice versa) – aka the “observer effect“. In the malware detection world, the more positive you are that something is malware, the less likely you’ll catch other malware. And the reverse of that, the better you are at detecting a spectrum of malware, the less positive you will be that it is malware.

If that particular geek-flash doesn’t make sense to you, let me offer you this alternative insight then. The highest fidelity malware detection system is going to be signature based. The more exacting the signature (which optimally would be a unique hash value for a particular file), the greater the precision in detecting a particular malicious file – however, the precision of the signature means that other malicious files that don’t meet the exacting rule of the signature will slip by. On the other hand, a set of behaviors that together could label a binary file as malicious is less exacting, but able to detect a broader spectrum of malware. The price for that flexibility and increased capability of detecting bad stuff comes at the cost of an increased probability of false positive detections.

In physics there’s a variable, ℏ the reduced Planck constant – that acts a bit like the fulcrum of a teeter-totter (“seesaw” for the non-American rest-of-the-world); it’s also a fundamental constant of our universe – like the speed of light. In the antivirus world of Uncertainty Principles the fulcrum isn’t a universal constant, instead you could probably argue that it’s a function of cash. The more money you throw at the uncertainty problem, the more gravity-defying the teeter-totter would appear to become.

That may all sound a little discomforting. Yes, the more capable your antivirus detection technologies are in detecting malware, the more frequently false positives will crop up. But you should also bear in mind that, in general, the overall percentage of false positives tends to go down (if everyone is doing things properly). What does that mean in reality? If you’re rarely encountering false positives with your existing antivirus defenses, you’re almost certainly missing a whole lot of maliciousness. It would be nice to say that if you’re getting a whole lot of false positives you must, by corollary, be detecting (and stopping) a shed-load of malware — but I don’t think that’s always the case; it may be because you’re just doing it wrong. Or, as the French would say – C’est la vie.

Practical Malware Analysis - A Review

Off and on over the last few weeks I've been reading Michael Sikorski & Andrew Honig's latest book "Practical Malware Analysis".

As you'd expect given the title, the book covers the art of malware reverse engineering and analysis from a malware investigators perspective - providing extensive coverage of the techniques that need to be mastered by folks that intend to make a career of such technical work. The tome of some 766 pages can be thought of more as a text book (complete with practical labs) rather than a reference book that many other similarly themed practical malware analysis books take.

A question I have when reading books such as this is "who's going to benefit from the book?". My first impression is that this book, while covering the spectrum of analysis techniques for an increasingly diverse array of threats, is probably most applicable to those folks just starting out in their IT security careers and are still exploring what they want to grow up. I think this book would be an ideal text for a 200-level computer science course at college or university - and the included labs would sufficiently reinforce the learned material. It's likely that folks who have some working familiarity with the malware threat and have tinkered with incident response or basic malware forensics could use the book as a concise reference for malware analysis, but would end up quickly moving on to more specialized/focused books that target specific classes of threat (e.g. rootkits, packers, etc.).

Having employed and managed many malware analysts in the past for organizations such as X-Force, IBM and Damballa, my expectation is that the corpus of knowledge contained within Practical Malware Analysis would represent the first year of their career - as in by mastering the content contained in this book, the reader would likely be equivalent to a junior analyst that had learned the basic "on the job" stuff at a typical anti-virus company (identify relevant features of the malware under study and develop signatures and clean-up scripts). Anyone beyond that level will need more specific books and material.

I like the fact that there's broad spectrum of material covered in the book and that there's labs to reinforce the concepts. That said, I'd have preferred that the authors dove a little deeper in to some of the automated techniques for handling armored malware at the sacrifice of the helicopter chapters on shellcode analysis and IDA Pro.

Kelihos' Voodoo Patronage

The King is dead. Long live the King! Or, given this week’s events, should the phrase now be “Kelihos is dead. Long live Kelihos”?

It is with a little amusement and a lot of cynicism that I’ve been watching the kerfuffle relating to the latest attempt to take down the Kelihos botnet. You may remember that a similar event (“Kelihos is dead”) occurred late last year after Microsoft and Kaspersky took it on themselves to shut down the botnet known as Kelihos (or sometimes as Waledac 2.0 or Hlux). Now, like a poor sequel to a TV docu-drama, Kaspersky and a number of other security vendors have attempted to slap down control of Kelihos Season Two – meanwhile Season Three of Kelihos has just begun to air. 

 

In the most recent attempt to interrupt the business operations of the criminal entity behind the Kelihos botnet, a bunch of threat researchers have managed to usurp command and control (C&C) of the Kelihos.B crimeware package by poisoning the peer-to-peer (P2P) relationships between all of the infected devices and install a surrogate control server. It’s good technical work by all those concerned, but has also proved to be ineffective if the objective was to actually takedown the botnet.

The good guys have set up what amounts to a sinkhole for a particular configuration of the Kelihos.B crimeware – with the Kaspersky blog initially identifying some 116,000 infected devices around the world. Like I’ve said many times before, botnets reliant upon P2P for transport of C&C information and stolen data propagation are vulnerable to this kind of takeover and victim enumeration. It’s one of the reasons we don’t see P2P being used much by sophisticated criminal groups – and almost never as a vehicle for attacks that target businesses.

Having said that, takeovers of portions of P2P botnets such as this most recent Kelihos.B example worry me quite a bit – it’s a reason why Damballa doesn’t offer to do this kind of work despite having excellent real-time visibility of the threat and the victims. There are two elements of P2P botnet takeovers that cause me the most concern:

1. To usurp control of the P2P botnet you have to initially join it in some shape or fashion, and then you have to send commands (via the P2P network) to all the other infected devices and redirect them to something you control.
   A victim of the Kelihos.B crimeware would be unable to differentiate the “good guys” from the “bad guys” – after all, their computer is still under someone else’s unauthorized control – and they could justly bring a legal case against those parties that seized control of their computer.
2. The use of sinkholes for victim data harvesting. It raises all kinds of questions about how you’re using someone’s stolen data – let alone the effect of sharing that victim information with other commercial entities. Obviously I have a strong opinion as to the ethics of selling these kinds of stolen information or using it for commercial purposes.

Despite the sinkholing attempt and the cries from the highest watchtowers that the Kelihos botnet is dead, it obviously isn’t. Within the security community there’s consequently a lot of discussion already over the semantics of what constitutes a botnet and what it means to have “killed” a botnet.

For example, the criminal operators behind the Kelihos.B botnet have been rolling out a new and improved variant of their crimeware – Kalihos.C – and it’s infecting a whole bunch of new victims (with some overlap with the Kelihos.B botnet victims). The fact that a new malware variant is being distributed to an overlapping group of victims seems to cause some degree of confusion to a few people.

Based upon my own observations, I’d be more inclined to take care when differentiating between the gang that operates botnets, botnets that share the same C&C infrastructure, and campaigns of crimeware updates and their installation. The claim of taking down the Kelihos botnet (twice now) is clearly false. It would be more precise to say that certain Kelihos campaigns have been disrupted. The criminals (and their core infrastructure) haven’t been significantly affected. In fact, the speed at which the Kelihos criminal gang was able to release an updated variant (Kelihos.C) reflects the futility of much of the current takedown effort.

Why go to all this effort? Why invest in Wac-a-mole style takedowns? While the efforts to takedown some Kelihos.A and Kelihos.B P2P botnets haven’t succeeded, they have enabled researcher to better understand the nature of the threat and hone their skills in the art of takedown. Knowing what doesn’t work (and why) is almost as valuable as knowing what does work.

I’m sure some group is going to try their hand at taking down Kelihos.C (and probably Kelihos.D) based botnets in the future. There’ll probably be the same claims of “Kelihos is dead” too. Unfortunately, if the Kelihos botnet controllers want to escape this bothersome cycle of losing a few thousand botnet victims each time, they already have the means available to them. As I discussed earlier this month, we’ve observed a growing number of criminal operators adding DGA’s to their malware families as a backup strategy should their P2P C&C fail for whatever reason. If the Kelihos operators add that feature to their next variant the wac-a-mole efforts of Kelihos-P2P-swatters truly become inconsequential.

Like I’ve said before, if you’re going to take down a botnet you have to take out the criminals at the top. It’s the only way. Taking out the infrastructure they depend upon for distributing new infectious material and C&C is a disruption technique – a delaying tactic if you will, and maybe an evidence building process if you’re lucky. In the case of P2P-based botnets, there’s very little infrastructure you can get your hands on – and you’ll probably end up having to issue commands to botnet victim devices – which is fraught with legal and ethical problems.

Oh, one last thing. Even if you’re lucky enough to be able to take out the C&C infrastructure or mechanism of communication, if you don’t take out the infection vector – the mechanisms of distributing new crimeware variants – you’ve achieved very little. As evidenced by the most recent Kelihos botnet takedown attempt, the criminals retained their primary distribution system and are already accumulating thousands of new victims per day with their latest Kelihos-variant campaign.

The (Cyber) War Scientists

A few weeks ago I finished reading the book "The War Scientists" by Thomas Craughwell. It's a book about the individuals - the Scientists if you will - that invented some of the most significant weapons of war. As you'd expect, the book examines their technologies in combat and impact at the time.

By itself, the book is pretty interesting but only in the capacity of bringing together an Encarta-level of history to the fore.

Despite that, it got me thinking about the "who and what" would be included in such a book if it was to be updated in 20 years or so. Would "Cyber War" be worthy of inclusion, what cyber weapon would make the grade and which individual(s) would be included?

Lets for the moment assume that real, full-on "cyber-war" will occur within the next decade or so, and that the weapons to be used in that war either exist today or are derived directly from technologies (or methodologies) present today. Big assumptions, but hey - in the realm of the possible, anything is probable.

Is there a particular technology - turned weapon of war - that leaps out as a game changer? Likely candidates for many I suppose could include Stuxnet or maybe Metasploit, or perhaps even the MBR rootkit. But to my mind these are all derivatives of older tools and tactics - engineering advancements of someone elses invention.

Would the owner of the mind behind the first vulnerability scanner constitute a "scientist"? (probably not).

The more I think about it, despite a lot of innovation in the cyber arms trade, I don't think that any "game changers" have been made to the public eye yet. Is there an equivalent to the torpedo or mustard gas? Sure, you can draw some comparisons between various malware formats or features if you were so inclined, but where are the one-sided game-changing weapon developments?

You know what, I suspect that some of those cyber-weapon game-changers have already been invented or are being invented right now. Unfortunately (or should that be fortunately?) those weapons haven't been used yet and their inventors aren't likely make headlines sometime after the dust settles.

Ice IX Rising Against SpyEye

As commercial crimeware construction tools go, SpyEye has been king of the hill for the last year or so – with dozens of cybercrime organizations adopting it as their attack platform of choice. But has its time come to an end already? In the competitive ecosystem of crimeware construction tools and attack delivery platforms, to maintain a lead, the engineers behind the tools have to continuously innovate and roll out new features to their subscriber-base. In the case of SpyEye, it looks like they’re falling behind and their customers are already switching platforms and providers.

Ever since the public leaking of the 1.3.45 SpyEye builder and some accompanying cracks, a menagerie of “unauthorized” SpyEye resellers and distributors have flooded the hacker forums with cut-price copies of the malware construction tool. As would-be SpyEye sellers tout their latest extensions, fake updates and fixes, the SpyEye original authors have bunkered down – focusing their attention upon only their most trusted customers, and not actively seeking more. As distrust spreads within the cybercrimal fraternity, a number of notable criminal operators have been moving to a new competitor on the block – “Ice IX”.

Ice IX, like its competitors (SpyEye, Zeus, TDL, Hiloti, Carberp, etc.), offers the same core crimeware construction functionality – malware builders, an attack delivery platform, and a management console – and also makes extensive use of third-party developed Web Inject content to extract valuable data from its victims. What makes Ice IX so interesting to (former) SpyEye customers is that it’s being actively maintained and is proving to be a reliable attack platform against even newly patched victims – not to forget being much cheaper too.

Over the last few months Damballa Labs have been tracking a number of criminal operators as they replace their SpyEye installations and migrate to the new Ice IX platform. It is only a trickle at the moment, but we can probably expect more SpyEye operators to transition to other better-supported crimeware construction platforms throughout the year.

To understand why SpyEye is losing out to Ice IX, my colleague Sean Bodmer has pulled together a Research Note on the topic – where he details the crybercriminal migration between attack platforms and discusses the impact on some of the larger (former) SpyEye-based operators we’re tracking.

The Research Note – “SpyEye, being kicked to the curb by its customers?” can be found at http://www.damballa.com/downloads/r_pubs/RN_SpyEye-Kicked-to-Curb_Bodmer.pdf

Infinite Malware & Infinite Protection?

Infinite detection of malware? In Sophos' blog entry "To infinity and beyond" it's pointed out that there's an infinite number of malware threats (and that there'll be more tomorrow). It's also implied that customers are protected against these infinite threats by infinite detection capabilities - which is obviously taking the theme in to some far-flung infinite parallel universe with infinitely better anti-virus solutions that we have in our particular reality.

Nevertheless, their perspective of infinite malware is quite correct. Given that malware can by dynamically generated (checkout the paper on x-morphic attack engines), exhibit polymorphic capabilities and is generally created faster than it can be counted, captured and cataloged, then for all intents and purposes it is infinite.

Which means I have to chuckle when I hear or read any media coverage about the number of malware a particular vendor has captured and written detection signatures for. It's like saying "look, I tripped over 2,543,234 pieces of malware around the world last year and developed protection of each of them". Then, with my mathematicians hat on... infinite threats minus 2,543,234discovered threats still leaves an infinite number of threats. Or, expressing detection coverage as a percentage of scale of the threat = zero percent.

Obviously that's not precisely true. Anti-virus technologies are generally OK at detecting the stuff they've seen before and with generic catch-all signatures they can often capture or label related families of malware as being malicious - or at the very least "suspicious". The problem tends to grow in to frustration when practically every binary file downloaded from the Internet gets marked as "suspicious" - and hence the label becomes meaningless.

Despite all this, Sophos is spot on - there's an intinite number of malware out there, and there'll be more tomorrow. Welcome to the day after yesterday.

Forgotten Password?

The increased proliferation of malware and botnet agents designed to rapidly intercept, retrieve and copy the passwords you use on a daily basis to access Internet resources likely means that it may be time to revisit many of those longtime-standing password policies. Given all the "best practice" guidelines I've seen over the years, I think that (in practical terms) they're increasingly missing the mark in defending against today's threat landscape.

One particular "best practice" that I think needs to be re-thunk... "don't write your password down."

I blogged a little more on the topic over on the Damballa site... It's safer to write your password down...

-------

Common wisdom over the last couple of decades has been to never write down the passwords you use for accessing networked services. But is now the time to begin writing them down? Threats are constantly evolving and perhaps it’s time to revisit one of the longest standing idioms of security – “never write a password down”.

Back in the day, a password was a critical part of the corporate identity system. You supplied your user ID and password pair in order to get online and to access key corporate resources. Access controls then extended the authentication model to enable greater control of what users could see, do and change. As new systems came online, and as business extended beyond the in-house corporate networks, additional (i.e. separate) authentication systems came in to play. Despite multiple attempts at developing and deploying single sign-on (SSO), most employees still need to juggle a dozen passwords in order to do their work. If they have external Internet accounts as well, then they’ll be juggling several dozen additional passwords. Once you thrown in their personal Internet accounts (webmail, Twitter, Facebook, LinkedIn, PayPal, Amazon, etc.) you’re quickly neck-deep in password soup.

Whats traditionally been the problem with writing down password anyway? Well, since passwords are the critical ingredient for access control, corporate security teams have long “educated” employees in to never writing them down. To do so would potentially expose yourself to impersonation – and you’d ultimately be responsible for whatever (damage) the impersonator did in your name.

In the meantime, Internet guides, popular PC magazines, and practically every website that forces you to create a login account, all extol the virtues of never writing your passwords down. They also give you lots of additional advice – such as “use a strong password”, “use a unique password”, “never use the same password on a different site”, etc. All of which make it incredibly difficult for any practically minded human to keep track of which password belongs to which website. The net result being that the “password rules” are being repeatedly broken.

Now, to ease some of this burden, there have been a spurt of software tools that’ll help remember passwords on your behalf. For example, the popular web browsers all provide some capability in this area. The problem though is that the bad guys have better tools. Practically all of today’s malware(along with all those botnets you hear about each day) have the built-in capabilities of grabbing/stealing both the passwords you’ve remembered and type in each time you visit a favorite website, and the passwords being conveniently “remembered” by the software on your computer.

Why would writing down a password be good? Well, it’s not a question of being good – just better. Granted, anything you type on your computer can (and will) be grabbed by the malware it’s been compromised with- but the lowest hanging fruit for the bad guys lies with all the stuff you’ve already asked your computer to remember on your behalf. After 3 months of use, web browser “remember” functions may have captured 50+ sets of authentication details. Within a few seconds of computer compromise, all three moths worth of stored credentials will have been copied and stolen (oh, and they’re neatly formatted and sorted) – so the malware doesn’t need to do any work, and it doesn’t matter if your anti-virus software gets an update tomorrow capable of detecting the malware and removing it. The damage is already done.

Staying hidden on a victims computer is not a trivial task for many malware – particularly wide-spread Internet malware (anythingwith a name you may have read about). There are lots of things that can go wrong. AV updates may detect the infection, dropper websites may be taken down, uploading sites may be sinkholed, CnC domains may be hijacked, etc. so it’s become important for modern malware to steal as much information as possible within the shortest possible time. Factors such as conveniently storing all your authentication details on your computer and recycling popular (i.e. memorable) passwords reduce the time the malware needs to be operating in order to steal critical data.

What about a few high-level odds?

• 1:3 – home PC being infected with malware with password stealing capabilities in a given year.
• 1:4 – home PC being infected with a botnet agent in a given year
• 1:8 – corporate PC being infected with malware with password stealing capabilities in a given year
• 1:12 – corporate PC being infected with a botnet agent in a given year
• 1:160 – your car being stolen in a given year
• 1:700 – your home being burgled
• 1:600,000 – being struck by lightning

I think it’s time to revisit the “never write a password down” idiom. Prioritizing best practices in password management, I’d be inclined to list them in the following order:

1. Don’t use the same password on multiple websites
2. Don’t let your computer “remember” your password!
3. Use a “strong” password – preferably something with 12+ mixed characters
4. Don’t use a predictable algorithm – e.g. abc123
5. Change your passwords regularly. For sites with lots of personal information and associated monies, change every 2-3 months. For other sites, try every 6-12 months.
6. Don’t reuse past passwords – even if you think it’s a cool password.
7. Don’t write your password down.

Yes, that’s right – writing down your passwords come in at a distant 7th place. In practical terms, even if you only manage the first 4 on the list, you’re probably going to be juggling at least a couple of dozen passwords (or more thank likely that’ll be 40+ on a regular basis for most people that spend any time online). The probability that your computer(s) will be compromised and that the information will be stolen by the bad guys malware is much, much greater than the probability that someone will manage to break in to your house and target all the post-it notes you’ve stuck around your screen with all your passwords on them. In corporate environments there’s a higher probability that the evening cleaning crew would gain visibility of he passwords (so post-it notes aren’t to be recommended), but that risk of an insider threat is still going to be lower than your work computer being compromised.

The first 6 password recommendations would trump the 7th in most cases – provided you take care in how and where you write your passwords down. Be smart about it… but don’t underestimate the risks posed by modern malware either.

Protecting Your Malware IP Investment

Competition between malware authors and botnet operators can be fierce at times. Opponents are constantly squaring up and trying to build bigger, better and more "advanced" everything. As such, they're keen to make sure that their latest advances and IP isn't ripped off by a competitor or, heaven forbid, some pesky malware analyst working at an antivirus company.

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

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

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

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

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

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

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

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

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

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