APT Dilemmas

The last month has seen a plague of comments and "expert" opinions materialize related to the Advanced Persistent Threat (APT). In the majority of cases, I'd have to class those very same comments and opinions as ambulance chasing tripe - by people that either have over active imaginations or are just simply looking to capitalize on the confusion generated by the media.

Sure, we're all entitled to our opinions, but there's more to all this. If many of these comments and expert opinions had been directed at an individual or corporation, those "experts" would have found themselves in court over slander charges many times over by now. So perhaps they're personally lucky that their ignorant and ill-educated comments haven't resulted in such actions. On the other hand though, they would appear to be adding kindling to a growing wildfire which will likely affect us all.

There are of course multiple camps of thought in every argument. For many (former) military types, it often appears to be about Nation States driving and incentivising hacking teams to target the assets of a foreign entity. That's they way they were trained to think. Similarly, Nationalism comes in many shapes and forms - and varying degrees of dedication - ranging from wearing a lapel pin through to chanting a pledge of allegiance to a flag (or deity, or prophet) each day. Every country, population or group has different levels and ways of showing nationalistic pride or reverence.

I believe that this applies greatly to APT's. The ability to acquire, retain and motivate a team of hackers capable of orchestrating and executing an APT campaign against a target (global conglomerate, strategic technology provider or government department, etc.) goes beyond meeting a specified financial compensation plan. APT campaigns aren't for the feint of heart. They require a degree of dedication not normally seen in most cyber criminal attacks.

That is not to say that someone can't simply go online and hire a bunch of hackers and build out a team to launch an APT campaign. That's not particularly hard - especially if you've got the cash. However, to keep a campaign flowing and obtain the level of persistence needed to keep the cross-hairs on a target for a year or more - well, that requires something more.

For one thing, running such a long campaign is probably going to need a core team that shares similar (if not identical) core values - nationalistic, political, religious, etc. - and is willing to dedicate the time needed. The dedication element can be brought easily enough, while the core values aspect means that the hacking team will likely have shared many experiences in the past. This of course doesn't prevent the campaign from engaging other external entities and subcontracting out either more specialist attacks or delivery options, but it does mean that tactical elements of the campaign can be passed on to third-parties as and where needed.

So, the dilemma with APT's is that they're a campaign strategy rather than an exploit, hack or attack vector. Which of course confuses many people who think of things solely in terms of attackers and tools - rather than objectives and motivations.

Would I class APT's as nation-state strategies serving as a precursor or reconnaissance for cyber-war? In some extreme cases, yes. I've met and probably helped train (in some fashion or other) several of the individuals that work this angle and are prepared to engage in these kinds of activities. However, many more of these people would refuse to engage in these activities out of nationalistic pride or prejuidice - but are only too happy to offer their persistent attention and services for a fee; being ideal candidates for longer term corporate espionage (e.g. back-dooring of oil pipeline control systems, targeting pharmaceutical research laboratories, accessing patent filing and tracking systems, etc.).

Then again, motivations for engaging and conducting an APT campaign can vary a lot - searching for UFO evidence, saving the whales or even targeting car manufacturers that attempt to hijack and steal other peoples Internet domain names - are all past causes capable of wedding a team together and working towards a common objective.

So, a word of advice then. It's dangerous to think of APT's as being wielded solely by nation-states. Unfortunately APT's are a fact of life - and have been so for well over a decade now. It's just that they've only been spoken about in hushed voices within closely closeted communities before Google said enough is enough to the secrecy.

Internationalized Domain Names and IPv6 Security

There are three fundamental changes happening right this minute to the Internet we all know and love - each of which will allow it to grow and allow more people to access it or profit from it. As we know from experience, nothing ever stands still for the Internet. Like life on the African Savannah, the old and the sick are easy prey to those who are faster and more agile. Old and vulnerable software, along with aging infrastructure, quickly fall prey to swift and orchestrated attacks from around the world.

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

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

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

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

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

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

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

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

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

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

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

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

Security B-Sides - San Francisco

A number of people suggested that I offer to speak at the Security B-Sides next month when I'm in San Francisco for the RSA Conference. It looks to be an interesting collection of speakers and topics - but if you'd like me to speak, it would appear that you'll need to vote for my talk proposal.

