The Day Before Zero

Nothing ever stands still on the Internet. Like life on the African Savannah, the old and the sick are easy prey to those who are faster and more agile. Old and vulnerable software, along with aging infrastructure, quickly fall prey to swift and orchestrated attacks from around the world.

Which brings me to the discussion over three of the most important changes on the Internet for quite some time – all of which appear to be reaching their crescendo at the same time. While I’m silently hoping that most people are familiar with the three, I suspect that very few people are as up to speed as they need to be. Which three? IPv6, Internationalized Domain Names (IDNs) and DNSSEC.

Incremental testing and roll-outs of these three technologies has been ongoing for way too long – but it seems that they’re all hitting the Internet (and consequently the Enterprise) at round about the same time. DNSSEC, the late starter, would appear to be in pole position to reach widespread deployment first. Meanwhile IPv6, a technology that has been on the drawing board for over a decade, is finally finding its feet as prophets predict the end of the Internet as old-style IPv4 addresses run out.

From a security perspective, DNSSEC is most strongly affiliated with “making the Internet better” – that is to say, it was designed to overcome many of the security weaknesses and failures of past DNS specifications, implementations and deployments – in particular, certain types of attacks directed at cache poisoning. For enterprise environments, DNSSEC strengthens the overall security of DNS servers and will make them more resilient to many of the attacks that have plagued the Internet for the last couple of decades. There is even talk about how this technology, once deployed widely and mandated for Internet use, will help reduce persistent threats such as spam and phishing. That said, it’s one of the technologies I’d class as important from a security perspective, but isn’t really going to affect the criminals adversely. Great defensive advances from a hacker/cyber-war perspective, much less so from a criminals perspective.

The two other technologies – IPv6 and IDNs – on the other hand are much more interesting from a security and criminal perspective, as they potentially open the doors to many new forms of abuse and attack vectors. I use the term “potentially”, but in reality I mean that they will obviously enable new forms of attacks and enhance many of the existing attacks that have plagued the Internet throughout the last decade.

I’m not going to go in to the technical details of these technologies – if you’re interested in finding out more about them, go HERE for the IPv6 information and HERE for the IDNs information. What I will point out though is that these two technologies have a far reaching impact upon both the vectors through which the bad guys can attack an enterprise through, and upon the security technologies used to detect and analyze subsequent attacks.

IDNs and IPv6 shouldn’t be thought of as an upgrade to existing Internet standards or networks – i.e. migrating from Internet 1.0 to 2.0 – but could conceivably be thought of as a parallel universe where things are kind of familiar, but different at the same time.

How could I describe the changes between IPv4 & IPv6 and the traditional domain system & IDNs? By way of analogy, think about good, old fashioned, radio. The traditional domain name and registration processes (with all the 2LD and 3LD definitions), along with the traditional IPv4 networks can be thought of as operating over AM Radio. Meanwhile IDNs and IPv6 can be thought of as FM Radio. That is to say, moving from one to the other isn’t the same as just turning the dial left or right in search of a new station or frequency. Rather, we’re talking about a kind of change that requires a different kind of receiver – and without the right receiver (AM or FM) you’re not going to be able to pick up the new channels.

The analogy only goes so far though. But just like the electromagnetic waves of radio transmissions are undetectable without the correct receiver and the right tuning, the same concepts apply to IPv6 and IDNs advancements. Without ensuring that your security technologies can actually handle these changes to the Internet or enterprise network, there’s no way you’re going to be able to detect them being abused for malicious and criminal purposes.

A likely question from readers is going to be “Are the bad guys abusing these technologies already?” From casual observation and perhaps being tainted by too many years having to think and act out as one of the bad guys, the answer has got to be “Yes”. But, on the plus side, not to a noticeable or damaging level yet. The bad guys are still in an experimental and prototyping phase – examining the potential vectors for abuse – and largely waiting for the time when it becomes worthwhile launching meaningful attacks that abuse IPv6 and IDN rollouts. I have no doubt that many of the criminal service providers are priming themselves for the new revenue models and competitive edge.

