Posts Tagged ‘security’

Host Intrusion Prevention – FAIL

Thursday, August 19th, 2010

Earlier this week NSS Labs were able to share with me a copy of their latest endpoint protection product group test – covering Host Intrusion Prevention. Their test regime was designed to identify the effectiveness of the most popular corporate endpoint protection products against the exploits most commonly encountered during Internet surfing – i.e. measuring the products capability to withstand every-day drive-by-download attack vectors.

The results, as a whole, were disappointing – but actually better than what I would’ve normally expected. By that I mean a handful of products could be deemed to have been “good enough” for everyday desktop protection against the standard drive-by criminal fare (which is a bit of a pleasant surprise* – but more on that heavily caveated surprise later), but most failed the test and some missed by an abysmal margin (which is more attuned to what I expected).

Some key findings taken from the report include:

  • Endpoint protection products differ up to 71% in effectiveness at stopping exploits, between 29% and 100%.
  • Based on market share, between 70-75% of the market is under-protected. Most vendors lack adequate protection against exploits.
  • Keeping endpoint protection software up-to-date does not yield adequate protection against exploits, as evidenced by coverage gaps for vulnerabilities several years old.

Endpoint protection suites are the absolute last line of defense against Internet threats and it’s deeply disappointing that they constantly perform so poorly against the threats they’re specifically designed to protect against. You’d think that with all the CPU, RAM and hard-drive capacity they gobble up that they’d carry their weight and perform better. Perhaps Intel (with it’s newly acquired McAfee) will be able to get this kind of protection in to the silicon powering our computers and do away with the cumbersome software suites that plague the performance and stability of our operating systems.

NSS Labs tested the products against 123 exploits grabbed from the wild (i.e. exploits that are in common use by Internet criminals and likely to be encountered by their preferred victims). Out of the ten products, only three managed to stop all the “original” exploits, and only one product managed to stop the alternative exploit versions. That sucks!

Seriously; that really does suck. To understand this better you need to appreciate the way in which Internet criminals construct their malicious drive-by-download sites. They don’t just randomly pick one exploit and hope it works against their victims computer, they try every single exploit they have available to them and cycle through the list until one of them works – and then install their malicious payload (e.g. botnet agent). This means that the endpoint protection product has to stop all of the exploits, or else its failed. Stopping 80% of the exploits is of no consolation. There’s no benefit to being “almost secure”.

The failure to handle the alternative exploit versions is most worrying to me (and any organization reliant upon that vendors endpoint technology). The “alternative” exploit versions reflect the way in which exploits are commonly refined and tuned by different criminal groups for inclusion in their exploit packs and drive-by-download sites. By missing the “alternative” exploits these vendors have failed on two critical counts:

  1. They’ve focused on detecting the nuances of the exploit sample, rather than identifying attempts to exploit the vulnerability. This is a subtle but significant evaluation of their core protection technology. Legacy signature systems focus on the code structure of the exploit – meanwhile preemptive technologies understand the protocol and/or data format that the vulnerable application depends upon and is exploitable via – thereby stopping any malicious code permutations that the criminals can think of or want to throw at it.
  2. If the product only caught the “original” version of the exploit and not the subsequent public alternative versions (which are similarly being distributed by the criminals), this signifies to me one of two equally depressing conclusions – (a) the vendors protection is marketing centric (i.e. skin deep) and coverage of the vulnerability is limited to “yes, we have protection – see it’s signature CBA321″ or (b) the vendors threat analysts do a very poor job and probably rely upon public analysis of threats rather than their own.

I know that I’m sounding pretty harsh in this blog posting, but this is serious business – and better protection is attainable. The customers of the vendor’s whose products failed to stop 100% of these endpoint exploit tests have an expectation for threat protection which obviously isn’t being met today.

– Gunter Ollmann, VP Research

USENIX Security Symposium

Tuesday, August 10th, 2010

This week the 19th USENIX Security Symposium will be kicking off in Washington DC.