To vote, go to your twitter account and send the following tweet:

I vote for "Your Computer is Worth 30 Cents" by @gollmann #BSidesSF

Whats the proposed topic?

Your Computer is Worth 30 Cents

In case you haven’t noticed, there’s a war going on. Malware vendors, SEO consultants, exploit pack developers, content delivery specialists and botnet masters are battling for control of your computer. They’re not battling you or the security systems you’ve deployed – they won that war quite some time ago. No, they’re battling each other over who gets to own your computer – and consequently who gets to make money from it.

The botnet ecosystem is evolving at a rapid pace. Specialized services have come to fill every niche of the hacking world. The frontline is rarely the mechanical process of exploitation and infection – instead it lies with innovative 24x7 support and helpdesk ticketing systems – quality of service is the competitive edge. How much is your computer worth to them? The price point is dropping day-by-day, but 30 cents is a pretty average trade value. Why is it so low? Because your computer is only part of the ecosystem – and a commodity one at that.

Messing with Virus Scanning Portals

OK, so there's been a bit of hubbub surrounding Kaspersky's experiment in abusing the sample sharing ecosystem that has evolved from the VirusTotal virus scanning portal. No surprise, just another example of another security feedback-loop that can be abused for good or ill purposes.

So, changing hats for a minute, I decided to think a little more on how you could intentionally abuse this feedback-loop if you set your mind to it. Needless to say, the opportunities for the so-inclined to mess the system up are present in abundance.

The new blog entry has been posed over at the Damballa site - Killing Antivirus, One DLL at a Time.

Is it likely that someone will do this? hell yeah! ;-)

Network ADS - Playing at Botnet Detection

With botnets and more recently APT's plastered across the news, you'll struggle to find a security vendor that hasn't spent a furious couple of weeks repositioning their preemptive detection technologies as "anti-botnet" or "anti-APT".

Needless to say, digging a little deeper in to these technologies - beyond their cursory marketing spin - is probably a good idea, especially if your company executives are thrashing about looking to take any steps that'll keep them from being the next Google-like victim and making headline news.

Yesterday I pulled together my thoughts on the use of network-based Anomaly Detection Systems (ADS) in their capacity as botnet detection tools. In a nutshell, NADS is fine for dealing with those big and noisy Internet botnets that everyone writes about in the news, but not much chop against the types of botnets normally found successfully operating within enterprise networks.

My thoughts and analysis can be found on the Damballa blog - Detecting Botnets with Network ADS - and is also cross-posted below...

-------

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

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

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

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

Botnet detection & mitigation strengths:

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

Botnet detection & mitigation weaknesses:

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

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

Ablative Security

The threats facing enterprise networks are incredibly diverse. Attack vectors are constantly changing and a never-ending sea of zero-day vulnerabilities plague those responsible for assuring corporate defenses.

While I'm familiar with just about every host and network security technology on the market today, I've been wondering if there are alternative ways of handling the quadratic equation of threats versus protection.

A concept I'm toying around with relates to Ablative Armor - essentially the concept of a protective armor that is (partially) destroyed in the process of defence - and whether it has legs from a network security perspective.

Ablative materials were used to protect returning space re-entry vehicles for a time, and are currently used as advanced "reactive armor" on heavy tanks and other front-line vehicles. The material and reaction type doesn't matter here for this discussion - merely the fact that these kinds of technologies provide some of he most advanced protection around. However, while they're carrying out their protection, they are similarly consumed by the defense - but (most importantly) leave the key equipment untouched.

Does ablative protection exist in IT security today? In some ways, perhaps it does. While at ISS, we came up with a technology called Buffer Overflow Exploit Protection (BOEP) which was designed to monitor system memory and, if it saw anything that looked like exploitation of a stack overflow, caused the host to immediately shutdown or reboot. BOEP works great as a preemptive protection technology - and in a way you could argue that by causing the system to reboot in this way is inelegant, but it may partially fit the bill of "ablative".

Perhaps the use of active honeypots/honeynets could constitute ablative security? They're throwaway systems designed to lure attacks (and attackers) to them - for both study and diversion - and are generally consumed in the process (i.e. once they're infected/compromised, they can't really be trusted and used for other tasks). But, at the end of the day, perhaps honeypots/honeynets aren't really a defense after all - being merely telescopes for studying attacks rather than front-line defenses of critical assets? Probably.