The question I’d leave for readers in return though is “do you think your security systems are capable of detecting and reporting abuse of IPv6 and IDNs?”

Think about it. Which systems and processes do you have in place capable of detecting a brand new phishing site hosted as www.eBay.com where the “B” is the Cyrillic letter Ve and just happens to look exactly like the ANSI “B” character? and what if the SSL/TLS certificate matches, etc. Would you notice that a botnet agent is propagating and establishing peer-to-peer relationships between infected hosts within your own organization over IPv6? Would you be able to scan for, and uncover, a botnet Command and Control service running on a compromised host with an IP address of 2001:db8:85a3::8a2e:370:7334?

While DNSSEC works to close down several vulnerabilities, IPv6 and IDNs open the doors for additional forms of attack and attack vectors. Now would be a great time to double-check that your existing systems are capable of handling these changes – particularly new internationalized domain names such as www.günterollmann.com.

– Gunter Ollmann, VP Research

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

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

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

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

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

You can register for the free APT audit here.

– Gunter Ollmann, VP Research

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

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

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

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

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

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

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

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

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

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

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

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

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

– Gunter Ollmann, VP Research

Many businesses have already deployed Anomaly Detection Systems (ADS) within their enterprises whether they know it or not. Most ADS technologies can be discovered operating at the host-level – typically integrated in to the popular desktop antivirus suites of the major security vendors – where they can be often be found functioning in a hybrid detection mode somewhere between a personal firewall and a behavioral analysis engine.

Network-based ADS (NADS) on the other hand serve a different purpose within large enterprises. Their deployments are far fewer than host-based ADS, and are often used by security teams to detect major changes in network activity – typically analyzing and regulating traffic flow. Optimized to view high volumes of network traffic across an enterprise as fast as possible (in real-time in many cases), they rely upon specially crafted abstract protocols of the traffic – such as NetFlow, JFLow, NetStream, etc. – where content visibility is sacrificed for analysis speed.

Over the last 2 years NADS technologies have increasingly been positioned as having an anti-botnet capability – which has caused much confusion amongst those responsible for managing ADS deployments and those responsible for enterprise-wide security. NADS do in fact have some value as an enterprise-level botnet detection tool, but their capabilities are all too often misrepresented.

How capable are NADS in detecting and mitigating botnets? What are their strengths and weaknesses? The following is a summary of my observations and experiences (garnered over the last 5+ years) in using NADS as an enterprise security technology – warts and all.

Botnet detection & mitigation strengths:

1. A correctly configured and baselined NADS deployment is capable of detecting the high-volume attack output from certain classes of botnets. By identifying voluminous email sending (e.g. spam agent or spam proxy operation) or crafted port-specific traffic (e.g. DDoS agent operation) and tracking that back to specific hosts, the infected systems operating in this manner can often be classed as being a member of a botnet.
2. Many general-purpose Internet botnet malware make use of worming capabilities to propagate around enterprise networks by exploiting unpatched software flaws in vulnerable hosts. If a NADS solution has been correctly baselined, it can be relatively easy to spot the anomalous traffic this propagating threat creates – thereby alerting security teams to a new malware outbreak.
3. By configuring the NADS system to account for “normal working hours”, different detection thresholds can be utilized to aid in the detection of hosts that are actively communicating with botnet Command and Control (CnC) nodes. For example, if a host suddenly commences HTTP or IRC communication with an IP address located in Tibet at 3:00am in the morning – this will likely be very suspicious.
4. If an organization has suffered a sudden and large botnet infection, the constant polling of some botnet malware variants will quickly become apparent and will aid in the identification of those bot infected hosts.
5. If the NADS system supports the use of blacklists, a list of known botnet CnC’s can be used as a means of tracking the volume of data that has been sent or received by enterprise hosts that are part of the botnet. Study of this logging can help reveal the scope of a breach and the types of information the criminal botnet operator is targeting.

Botnet detection & mitigation weaknesses:

