In situ Automated Malware Analysis

Over the past few years there's been a growing trend for enterprise security teams to develop their own internal center of excellence for malware investigations. To help these folks along, there's been a bundle of technologies deployed at the network perimeter to act as super-charged anti-virus detection and reporting tools.

There's a problem though. These technologies not only tend to be more smoke and mirrors than usual, but are increasingly being evaded by the malware authors and expose the corporate enterprise to a new range of threats.

Earlier this week I released a new whitepaper on the topic - exposing the techniques being used by malware authors and botnet operators to enumerate and subvert these technologies. The paper is titled "Automated In-Network Malware Analysis".

I also blogged on the topic yesterday over on the Damballa site - here.

Cross-posting below...

Automated In-Network Malware Analysis

Someone once told me that the secret to a good security posture lies in the art of managing compromise. Unfortunately, given the way in which the threat landscape is developing, that “compromise” is constantly shifting further to the attacker’s advantage.

By now most security professionals are aware that the automated analysis of malware using heavily instrumented investigation platforms, virtualized instances of operating systems or honeypot infrastructures, are of rapidly diminishing value. Access to the tools that add sophisticated evasion capabilities to an everyday piece of malware and turn it into a fine honed one-of-a-kind infiltration package are simply a few hyperlinks away.

Embedding anti-detection functionality can be achieved through a couple of check-boxes, no longer requiring the attacker to have any technical understanding of the underlying evasion techniques.

Figures 1 & 2: Anti-detection evasion check-boxes found in a common Crypter tool for crafting malware (circa late 2008).

Throughout 2010 these “hacker assist” tools have been getting more sophisticated and adding considerably more functionality. Many of the tools available today don’t even bother to list all of their anti-detection capabilities because they have so many – and simply present the user with a single “enable anti’s” checkbox. In addition, new versions of their subscriber-funded tools come out at regular intervals – constantly tuning, modifying and guaranteeing their evasion capabilities.

Figure 3: Blackout AIO auto-spreader for adding worm capabilities and evasion technologies to any malware payload. Recommended retail price of $59 (circa August 2010).

Pressure for AV++

In response to the explosive growth in malware volumes and the onslaught of unique one-of-a-kind target malware that’s been “QA Tested” by their criminal authors prior to use in order to guarantee that there’s no desktop anti-virus detection, many organizations have embarked upon a quest for what can best be described as “AV++”.

AV++ is the concept behind some almost magical array of technologies that will capture and identify all the malware that slips past all the other existing layers of defense. Surprisingly, many organizations are now investing in heavily instrumented investigation platforms, virtualized instances of operating systems or honeypot infrastructures – all the things that are already know to have evasions and bypassing tools in circulation – despite the evidence. Has fear overcome common sense?

An area of more recent concern lies within the newest malware creator tool kits and detection methodologies. While many of the anti-detection technologies found in circulation over the last 3-4 years have matured at a steady pace, the recent investments in deploying automated malware analysis technologies within a targeted enterprise’s network have resulted in new innovations and opportunities for detection and evasion.

Just as the tactic of adding account lockout functionality to email accounts in order to prevent password bruteforcing created an entirely new threat (the ability to DoS the mail system by locking out everyone’s email account) so we see the development of new classes of threats in response to organizations that attempt to execute and analyze malware within their own organizations.

In a “damned if you do, and damned if you don’t” context, the addition of magical AV++ technologies being deployed within the borders of an enterprise network has opened the doors to new and enhanced evasion tactics.

To best understand the implications and dynamics of the new detection and evasion techniques being used by the criminals targeting businesses I’ve created a detailed white paper on the topic.

Intel Pentium Processor "Performance Upgrade"

Catching up with some of the RSS feeds I monitor earlier today I came across some chatter about the newly launched/noticed upgrade option for Intel processors. Specifically, the $50 upgrade option to the new Pentium G6951.

So whats all this about? Apparently, the new processor can be "upgraded" by purchasing what amounts to a license key for turning on the embedded functionality of the chip. Or, to put it another way, you've purchased a PC with a downgraded Pentium processor with disabled features - but can "enable" those features at a later date by simply purchasing the aforementioned "upgrade card".

