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.

Crimeware Immunity via Cloud Virtualization

There's a growing thought recently that perhaps remote terminal emulators and fully virtualized cloud-baseddesktops are the way to go if we're ever to overcome the crimeware menace.

In essence, what people are saying is that because their normal system can be compromised so easily, and that criminals can install malicious software capable of monitoring and manipulating done on the victims computer, that perhaps we'd be better off if the computer/laptop/iPad/whatever was more akin to a dumb terminal that simply connected to a remote desktop instance - i.e. all the vulnerable applications and data are kept in the cloud, rather than on the users computer itself.

It's not a particularly novel innovation - with various vendors having promoted this or related approaches for a couple of decades now - but it is being vocalized more frequently than ever.

Personally, I think it is a useful approach in mitigating much of today's bulk-standard malware, and certainly some of the more popular DIY crimeware packs.

Some of the advantages to this approach include:

1. The user's personal data isn't kept on their local machine. This means that should the device be compromised for whatever reason, this information couldn't be copied because it doesn't exist on the user's personal device.
2. So many infection vectors target the Web browser. If the Web browser exists in the cloud, then the user's device will be safe - hopefully implying that whoever's hosting the cloud-based browser software is better at patch management than the average Joe.
3. Security can be centralized in the cloud. All of the host-based and network-based defenses can be run by the cloud provider - meaning that they'll be better managed and offer a more extensive array of cutting-edge protection technologies.
4. Any files downloaded, opened or executed, are done so within the cloud - not on the local user's device. This means that any malicious content never makes it's way down to the user's device, so it could never get infected.

That sounds pretty good, and it would successfully counter the most common flaws that criminals exploit today to target and compromise their victims. However, like all proposed security strategies, it's not a silver bullet to the threat. If anything, it alters the threat landscape in a way that may be more advantageous for the more sophisticated criminals. For example, here are a couple of likely weaknesses with this approach:

1. The end device is still going to need an operating system and network access. As such it will remain exposed to network-level attacks. While much of the existing cybercrime ecosystem has adopted "come-to-me" infection vectors (e.g. spear phishing, drive-by-download, etc.), the "old" network-based intrusion and automated worm vectors haven't gone away and would likely rear their ugly heads as the criminals make the switch back in response to cloud-based terminal hosting.
   As such, the device would still be compromised and it would be reasonable to expect that the criminal would promote and advance their KVM capabilities (i.e. remote keyboard, video and mouse monitoring). This would allow them to not only observe, but also inject commands as if they were the real user. Net result for the user and the online bank or retailer is that fraud is just as likely and probably quite a bit harder to spot (since they'd loose visibility of what the end device actually is - with everything looking like the amorphous cloud provider).
2. The bad guys go where the money is. If the data is where they make the money, then they'll go after the data. If the data exists within the systems of the cloud provider, then that what the bad guys will target. Cloud providers aren't going to be running any more magical application software than the regular home user, so they'll still be vulnerable to new software flaws and 0-day exploitation. This time though, the bad guys would likely be able to access a lot more data from a lot more people in a much shorter period of time.
   Yes, I'd expect the cloud providers to take more care in securing that data and have more robust systems for detecting things that go astray, but I also expect the bad guys to up their game too. And, based upon observing the last 20 years of cybercrime tactics and attack history, I think it's reasonable to assume that the bad guys will retain the upper-hand and be more innovative in their attacks than the defenders will.

I do think that, on average, more people would be more secure if they utilized cloud-based virtual systems. In the sort-term, that security improvement would be quite good. However, as more people adopted the same approach and shifted to the cloud, more bad guys would be forced to alter their attack tools and vectors.

I suspect that the bad guys would quickly be able to game the cloud systems and eventually obtain a greater advantage than they do today (mostly because of the centralized control of the data and homogeneity of the environment). "United we stand, divided we fall" would inevitably become "united we stand, united we fall."

IP's and the APT

Most of the good thrillers I seem to have watched in recent years have spies and assassins in them for some diabolical reason. In those movies you’ll often find their target, the Archduke of Villainess, holed up in some remote local and the spy has to fake an identity in order to penetrate the layers of defense. Almost without exception the spy enters the country using a fake passport; relying upon a passport from any country other than their own.

Like any good story, there’s enough truth to the fiction to make it believable. Take the real-life example of the hit squad that carried out the assassination of a Hamas official in Dubai early 2010. That squad (supposedly Israeli) used forged passports from the United Kingdom, Ireland, France and Germany.

So, with that bit of non-fiction in mind, why do so many people automatically assume that cyber-attacks sourced from IP addresses within China are targeted, state-sponsored, attacks? Are people missing the plot? Has the Chinese APT leapfrogged fact and splatted in to the realm of mythology already?

If you’re manning a firewall or inspecting IPS log files, you can’t have missed noticing that there’s a whole bunch of attacks being launched against your organization from devices hosted in China on a near continuous basis. A sizable fraction of those attacks would be deemed “advanced”; meaning that as long as they’re more advanced than the detection technology you happen to be reliant upon, they’re as advanced as they need to be to get the job done.

Are these the APT’s of lore? Are these the same things that government defense departments and contractors alike quake in their boots from? There’s a simple way to tell. If what you’re observing in your own logs shows the source as being from a Chinese IP address it almost certainly isn’t.
Yes, there’s a tremendous amount of attack traffic coming from China, but this should really be categorized as the background hum of the modern Internet nowadays. China, as the most populous country on the planet, isn’t exempt from having more than its fair share of Internet scoundrels, wastrels, hackers and cyber-criminals — spanning the full spectrum of technical capability and motivations. Even then, the traffic originating from China may not be wholly from criminals based there — instead it may also contain attack traffic tunneled through open proxies and bot infected hosts within China by other international cyber-criminals.

Mind you, when we’re talking about cyber-warfare and state-sponsored espionage, we’re not talking about a bunch of under-graduate hackers.

Just about every country I can think of with a full-time professional military force has been investing in their cyber capabilities – both defense and attack. While they’re not employing the crème de la crème of professional hacking talent, they are professional and have tremendous resources behind them, and they follow a pretty strict and well thought-out doctrine. If you’re in the Chinese Army and have been tasked with facilitating a particular espionage campaign or to aid a spy mission, the last thing on earth you’re going to do is to launch or control your assets from an IP address that can be easily traced back to China. Anywhere else in the world is good, and an IP address in a country that your foe is already suspicious of (or fully trusting of) is way better.

Don’t get me wrong though, I’m not singling out the Chinese for any particular reason other than most readers will be familiar with the hoopla and epic proportions of Chinese APTs in the media. Any marginally competent adversary is going to similarly launch their attacks from a foreign source if they’re planning on maintaining deniability should the attack ever be noticed – just like those spy tactic of using foreign passports.

So, if you’re inclined, how are you going to get access to foreign resources that can proxy and mask your attacks? Elementary my dear Watson, there’s a market for that. First of all there’s a whole bunch of free and commercial anonymizing proxies , routers and VPN’s out there – but they may not be stable enough for conducting a prolonged campaign (and besides, they’re probably already penetrated by a number of government entities already). Alternatively you could buy access to already compromised systems and hijack them for your own use.

Over the last five years there have been a bunch of boutique threat monitoring and threat feed companies springing up catering almost exclusively to the needs of various national defense departments. While they may offer 0-day vulnerabilities, reliable weaponized exploits and stealthy remote access Trojans, their most valuable offering in the world of state-sponsored espionage is arguably the feed of intelligence harvested from the sinkholes they control. Depending upon the type of sinkhole they’re fortunate to be operating, and which botnet or malware campaign that happened to utilize the hijacked domain, they’re going to have access to a real-time feed of known victim devices from around the world, copies of all the data leached from the victims by the malware and, in some cases, the ability to remotely control the victim device. Everything a cyber-warfare unit is going to need to hijack and usurp control of a foreign host, and launch their stealthy attack from.

Now, if I was say working within the cyber-warfare team of the French Foreign Legion or perhaps the DGSE (General Directorate for External Security) and interested in gathering secret intelligence about the investment Chinese companies are making in sub-Sahara mineral resources, I’d probably launch my attack from a collection of bot-infected hosts located within US or Australian universities. The security analysts and incident response folks working at those Chinese companies are probably already seeing attack traffic from these sources off-and-on, so my more specialized and targeted attack would unlikely raise suspicion. Should the targeted attack eventually be discovered, the Chinese would simply blame the US and Australian governments – rather than the French.

Having said all that, you’ve probably seen movies with double-agents in them too. And it’s entirely possible that someone hair-brained enough would argue that China launches attacks from their own IP space because everyone knows that you shouldn’t, and therefore an assumption would be made that attacks launched from China are clearly not from the Chinese government – while they are in fact. How very cunning. Now there’s a twist for the next spy movie.

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.

Get over it, BYOD is here for good

Like the scene of a movie in which a biblical character holds back the mighty sea and is about to release the tide against his foes, BYOD has become a force of nature poised to flood those charged with keeping corporate systems secure.

Despite years of practice hardening systems and enforcing policies that restrict what can and can’t be done within the corporate network, businesses are under increasing (if not insurmountable) pressure to allow a diversifying number of personal devices to connect to their networks and be used for business operations. Bring your own device (BYOD) is the most intrusive trend that security teams have had to face for quite some time.

Unlike other business changes over the years that caused security teams to reevaluate their policies (such as allowing remote users to VPN in to the corporate network or enabling webmail facilities for roaming users), BYOD is being driven by all levels of the corporate hierarchy simultaneously. And it’s forcing new changes in the way organizations conduct business and seek to secure themselves.

BYOD is directly forcing the hand of security teams; and those that don’t (or can’t) accommodate the change are in for a very rough ride indeed.

Organizations that have embraced the approach – allowing employees to bring in their personal devices and engage with business systems – appear to have reaped rewards ranging from increased productivity, through to a lowering of capital expenditure within their IT departments. BYOD is affecting all walks of life. For example:

• Out-of-hours system monitoring and alerting through Android applications that can be trivially loaded on to an employee’s Smartphone.
• Larger pockets being added to medical staff’s lab coats and smocks to accommodate the iPads they’re increasingly carrying around.
• Shared use of cloud storage facilities as employees jump back and forth between personal and corporate devices throughout the day.

Not all businesses have embraced a BYOD culture the same way. In the majority of organizations I deal with, the general security strategy is to treat the device as “untrusted” – typically only allowing the user of the device to connect to the Guest or dirty wireless networks and limiting access to those services or business applications that can ordinarily be accessed remotely (e.g. through a VPN). Meanwhile, a handful have gone ‘whole hog’ as it were, and are doing away with corporate supplied computing devices; instead they’re offering to subsidize the employee’s purchase and provide a list of “minimum” security standards for the device.

We are in a transitional period with respect to BYOD strategies and there is a lot of experimentation as organizations strive to achieve a new balance between security and convenience. As such, the security posture of an organization needs to take into account the continuous change going on about it. While it’s been a common declaration within the security community that you can’t protect the end-point from a determined attacker, as device ownership slips from the hands of the corporate entity into the hands of the employee, so too does the onus for protecting it.

For many organizations the frontline in security for the last two decades has been protecting computers with host-based defenses. Sure, there’s been investment in perimeter defenses, but the war between the cybercriminals and their prospective victims has been happening with the operating systems, web browsers and applications of the end device. As such, with control of the end-point device slipping out from control and oversight of corporate security teams, an added emphasis is being placed upon two critical security approaches – securing the core (centralized) intellectual property and data of the organization, and rapidly identifying devices that have already been compromised.

Organizations with a mature security strategy flexible enough to accommodate BYOD demands have pursued an approach in which it is assumed that the user’s device is likely (if not already) compromised and under control of an external criminal entity. As such, they have myopically focused their attention on securing the servers that really matter to the business and are securing the system and repositories that govern or track the data itself. In parallel, they’ve deployed systems that alert and identify devices that are acting suspiciously or are positively identified as being usurped by professional crimeware, and take immediate, automatic steps to restrict and cauterize the threat.

BYOD has forced a paradigm change in the way businesses approach and enforce security within their organizations. Security teams within organizations that continue to resist the adoption and use of personal devices (whether they be personal laptops, Smartphones, tablets or X-Box) are fooling themselves if they think they can hold back the tide. Security consolidation and threat alerting are the ropes they need to grasp.

Unauthorized Access to Millions of Cards at Global Payments

Global Payments, an Atlanta-based payment card processing firm, announced yesterday that they had suffered “unauthorized access into a portion of its processing system“. Sometime in early March they uncovered the attack, and there are some indications that the breach occurred between January 21st and February 25th of this year.
At the moment there is very little public information relating to the nature of the breach, merely that the details of an estimated 10,000,000 cards (track 1 and track 2 – effectively what’s needed to clone physical cards) have been slurped by the attacker(s). Global Payments will be holding a conference call Monday, April 2, 2012 at 8:00 AM EDT. Personally, I’m not expecting much in the way of additional information concerning the method and vectors of the breach to be discussed – but would expect a lot about what they’ve done to reduce fraudulent use of the stolen card details.
There are a number of unverified reports that a New York City street gang with Central American ties took control of “an administrative account that was not protected sufficiently”. Hopefully a little more light will be shed over the following days as to the nature of the breach – less so for closing the case at Global Payments, but more for others to learn from and to not repeat these kinds of mistakes.
When it comes to breaches like this – as in attacks that appear to target large organizations that hold large volumes of easily sellable data in the digital underground – the three most common vectors from my experience are the following:

1. Insider threat – An insider with detailed knowledge of the businesses operations is able to install tools or access administrative accounts that enable large volumes of confidential information to be copied and transported out of the organization – past existing data inspection technologies. Often the transport mechanism is a USB device or a password-protected file that is uploaded to an external Internet server.
2. Crimeware
   installation – A system within the organization is breached through standard drive-by-download or phishing email vectors and a full-featured crimeware agent is installed. The malicious agent registers itself with a criminal’s remote command and control (C&C) server and drops a bunch of stolen data relating to that single compromised host. The criminals inspect the small amount of stolen data and realize that they have access to a host within an interesting organization and turn on some additional functions of the crimeware agent to better enumerate the devices and accounts within the breached organization. Armed with a better understanding of the organization and a number of captured accounts and their passwords, the criminals may begin to remotely access other systems within the breached organization or, more likely, sell access to the device to someone that is more capable and better prepared to hack the victim’s network.
3. Remote account access - Somewhere along the line the organization has enabled a number of remote access portals or VPN’s to enable staff and business partners to access key servers or update data records. Some of these services have been poorly secured or, most likely, particular accounts have been uncovered and fully enumerated by the attackers. Armed with the accounts user ID and password, the attacker(s) can simply log in remotely and slurp down the data they want.

For organizations likely to suffer from such targeted breaches (whether or not the initial breach was due to an opportunistic or non-targeted infection vector), there are obviously a myriad of technologies and tactics that can be implemented (any typically are) to timely identify and limit the loss from a breach. Some of the most successful approaches I’ve seen in recent years are the following:

• Canary accounts – Dropping in a number of records that appear to be real in to key databases and record repositories, and carefully monitoring access to these particular accounts. For example, these may be credit cards that exist only within the card processing organization and if any external merchant tries to process a transaction against such a card it would be clear that data has been leaked. These canary accounts can also be used to track data propagation within the network from a data-leakage perspective.
• Administrative accounts that aren’t – By including a number of accounts within internal corporate email address books and servers that appear to be administrative (or high privilege accounts), monitoring systems can be set to alert if anyone attempts to email them, or use the accounts to access any server. This will alert the organization to many internal breaches earlier than watching for externally used canary accounts.
• Destination monitoring - By tracking all egress traffic and identifying both anomaly traffic patterns to standard business entities and to “unexpected” destinations, it is possible to gain early warning of a breach in progress.
• Cybercriminal C&C monitoring - The most likely breach vector that the victim organization is going to be able to proactively detect and protect against is going to be against remotely controllable crimeware. By knowing which Internet infrastructure is related to what criminal operators it becomes an automated process of identifying crimeware infected computers operating within their organization and prioritizing their remediation over standard malware infections.

Hopefully most organizations are aware that modern crimeware rarely comes through the front door in an easily inspectable form. Even insider threats have found it increasingly advantageous to use their own crimeware as a method of remotely accessing devices within the targeted organization and transporting the stolen data out. As such there is a need to identify egress traffic associated with crimeware and to instrument the organization to detect canary data records and administrative accounts.
With a bit of luck we’ll get more insight to the Global Payments breach over the coming weeks. However, I suspect that it’s going to be the same old story again. The cybercriminals have better tools than their victims and are more agile in their deployment and use.