1. Very few botnets encountered within enterprises nowadays are noisy and spew copious volumes of spam or participate in devastating DDoS attacks. Botnet masters have largely moved on from this activity – and will only order bot infected hosts to operate this way if they’ve already exhausted all other value from the compromised hosts, or if they never bothered to figure out the infected hosts were actually located within an enterprise (in which case, if they had, they would have probably sold them to someone else for a good price). Therefore, basing detection of a botnet infection on copious volumes of attack traffic is either too late in the botnet lifecycle or was just bothersome (and not a security risk) to begin with.
2. By basing botnet detection upon the identification of outbound malicious traffic, the enterprise security team have failed to preempt the malicious operation of the botnet and are forced to deal with the voluminous output of an ongoing attack. Detection and mitigation of the botnet control instructions that instructed the attack to begin would have been more efficient and less damaging.
3. Baselining an enterprise NADS deployment – and keeping that baseline current – is almost impossible in the vast majority of businesses. New application deployments and software updates, along with roaming users and peer-to-peer communications, mean that enterprise network traffic is not as consistent and predictable as it was even only half-a-decade ago. As such, it becomes increasingly difficult to spot the worming traffic generated by botnets attempting to propagate around the network. This has become further complicated by the fact that the malware authors themselves have learned much from past attacks and have intentionally become more stealthy and deliberately slowed their propagation pace to avoid anomaly detection systems.
4. Botnet malware is more often than not designed to function only when the infected host is actually in operational use by its authorized user. As such, it is increasingly difficult to identify anomalous traffic from real traffic as the user goes about their regular Internet surfing.
5. Most botnet malware found within enterprise networks are proxy aware. This means that they borrow the users credentials and funnel all their CnC traffic through the corporate proxy servers – i.e. they do not use non-standard ports or protocols to navigate out to the Internet or between internal systems. The vast majority of botnet malware rely upon HTTP or HTTPS for communication.
6. Timing is everything for botnet operators nowadays. No sooner has a host been compromised through a drive-by-download vector or Trojan file download, that it connects back to its CnC ready to receive both a updated malware package and a new set of instructions. As such, unless the NADS solution is configured to react in real-time to the identification of a new botnet infection, the threat will have either moved on or already become more severe.
7. Many of the more commercially-minded botnet operators invest in fast-fluxing and domain-fluxing CnC technologies. The unrelenting changes in CnC IP addresses and hosts names can quickly overwhelm NADS systems.

So, in summary, I’d say that NADS does have a role to play in botnet detection – but only a very minor one, and even that’s diminishing all the time. NADS deployments make for capable enterprise-wide network health monitoring systems, but have faltered against advanced threats like botnets and even more stealthy threats such as Advanced Persistent Threats (APT’s). I’d liken NADS to a school nurse – constantly overseeing the health of the entire student population and dealing with the odd knee scrape and cut lip – but not trained or equipped to deal with major head trauma or the results of a shooting spree.

– Gunter Ollmann, VP Research

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

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

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

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

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

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

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

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

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

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

– Gunter Ollmann, VP Research

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

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

- Christopher Elisan – Senior Research Analyst

After a hard day’s work at the office, we often find ourselves still sitting in front of the computer or our laptop at home checking our corporate e-mail accounts. Some corporate users use Outlook Web Access (OWA) to check their work e-mail.

These are the kind of corporate users that Zeus botmasters are targeting since October of 2009, as first reported by Gary Warner in his blog, where an e-mail posing to be coming from the user’s own domain is alerting the recipient of a security upgrade that must be installed. But even after 3 months, the same tactic is still being used.

Figure 1: Sample OWA Spam

Clicking on the link will open a page urging the corporate user to download an executable to update the user’s mailbox settings.

Figure 2: Webpage urging the user to download an executable file

Of course, the file is a Zeus bot agent, aka Zbot. Since the installation will be user-driven, UAC warnings will simply be ignored by the user.