There's a lot of fervor concerning this particular innovation from Intel. Granted, the concepts aren't particularly new and other technology companies have tried similar tactics in the past (e.g. I was once told that the IBM Z-Series mainframes ship with everything installed but, depending upon the license you purchased, not all the capacity/features of the system are enabled), but It's not something I'm a particular fan of. Then again, it would seem to me that I'm probably not the type of consumer that Intel would be marketing this product strategy to either.

The Intel site describing the upgrade technology/processes/etc. can be found at http://retailupgrades.intel.com/ - although it does appear to still be in a state of "under construction" as evidenced with the following response to the FAQ question of "Which PC's with this upgrade work on?"


Good luck with this one Intel. It's not like I'll be buying any product (Intel or other) knowing that it had been intentionally disabled and subject to an additional fee for activation.

The exception would be if I felt like doing a bit of RE to get the full functionality without buying in to the whole marketing "vision" (subject to license agreements, yadda, yadda, yadda...).

Musings on Metasploit

The week before last I attended and spoke at the OWASP AppSec 2010 conference on the first day, meanwhile HD Moore spoke on the second day.

It's always fun to watch HD Moore as he covers the latest roadmap for Metasploit - explaining the progress of various evasion techniques as they're integrated in to the tool and deriding the progress of various "protection" technologies.

A couple of things he said at the time stuck in my mind and I've been musing over them throughout last week. One comment - in response to a question that had been raised - was that IDS/IPS evasion is already sufficient within Metasploit and that further techniques would be "like kicking a cripple kid". Granted, not very PC - but that's the purpose of such statements.

I agree to a certain extent that IDS/IPS technologies can be evaded - but there's a pretty broad spectrum to IDS/IPS technologies and 'one size doesn't fit all'. For example, HD Moore mentioned that simply using HTTP compression (i.e. GZIP) is enough to evade the technology. Not so. For IDS/IPS technologies with full protocol parsing modules (rather than packet-based signature matching) such techniques won't work. But that's by the by. Depending upon the sophistication of the attacker and their knowledge of the strengths and weaknesses of the IDS/IPS technology, evasions can often be found in short order (depending upon the type of vulnerability being exploited). While it's obviously to HD Moores advantage to talk a good game on behalf of Metaspolit and novel evasion techniques, it doesn't hurt to be reminded that there is an agenda to making such broad claims.

The other comment he made related to the progress of adding more advanced payloads and exploit techniques. While I can't remember precisely the terms he used, the way he was discussing the topic - how much fun everyone was having inventing and developing the new techniques - I couldn't help by feel a little ashamed that things within the professional (attack-based) security field had reached this level.

What do I mean? Well, the way in which HD Moore was describing things to the audience I couldn't help but think in terms of physical weapons research. The description of the nestled exploit and evasion modules and how the developers/researchers were going about developing better, faster and more efficient techniques made me visualize a game of one-up man-ship between bullet designers. Something like the following...

Researcher 1: I think we should make a bullet that's Teflon coated but acts like a dum-dum bullet that expands to make a bigger hole in the target.

Researcher 2: No, I've got a better idea. Instead of using the dum-dum style of bullet, I've come up with a way of making it fragment quicker and completely eviscerate the target internally.

Researcher 1: How about we add that new flaming compound so that as the target gets eviscerated he'll combust at the same time.

Researcher 2: That's cool! I bet there'll be crimson smoke coming out of the target too.

Researcher 1: Ha ha. Cool! Lets build it and test it against those homeless people across the road.

I'm guessing you're thinking that I'm perhaps a little warped in thinking these kinds of things (and for writing them down). But it's something that sprung in to my mind at the time and again last week. How much is too much?

Granted, "good enough" protection can be defeated by using a "good enough" evasion technique. But I wonder when (or if) we'll ever need people to be more responsible for their actions developing what are effectively the cyber-equivalent of weapons? I strongly doubt that there'll ever be the cyber-equivalent of the Hague Convention though.

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.

Blacklists, Clustering and The Matrix

Blacklists are the mainstay of many security technologies protecting enterprise networks today. Despite being used practically everywhere however, many people fail to understand what blacklists actually offer in the realm of protection - and how they're often used as a preemptive protection technology.

Add to that a complementary technology - one offering more advanced features in the realm of preemptive threat detection (and perhaps "protection") and used to aid and extend blacklists - is that of clustering.

To help explain these technological terms (and whats happening in this field of preemptive technology) I wrote a couple of technical blogs that were published in SC Magazine this week. With a bit of luck you'll find them educational and a bit of fun.