Damballa’s researcher extraordinaire, Manos Antonakakis, will be speaking Thursday in the 2:00pm – 3:30pm slot on the topic “Building a Dynamic Reputation System for DNS“.

If you’re in town attending the conference, make sure you see this presentation!

What’s it all about?

The Domain Name System (DNS) is an essential protocol used by both legitimate Internet applications and cyber attacks. For example, botnets rely on DNS to support agile command and control infrastructures.  An effective way to disrupt these attacks is to place malicious domains on a “blocklist” (or “blacklist”) or to add a filtering rule in a firewall or network intrusion detection system. To evade such security countermeasures, attackers have used DNS agility, e.g., by using  new domains daily to evade static blacklists and firewalls. In this paper we propose Notos, a dynamic reputation system for DNS. The premise of this system is that malicious, agile use of DNS has unique characteristics and can be distinguished from legitimate, professionally provisioned DNS services. Notos uses passive DNS query data and analyzes the network and zone features of domains. It builds models of known legitimate domains and malicious domains, and uses these models to compute a reputation score for a new domain indicative of whether the domain is malicious or legitimate. Our results show that Notos can identify malicious domains with high accuracy (true positive rate of 96.8%) and low false positive rate (0.38%), and can identify these domains weeks or even months before they appear in public blacklists.

– Gunter Ollmann, VP Research

Presenting @ BlackHat USA 2010

Monday, July 26th, 2010

This week Damballa will be represented at the 2010 BlackHat USA event in Las Vegas with me presenting on Thursday (29th July) at 11:15am. I’ll be covering the topic “Becoming the six-million-dollar man” – a closer look at some of the more sophisticated ways in which criminal botmasters are monetizing their botnets and laundering the proceeds, and how they’re becoming millionaires.

Come join the fun. I can probably guarantee that you’ll learn several of the new ways for making money from botnets – such as identity laundering and reputation hijacking.

Here’s the abstract for my presentation:

Starting a life of Internet crime is easy; in fact you’ve probably already doing it as far as the RIAA is concerned. Now that you’ve chosen to embark upon a new career, how are you going to get dirty, filthy, stinking rich? How do you become a millionaire?
The tool of choice has got to be botnets. Building them is just the start. How do you monetize the tens or hundreds of thousands of machines under your control? Should you harvest confidential and personal information from the victims, or would it be more prudent to become a specialist service provider to other botnet operators? Which models work best, and how can you become a six-million-dollar man within a year?

– Gunter Ollmann, VP Research

It’s Safer to Write Your Password Down

Tuesday, July 6th, 2010

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. abc<siteName>123
  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.

– Gunter Ollmann, VP Research

The FTC Wake-up Slap

Friday, June 25th, 2010

When do your corporate security practices warrant FTC monitoring? When you fail to maintain the minimum levels of system protection and customer’s private data happens to drip from your porous applications.

“When a company promises consumers that their personal information is secure, it must live up to that promise,” says David Vladeck, head of the FTC’s Bureau of Consumer Protection. “Likewise, a company that allows consumers to designate their information as private must use reasonable security to uphold such designations.

“Patrons of social networking sites may choose to share some information with others, but they still have a right to expect that their personal information will be kept private and secure,” he says.

(courtesy of Byron Acohido’s The Last Watchdog blog)

This follows the news that Twitter has agreed to settle with the FTC after charges of failing to safeguard their customers personal information. The net result? Twitter must establish a comprehensive security program and will be subject to government monitoring for the next 10 years.

Personally I’ve got to wonder whether other organizations are going to come under similar levels of examination from the FTC in the near future. Take for example the recent disclosure of personal iPad customer data via flaws in a key online management application – AT&T iPad Breaches Are About App Security, Not Mobile Devices, Experts Say.

Their are of course a couple of obvious questions here:

  • What is the minimum level of security required for protecting a customer’s personal data?
  • What constitutes a Comprehensive Security Program?