This shows how Zeus botmasters are targeting enterprise users specifically those with corporate laptops used at home. Once an infected laptop is connected to a corporate network, there is a big possibility that the rest of the systems in the same network will be infected giving the botmaster access to the corporate network. This actually gives the botmaster leverage as he now has control over infected corporate hosts and not just the laptop that was initially compromised. Access to corporate bots are more valuable than infected home PC’s. Aside from the wealth of information that can be stolen, access to corporate hosts can be sold for higher values to other botmasters. See related post on The ABC Advantage of Controlling Enterprise Networks.

This leads us to ask, how did the Zeus Botmaster get a hold of a corporate user’s e-mail address? Below are possible scenarios:

1. The original e-mail addresses were scraped from a newsgroup or other public list that keeps the e-mail headers. The headers contain a wealth of information that enables the Botmaster to determine whether OWA is applicable.
2. The Botmaster is able to get a hold of a directory of company employees. Even without the e-mail addresses listed, the Botmaster can guess the e-mail address format through simple trial and error or through social engineering. Some common e-mail address format are <firstname>.<lastname>@company_name.com, <firstname>_<lastname>@company_name.com.
3. The Botmaster bought it from other spammers.

As for corporate users that used their home PC to access their work e-mail through Outlook Web Access. Their PC still becomes part of the Botmaster’s herd waiting for a command.

- Christopher Elisan, Senior Research Analyst

There’s been no shortage of press covering Advanced Persistent Threats (APTs) this week. While there have been plenty of post-hack discussions over the past few years following the big public breaches, this one’s different – there’s almost a kind of relief that this one’s made it out in the open. I can liken it the relief and revelations that followed that first major tobacco manufacturer’s decision to admit that smoking actually probably wasn’t so good for you after all…

Unfortunately, the revelation of several dozen major organizations being the victim of this particular APT example has just about every security vendor on the planet clamoring to extol and position their latest nicotine patch equivalent. Or, perhaps more appropriately, a lock-box to prevent you from reaching for another cigarette.

In the hussle-bussle of vendors claiming “First” or “Preemptive”, there’s a lot of weighted wordage flying about. But if that’s all true, if a particular vendor was “First” in its discovery, why didn’t they stop the threat or protect the currently known victims? Didn’t they understand the significance of what they had already discovered? Did they choose to keep the information to themselves for competitive advantage? I can’t answer those questions – and frankly any answers I’d likely receive in return from these “First” vendors would probably be carefully word-smithed by a gaggle of marketing folks.

What about “Preemptive”? I like that word – it’s important. Having developed and invented many security technologies that fall in to that bucket over the last decade, I can categorically state that “Preemptive” is good. But (and you know there’d be a “but”), it’s not good enough…

Those nicotine patch equivalent vendors are going on about how they could/would/will/have/might preemptively…

• …detect the fact that the user is visiting a URL that’s probably dangerous
• …detect the malicious JavaScript or HTML that delivered the exploit
• …detect the exploit shellcode
• …detect the buffer overflow
• …detect the memory manipulation of the exploit
• …detect the malicious payload
• …detect the malware component
• …detect the malicious behaviors of the compromised application
• …detect the inappropriate behaviors of the compromised host
• …detect the malicious network behaviors

…and by “detecting” the APT, they’d have been able to protect against it (or an aspect of it). But at the end of the day, all those technologies, for one reason or another, failed to protect these organization from being a (very public) victim of the APT.

Why? Because APT’s aren’t like average-Joe malware, botnets, script-kiddies, hackers, fraud artists and cybercriminal attacks. The thing that makes APT attacks different from the other forms of cyber-attack can best be summed up with the mantra “if at first you don’t succeed – try, try and try again.”

The vast majority of Internet attacks – especially mass Internet botnets – are opportunistic attacks. The bad guys have a broad objective in mind along with a number of tools they specialize in and have a ceiling to the amount of effort they’re willing to expend. They will optimize a particular attack vector, select the preferred delivery method, and pound the Internet (and everyone on it) with that toolset until they’re acquired enough victims. So, while many of the attacks may appear to be “targeted” (e.g. Spear Phishing), their objectives are rather limited (e.g. immediate financial fraud), and if they don’t succeed against the currently highlighted target they’ll simply move on to the next.