Part One: Blacklists, clustering and The Matrix

Part Two: Blacklists, clustering and The Matrix

Mobile Threats - Cellular Botnets

Smartphones are getting smarter. You know it, I know it, and every would-be criminal botnet operator knows it too. But why haven't we seen many cellular botnets? It's not as if it's difficult to exploit, compromise or otherwise socially engineer a remotely controllable agent on to the handset.

Thoughts on the topic went up on the Damballa blog site earlier today and are mirrored below...

Last month I gave a couple of presentations covering the current state of cellular mobile botnets – i.e. malware installed on mobile phone, smartphone and cellular devices designed to provide remote access to the handset and everything on it. While malware attacks against dumb and smart phones are nothing new, the last 3 years of TCP/IP default functionality, compulsory data plans, access and provisioning of more sophisticated development API’s, have all made it much easier for malware developers to incorporate remote control channels in to their malicious software. The net effect is the growing “experimentation” of cellular botnets.

I purposefully use the term “cellular” so as to focus attention on the botnet agents’ use of the mobile Telco’s cellular network for Internet access – rather than more localized WiFi and Bluetooth services. Worms such as Commwarrior back in 2005 made use of Bluetooth and MMS to propagate between handsets – but centralized command and control (CnC) was elusive at the time (thereby greatly limiting the damage that could be caused, and effectively neutering of any criminal monetization aspirations). More recently thoughh, as access to the TCP/IP stack within the handsets has become more accessible to software developers through better API functionality by the OS vendors, the tried and tested CnC topologies for managing (common) Internet botnets are be successfully applied and bridged to cover cellular botnet control.

Discussions about Smartphone botnets are making it to the media more frequently – albeit mostly the IT and security press – for example, “Botnet Viruses Target Symbian Smartphones“. Based upon the last couple of presentations I’ve given on the topic, lots of people are worried about cellular botnet advances – no more so than the Telco providers themselves.

Sure, there are plenty of ways of infecting a Smartphone – successful vectors to date have been through Trojaned applications, fraudulent app store applications, USB infections, desktop synchronization software, MMS attachments, Bluetooth packages, unlocking platform application downloads/updates, etc. – but relatively little has been publicly discussed about the use of exploit material. As we all unfortunately know, one of the key methods of infecting desktop computers is through the exploitation of software vulnerabilities. Are we about to see the same thing for Smartphones? Will cellular botnets similarly find that handset exploitation will be the way to propagate and install botnet agents?

In all likelihood, vulnerability exploitation is likely to a lesser problem for Smartphone – at least in the near future. Given the diversity in hardware platforms, operating systems and chip architectures, it’s not as easy to create reliable exploits that can affect more than one manufacturers line of product. That said though, some product lines are numbered in the tens of millions of devices, and the OS’s are becoming increasingly better at making the underlying hardware transparent for malicious software and exploitation. I’ll also add that there are plenty of vulnerabilities, “reliable” exploits up for sale and interested researchers bug hunting away – but at the moment there’s little financial gain for professional botnet operators compared to the well established (and much softer) desktop market of exploitable systems. But we have to be careful to not marginalize the threat, it’s worth understanding that botnets are already being developed and (in very limited and targeted distribution) are being used for installing botnet agents on vulnerable handsets.

This is of course causing increasing heartburn for the mobile telco providers – since their subscription models essentially mean that they’re responsible for cleaning up infected handsets and removing the malicious traffic, much more so than traditional ISP’s are. If a handset is infected, their customer will likely incur a huge bill and (as what typically happens) the Telco will not be able to recover the losses from the customer. Attempts to recover the cost from the customer will increasingly yield two results – 1) they won’t be a customer any longer and 2) the negative PR will have them rolling in pain.

Fortunately, as the cellular botnets become more common and sophisticated in their on-device functionality, they’re also going to become more mainstream and closely related to classic Internet botnets. What this means is that their CnC channels and infrastructure will increasingly be close to (or the same as) “standard” botnets. Which in turn means that cellular botnets can be thwarted at the network layer within the mobile Telco operator’s own networks (similar to what some major ISP’s are trialing with their residential customers) – thereby turning the threat in to something that they can protect against. How is that possible? Well, a quick browse of the Damballa website should provide a fair bit of insight in to that – and perhaps I’ll post a follow-up blog on key techniques sometime soon.

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.