These two cases (Twitter and AT&T) share a number of similarities – poor application logic, weak security implementations, and ease of compromise. While “minimum” security levels can be interpreted in many different ways, since there’s no agreed or definitive manual that organizations can use, I’d be inclined to offer a couple nuggets of security advice.

  1. Don’t be the “lowest hanging fruit” in your business sector. Look around. For example, if all the buildings around yours have 9′ high barbed wire fences and bars on their first floor windows, it’s more than likely a great idea to invest minimally in the same level of security. Similarly, when it comes to corporate security make sure you have a functional defense in depth system of interlocking (and overlapping) protection and detection technologies – and know how to use them!
  2. Make sure you’re testing your own defenses! At a minimum, you need to run the standard suites of automated vulnerability scanning and probing tools – both at the network and application levels. Any newly-minted CISSP graduate will know whats required in order to achieve this basic level.

But that really is a minimum level of security proficiency. It doesn’t offer you much more protection than the equivalent of ensuring that you’re keeping your shoelaces tied up so that you don’t trip over them (like any mother tells her kids). Obviously, you should be aiming to raise your security awareness beyond this (e.g. “don’t run with scissors”) – especially if you’re required to pursue a “Comprehensive” security program.

– Gunter Ollmann, VP Security

Corporate Espionage and Tethered Criminal Actions

Wednesday, January 13th, 2010

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

A Not-So-Obvious Botnet Cleanup Strategy

Monday, April 13th, 2009

A problem encountered by most enterprises upon learning that their network is infested with multiple bot agents is that of devising a remediation strategy. While the obvious solution is to shout loudly at the host-based anti-virus vendors and tell them to get their act together, there are several reasons why that often proves to be insufficient.

For one thing, the fact that a bot agent was detected by network sensors as being present upon a host that was already running an anti-virus product is probably a pretty good hint that the host-based AV vendor didn’t recognize the malware in the first place and inevitably doesn’t have a method for removing the infection. In order to develop this detection/removal capability, the AV vendor is going to have to obtain a sample of the malware on an infected host first.

Depending upon the nature of the support agreement between the enterprise customer and the host-based AV provider, it may take a while before a malware analyst completes their autopsy of the supplied sample and develops the necessary detection signature and host cleanup process. Given the tens-of-thousands of new malware samples received daily by AV vendors and the fact that only a small percentage of those will actually be inspected by a flesh & blood analyst, their priority is going to be on the most frequently encountered malware or samples gathered from big and vocal enterprise customers. So, with that in mind, keep on shouting at your preferred AV vendor…and don’t let up.

Another thing to bear in mind is the fact that bot agents, by their very nature, liaise with a central C&C to receive updates. These updates are increasingly focused upon updating the core components of the malware installed on the infected host (rather than just new instructions for actions to be performed). The net effect of these updates to the bot agent are that the malware present on the host is constantly changing and that a sample gathered one day (and any remediation steps planned because of it) could have changed overnight.

A few years ago we saw malware authors adopt the concept of serial-variant attacks (basically releasing new malware agents every few hours faster than AV vendors could distribute new signatures in order to stay ahead of detection systems), and I wouldn’t be surprised if we begin to observe similar tactics occurring with the bot agent at the local host level in the near future.

One further thing to bear in mind when attempting to remediate a botnet infestation is to consider the core functionality of bot agent, in particular its capabilities for keylogging and observing host authentication credentials. If the malware has these capabilities, it’ll probably pass them through to the central (remote) C&C or to other agents within the same network (via peer-to-peer communications). This means that you’ll probably have to remediate all infected hosts at the same time because if you miss one, that host can then begin to reinfect the remediated hosts using those previously stolen credentials.