APT’s don’t follow this model. If a particular attack vector, tool, technology or exploit didn’t (or is unlikely to) work, they switch to another – never changing targets nor focus.

What does that mean in practice? Regardless of the perimeter or host security technology you deploy, and how “preemptive” it is, it isn’t going to stop an APT. Sure, each “preemptive” technology worked just fine – stopping each and every attack vector, malicious payload or strange behavior it was supposed to – but the criminal operators targeting your organization just move on to the next tool or vector until they find one that works. And lets not forget (or kid ourselves), this probing of network defenses and “preemptive” protection doesn’t happen as an overnight barrage of simultaneous attacks from a small cluster of IP addresses tracked down to the Chinese Army. No, this is low and slow stuff spread over many days, weeks or months, routed via a variety of sources and proxies from around the world – or even through your business partners.

So, can all of these nicotine patch sellers protect your organization against APT’s? No, of course not. They can protect against many of the vectors that may be tried and probably identify the particular exploit or malware they end up using, but at the end of the day APT’s will win.

Which brings me to my final point. I don’t care how you got infected or became the latest APT victim – because you will be – so get over it and do something already. If a criminal operations team is willing to spend the time, effort and monies to target your organization, they will win! So, how do you defeat APT’s? Simple, you detect their presence as fast as you possibly can and remediate the victims almost as fast.

OK, so “preemptive” protection is important – but being able to know when that “preemptive” protection has failed is even more important!

FailSafe

Let me put on my Damballa hat for the moment. I’ve been getting a bunch of queries about whether the Damballa FailSafe solution detects the “Google APT thing in the news”. The answer is Yes, and many of the other APT’s that you haven’t heard about (and are unlikely to hear about). You see, from our technology perspective, we don’t care how you became a victim either (you can debate that’s my influence or cynicism leaking through). Lying at the heart of our technology is the ability to identify the suspicious and unauthorised remote control of systems within the enterprise.  All this is done at the network level and an APT’s command and control (CnC) is generally no different from a successful mass-Internet botnet, an insider threat or even a remote access trojan hand placed by a criminal operative. The motivations behind a botnet, insider threat and APT may be wildly different – but the CnC communications do not.

It gets a little tougher distinguishing between a brand new targeted botnet, an insider threat or an APT purely from their CnC traffic. But in reality the trick is to identify those threats that have already navigated your layers of corporate defenses and shut them down. Deciding which particular threat was politically/financially/ethics motivated comes afterwards.

Was this “Google APT thing in the news” the first APT to place Google under it’s cross-hairs? No. Is it the only APT targeting Google? No. Will it be the last APT to be targeting Google? No. Will targeted enterprises be able to prevent APT’s from getting in? No. Is it possible to detect when an APT has successfully bypassed all your “preemptive” protection technologies and compromised your systems? Yes.

– Gunter Ollmann, VP Research

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

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

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

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

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

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

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

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

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

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

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

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

– Gunter Ollmann, VP Research

Microsoft posted yesterday Microsoft Security Bulletin MS10-001: Vulnerability in the Embedded Open Type Font Engine Could Allow Remote Code Execution (972270)

“The vulnerability could allow remote code execution if a user viewed content rendered in a specially crafted Embedded OpenType (EOT) font in client applications that can render EOT fonts, such as Microsoft Internet Explorer, Microsoft Office PowerPoint, or Microsoft Office Word. An attacker who successfully exploited this vulnerability could take complete control of an affected system. An attacker could then install programs, view, change, or delete data, or create new accounts with full user rights. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.”

Although the aggregate severity rating for Windows 7 based systems is low, it could still be utilized by Zeus bot agents capable of running in Windows 7 as a vector for infection. See our previous blog for a discussion of the new Zeus DiY that supports Windows 7: Botnet Feature Advancement and Zeus Tweaking.

I’m a PC but this was not my idea!

- Christopher Elisan, Senior Research Analyst