What about sinkholes? By dynamically/automatically hijacking the command and control domain names used by botnet nmasters and diverting all traffic to a sinkhole - does that constitute an aspect of ablative security? Maybe - after all, once you sinkhole that domain, neither the attacker or target can reuse that domain (or IP address) for much afterwards - and the attackers are alerted to who the defenders are. But still, I'm not so sure.

So, what would ablative security (or armor) look like in a network security sense? I doubt that we'd want the firewall to suddenly start smoking like a Gemini heat shield and shut itself off (permanently) upon thwarting the latest zero-day exploit.

If ablative security revolves around the targeting system being consumed in the process of thwarting an attack, perhaps automatic nuke-and-pave host-level responses are in order. For example, a virtual watcher program monitors the health of the virtually hosted operating system a user is using. They browse a malicious drive-by-download Web site, the "host" gets infected, and starts doing bad things. The canaries within the compromised "host" inform the virtual watcher, which then notifies the user to the fact that they're compromised (perhaps even telling them to take a couple of minutes off to grab a coffee), then automatically proceeds with re-imaging the "host" from a known good/save version. In this model the "canaries" are consumed in the defense of the system.

I think that this approach may be one take on the concept of ablative security, and there must be others. You could argue that the use of canaries for detection borders on honeypot functionality or something else. That said, there's nothing to say that the canaries have to exist within the host environment - and could just as easily (or perhaps more easily) exist at the network level instead.

My gut feel is that the concept of ablative security has a degree of unseen usefulness in protecting against some of the threats out there today and coming at us in the future. I'm going to ponder on it for a while. If anyone has thoughts on the topic, I'd love to hear them.

Whats more important - preemptive, or post-preemptive?

Preemptive security technologies - they're great, and you can't beat them. Well, that's how it's supposed to work anyway. If only life was so simple.

The core idea behind preemptive protection technologies is to detect and stop entire classes of threat from successfully compromising the integrity of a host, network or application. Sales and marketing teams are only too eager to throw around the "preemptive" term - which can lead to rather embarrassing discussions between customers and technical engineers as the two have work out why a particular threat that was supposed to have been stopped, managed to get through the defenses. Its very rarely because the "preemptive" technology failed to to what it was designed to do - and almost exclusively because of nuances in the attack.

For example, there are litterally dozens of technologies out there being touted as "preemptive" protection against drive-by-download attacks. Some of these technologies focus upon detecting the presence of a shellcode payload, with others may hone in on JavaScript obfuscation techniques. However, despite these preemptive detection technologies, there is a growing list of vectors that bypass each technology. For example, drive-by-download attacks that use Flash scripting instead of JavaScript, or embed the shellcode in a different file - rather than within the JavaScript. The net result is customers scratching there heads and looking for answers. The nuances will often escape them - and the vendors R&D team will have a few late nights adding detection capabilities for the new evasion technique or encoding scheme (if they're lucky).

Don't get me wrong, "Preemptive" protection is damned important. You need it a lot more than some just-in-time signature update. But you've also got to realize that the more ground-breaking the "preemptive" protection is, the narrower its focus is in threat mitigation.

Whats more important than "preemptive" protection? In my mind its post-preemptive protection detection - i.e. being able to rapidly detect when all your combination's of "pre" protection didn't quite work, and your network got nailed despite the effort (and resources) you expended. If you focus exclusively on trying to prevent hosts, networks and applications from being compromised, you're going to have a damned hard time detecting when your systems do in fact get p0w3d by some Internet criminals.

This is particular important when you're facing a more organized and motivated opponent - such as those running an APT operation against your organization.

I discussed this in more detail the other day in my Damballa blog - “Preemptive Protection” Isn’t – If You’re Battling APT’s - and cross posted below...

------>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

FailSafe

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

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

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

Advanced Persistent Threats

I've been getting lots of questions on what precisely is an Advanced Persistent Threat - or APT for short - from all kinds of angles.

As such, the Damballa team have created the executive two-pager that helps answer "What is an Advanced Persistent Threat?"