There are a few extra steps to the remediation phase that I’d recommend to enterprises seeking to clean up a botnet infestation:

  1. Before gathering malware samples to analyze and develop clean-up scripts to remove them from infected hosts, it’s important that any C&C communications are first blocked. This will prevent any remotely initiated reinfection pains as the botnet herder attempts to regain control of lost assets.
  2. If the botnet is known to (or suspected to) have peer-to-peer communication capabilities, the infected hosts will have to be isolated from all other local members of the botnet.
  3. As many large enterprises typically re-image infected hosts (basically overwriting the entire system with a known-good image), it is important that any default passwords (e.g. local administrator passwords and certificates) are automatically changed since these are precisely the types of credentials the bot agent would have sought to acquire (and extract) when if first infected the host.

- Gunter Ollmann, VP of Research

Dealing With Those Pesky “Unnamed” Threats

Friday, April 3rd, 2009

The curious thing about the cyber-threats that enterprises encounter today, is that the threats you can identify are already well on the way to being solved. For example, as I explained in my previous post, the fact that a piece of malware has been granted a unique name is a great indicator of whether it will in fact continue to be a risk to an enterprise.

It would be easy to appear alarmist and say “beware the invisible bogyman (wooo),” but I won’t, since there’s more than enough FUD like that circulating the security industry already. What I’d like to do instead is draw attention to the differences between an “invisible” and an “unnamed” threat.

When I use the term “invisible” I’m not referring to any particular uber-stealth technique (rootkit technologies, code obfuscation, etc.) or some kind of computer code voodoo, but rather the threats that can’t be observed because you simply don’t have the technology to identify them in action. An analogy would be FM radio. You can be sitting at your desk and you inherently know that there are FM signals passing through the airwaves and your body, but unless you have the right piece of technology (i.e. a radio) there’s no way you can “observe” the signals, let alone interpret them.

The same applies to the malware built and used by criminals today. The channels they use to communicate with infected systems and take remote control of them are a bit like FM radio. The communication is flowing, but without the right receiver you might as well be using binoculars to study the radio mast. In the context of crime-ware, you need to appreciate how these command and control (C&C) techniques work, and to then deploy the correct technology capable of identifying and intercepting them – at the right location.

Which brings me to my second definition – “unnamed.”  For some malware sample to have received a name, it means that someone, somewhere, must have obtained a copy of it (at some stage), done some research in to it and built a specific detection algorithm to detect future instances of it. There are two obvious problems with this kind of (legacy) anti-malware approach:

  1. It doesn’t help if you happen to be the first infected site/customer.
  2. With tens-of-thousands of new malware samples being received daily, how is an anti-virus vendor going to name them and write a signature to cover each one?

The bad guys know this hence their increased investments in stealthing and advanced C&C techniques and the resultant volume of “unnamed” threats. In the context of malware, an unnamed malicious tool or technology is essentially “invisible” to the protection technologies and therefore not identified, reported upon, protected against nor remediated.

Which takes me back to this week’s big threat – Conficker. From both a prevention and a remediation perspective, this named threat has already been fixed within enterprises for several weeks (months even if you trace back to when it first inherited its name(s)). That said, looking at the kinds of C&C reliant crimeware and bot agents typically encountered within the enterprises Damballa works with, Conficker was always going to be a non-event – “ it wasn’t even statistically significant.

Over 85 percent of the infections we commonly see within enterprise are “unnamed” and average about 10 infected hosts per “unnamed” crimeware sample.

What that signifies to me is that the criminals are being picky about their targets and intentionally keeping infection volumes small so they can remain below the anti-virus radar. Why? Well, if you’re an anti-virus vendor, it costs real dollars for each and every signature you produce  therefore you tend to be choosy about what threats you develop signatures for. Low volume threats, encountered within a single customer’s environment, are difficult to justify.

From the criminal malware authors perspective, it costs them nothing to tweak their DIY malware creator tools and generate yet another unique and “unnamed” piece of malware.

Looking forward, I believe that enterprises can expect the professional criminals to continue to lower the volume crimeware and bot agents they choose to deploy within targeted enterprise yet have them report to the same central C&C infrastructure for management.

Fancy purchasing some used binoculars?

– Gunter Ollmann, VP of Research