Gold dust or Nuggets? A Hackers Tell

After a hard day's conferencing, security folks will typically end up in the hotel bar and, with odds often appearing to be in excess of 3:1, the conversation will inevitably encompass a discussion of which internal corporate systems are the most hacked/vulnerable/indefensible.

If the migratory cluster of bar stools and hotel chairs encircling the obligatory way-too-small table contains more than a pair of reformed hackers or pentesters, by listening in you'll end up gaining quite a bit of insight in to why the better hackers are so often successful (and you'll probably also pick up a few tell's for future reference).

While there's much literature and many tutorials to be found that explain the technical aspects of how to successfully compromise corporate defenses, exploit systems and ultimately extract data, there's actually very little "guidance" on which systems should be targeted and why, once you've breached the network. Sure, there's plenty of discussions covering the technical aspects of how to raise privileges (e.g. locating and exploiting the Active Directory server in order to acquire corporate user/admin credentials etc.), but which systems really provide the treasure trove?

Quite a few folks I've been speaking with will initially (and specifically) target the systems used by the corporate security teams. These systems are important for a couple of reasons; 1) internal security folks often have good access to a wide range of other systems that may be valuable and 2) By keeping an eye on the "watchers" you'll know when you're close to being caught and can stay a couple steps ahead. Personally, I think it's a ballsy move if you can pull it off - but it's not something I'd throw in as a priority. There are a lot of inherent risks in trying to tackle systems maintained and watched by the professionally paranoid - so it may be more prudent to gather better intel first.

Another primary target for some folks is to go after the obvious corporate data repositories - the backend databases, business intelligence systems and storage facilities. This mode of attack I'd associate much more with the quick "get in and get out of dodge as fast as you can" - maximizing the potential reward by sacrificing (IMHO) a fair degree of stealthiness and persistence. If typically works very well - and is an ideal tactic for "compelling result" penetration testing or hackers looking for rapidly monetizable data.

A tactic that I've always preferred (dependent upon the specific objectives of the pentest of course) is to initially locate and target the QA systems. For the folks that target the corporate secuity systems or go after the official data repositories, going after the QA systems sounds not only unexciting but also like a complete and utter waste of time. But hear me out first. QA systems really are a veritable treasure trove of corporate data. Consider the following:

1. Like a smelly hobo camped outside a high-street McDonalds, both security analysts and helpdesk alike tend to keep their distance from (what are typically) "unmanaged" QA systems.
2. QA systems often contain complete copies of the high-value corporate data so that development teams and QA/Testing personnel can actually test the applications correctly. You'll often also note that the more "valuable" a particular suite of data, application or business process is, the higher the probability that the QA copies of the data will in fact be real-time mirror images of live data.
3. Nobody ever "owns" the QA systems. They're always the last systems to get patched (if ever) and access controls typically hover between poor and non-existent.
4. When was the last time anyone bothered to look at the audit logs? With so many ad-hoc system use, trials and testing, it's a nightmare from both a detection and forensics perspective. QA systems are an ideal place to recon an enterprise network from and retain a persistent toe-hold within the organization.
   
5. QA systems typically have "temporary" access to to all the core business systems and data repositories within a corporate network. By "temporary" I mean in theory if you listen to the server administrators - in practice they can be considered permanent gateways.
6. Testing systems are typically littered with copies of entire development source code trees - making it a piece of cake to acquire the latest business logic, intellectual property or hard-coded/embedded passwords to other critical systems within the corporate entity.
   

Sure, there's plenty of other opportunistic systems to go after within a target's organization once they've been breached, but with all other factors being equal, there are certain tactical tell's that can be readily associated with the types of hackers and pentesters out there (the previous three just being examples I heard/discussed repeatedly over the last couple of weeks).

The primary objectives and "styles" of the hackers/pentesters reminds me a little of those old Western gold-rush films. Rounding up the Sheriff and his deputies and locking them up in their own jail before robbing the bank is a little analogous to going after the security folks/systems. Meanwhile the priority targeting of the corporate data repositories reminds me of a stagecoach robbery - the pounding of hooves and guns blazing. Yet going after the QA systems reminds me of a movie in which the villains dig up the ground under the saloon and casino - hoovering up all the gold dust that patrons had lost over the years through the cracks in the floorboards.

Grab a beer with a friendly hacker or pentester and ask them how they'd earn their gold.