The SecureWorks Counter Threat Unit^SM (CTU) has been carefully monitoring the activity of the Monkif/DlKhora botnet. This bot is an example of a Downloader trojan, in that its primary purpose is to receive instructions to download and execute other malware. The trojan also attempts to disable anti-virus and personal firewall software to maintain its foothold on the system.

One interesting technique the Monkif botnet utilizes to hide its intent on the network is to encode the instructions to appear as if the command and control server is returning a JPEG file. The server sets the HTTP Content-Type header to “image/jpeg” and prefaces the bot commands with a fake 32-byte JPEG header. The bot checks if the header matches and decodes the rest of the response to retrieve its commands. The commands are encoded using a single byte XOR with 0×4. The malware that CTU has observed being installed by Monkif is a BHO (Browser Helper Object) trojan commonly referred to as ExeDot, which performs Ad Hijacking and Ad Clicking.

The botnet makes no attempt to pad the commands to make the data size representative of a true JPEG. In addition, the data will not parse to a legitimate JPEG. These attributes may provide opportunities for generic countermeasures to detect the traffic by identifying malformed image data.

One of the provisions of the Communications Decency Act (Section 230 of the US Code) established a safe harbor for ISPs so that they couldn’t be held liable for the speech of their users. If you take umbrage at something someone said on the Internet, your remedy is to sue the speaker, not their ISP or telephone company.

That safe harbor is pretty well known, however there is another provision in title 230 that hasn’t received quite as much attention. Subsection (c) (2) provides protection for “Good Samaritan” blocking of offensive material. This states that service providers are not liable for voluntarily blocking access to offensive or otherwise objectionable material.

Kaspersky’s anti-malware product displays warnings and blocks the operation of Zango’s software, which is classified as adware. Zango wasn’t very fond of this practice and thus sued Kaspersky for tortuous interference in Zango’s business. Kasperksy was able to obtain a summary judgment in trial court because of the 230 safe harbor. Zango appealed to the US Court of Appeals for the Ninth Circuit. That court recently handed down a judgment for Kaspersky.

One of the arguments Zango raised in the appeal was that Kaspersky was selling a product, not offering an interactive online service. The court found that Kaspersky’s products count as an interactive computer service based on the fact that they disseminate updates via the Internet. This definition of interactive computer service should be broad enough to cover a good chunk of the security industry.

I am not a lawyer, this post does not constitute legal advice, nor would I be competent to offer such advice. The following is just the speculation of a security geek that thinks that our legal system should be accessible to anyone willing to do the requisite research. That said, for those organizations that would not be covered, I wonder if including a feature that allows users to update content via the Internet would be enough to extend the liability protection to that organization.

Another interesting side effect of including security services under the liability shield is that it could be used to try to shield an individual security researcher from liability. The exact wording of the statue states that no provider or user of an interactive service shall be held liable for:


"any action taken to enable or make available to information content providers
or others the technical means to restrict access to [objectionable content]"


If a researcher were to publish security research online that would allow others to develop countermeasures, that sure sounds a whole lot like it would be included in that definition to me. In theory, this could be used to shield researchers who publish vulnerability information. While this law may offer protection to those who disclose information in a number of different ways, SecureWorks supports and follows guidelines for responsible disclosure.

If this legal tactic were to be accepted in a court of law, there could be two unintended restrictions to when this defense could be employed, that some might consider leading to undesirable outcomes.

First, as the law only protects users or providers of interactive services, this liability shield may not work for someone presenting information in person or dead tree format. Second, if the requirement is to give information which would allow others to be able to restrict access, it might require enough information to write a signature to block the attack. So this could lead to a situation where revealing information online, full disclosure style, could have more legal protections then giving a talk at Blackhat for example. But then again, perhaps videotaping the talk and putting it online would be enough for conferences to be counted as an interactive service. It would be nice to have another tool to defend against legal threats that have unfortunately prevented some security talks.

In this post, we will be taking a look at the Tornado Malware kit. Tornado is a Russian web-attack kit used by hackers to compromise as many machines as possible. “Out of the box,” it comes with 14 exploits, although users have space to add more, thanks to a modular design (handy!). Visitors are greeted with the following login prompt:

The spelling throughout the application is generally poor. After login, users are taken to the stats page (a dashboard of sorts) which shows information about the traffic the kit has seen so far, broken down by OS and web browser. The Tornado kit has a target URL which attackers direct as much traffic to as possible. Once an attacker is able to lure a visitor to the malicious URL, Tornado chooses an exploit most likely to succeed and serves it up. It does this by analyzing the visiting browser’s User-Agent header. Here we can see part of that process:

In some cases, attackers place the link into other compromised sites, so that visitors may have no idea they are browsing a malicious site. Buried in the obfuscated code, several requests are made to Russian web sites. This allows the author of the kit to monitor where the kit is used, and make sure that it is being used, you know, “legally”.

If the browser exploit attempt is successful, the victim’s machine will make a request to download an EXE from the attacker’s site. At this point, it is game over. The loader that Tornado uses is configurable, so it’s easy to add additional payloads, or change to a different payload altogether, as seen in our final screen shot. Overall, this simple exploit kit has some worrisome capabilities.

By Hunter King & Nick Chapman

The saying goes: “What happens in Vegas stays in Vegas.” Well, apparently not during the week of Black Hat USA 2008. Black Hat is one of the world’s largest and most well known security conferences. Several members of the SecureWorks Counter Threat Unit^SM had an opportunity to attend and we’d like to share some brief highlights from a few of the talks.

There were many highly renowned speakers sharing their expertise, including our own Joe Stewart speaking about the Storm botnet. Informal conversations with other attendees were also extremely valuable. With all this knowledge and experience in one place, Black Hat really is like drinking from the InfoSec fire hose. We don’t want to keep you in suspense any longer, so here are a few samples from some of our favorite talks.

SQL Injection Worms for Fun and Profit

Readers of our previous blog postings will know that we, like many others, have been keeping an eye on the recent waves of mass SQL injection attacks (here, here, and here). Justin Clarke of Gotham Digital Science gave a turbo talk about this very topic. The main thrust of his presentation was that this is just the beginning. The current attacks, although widespread, are very limited in scope. The attackers are only targeting websites using Microsoft SQL Server for a backend database and only targets Microsoft ASP (and more recently Cold Fusion) websites. Once a website has been compromised, the payload is only targeting users who visit that site. Nasty attacks that could be on the horizon include privilege escalation / attacking the database host OS, attacking HTML Forms, scanning internal corporate networks / DMZs, and more. Today the attackers are using the Google search engine to identify potentially vulnerable systems and have successfully compromised literally hundreds of thousands of websites. It would be quite feasible to use Google search results to further refine their focus, generating a targeted attack against an entire business vertical or just a particular organization.

Get Rich or Die Trying – “Making Money on The Web, The Black Hat Way”

Jeremiah Grossman and Arian Evans gave a wonderful talk about real world ways to monetize attacks, both against technology and flaws in business logic (Arian’s other talk about encoding issues was also very interesting). What I found fascinating is how, as the amount of money involved increased, the amount of technical expertise required to pull off the hack decreased. The presentation started by talking about manually solving CAPTCHAs for profit. Initial offers were for $10 per 1000 CAPTCHAs solved, which works out to an income of about $50 a day. However, free market competition drove that price down to as low as $2 per 1000 CAPTCHAs.

Another example of ways hackers can make large sums of money that don’t require a high degree of technical sophistication was through information leakage. An Application Service Provider (ASP) which provided services to banks had been revealing sensitive information in an error message. Only three items of information were actually required to access an account through the ASP – a client identifier, a bank identifier and an account number.

These parameters were supplied via HTTP GET variables, easily modifiable by anyone with a web browser. If these three items didn’t match, the web application was kind enough to tell the visitor that “Account X belongs to Bank Y.” If a visitor used the correct bank identifier but other parameters did not match, the website would inform them you that “Bank Y belongs to Client Z.” The website was also only checking that a visitor was authenticated – it did not verify that the user was authorized to access a particular account. This could easily be exploited for profits in the tens or hundreds of thousands of dollars.

A third example requires even less technical expertise. A website featuring press releases (including profit and loss statements) would add press releases to their site ahead of their official release date — they just wouldn’t link them from the main page. However, the press releases were stored on sequentially numbered web pages, so it was a trivial task to identify and access a “hidden” press release. This would allow outsiders to have access to P&L information for publicly traded companies before the market closed. Hackers exploited this to earn over 8 million dollars on the stock exchange market.

The critical lesson here is that all avenues of attack must be considered. This is especially true when dealing with how the business logic is implemented at a technical level. This is very difficult to do, because it requires knowledge of the business processes and a grasp of some of the technical details that drive those processes. If you’re not aware of how these interact, rest assured that there are many people using your systems, and it only takes a single one having that “Eureka!” moment where they find a critical flaw. This can lead to financial losses in the hundreds of thousands or more. What’s even worse is that some of these “attacks” aren’t even illegal, not even in the United States.

Malware Detection Through Network Flow Analysis

The always entertaining Bruce Potter, founder of The Shmoo Group, gave a talk titled “Malware Detection Through Network Flow Analysis.” In it, Bruce emphasized the need to quickly detect compromised machines in order to minimize damage. Given the rate at which client-side attacks presently occur, compromise is, for many, inevitable. Quick detection of infections becomes an increasingly important tool in the defender’s toolkit. Bruce advocates analyzing network traffic data for statistical anomalies. For example, a desktop which sends out twice as much data as it receives is likely part of a botnet. Without NetFlow data (or similar), this infection may go completely unnoticed. Bruce also advocated including frequency distribution graphs alongside traditional time-based graphs as a method of quickly identifying potential network issues. Incorporating these techniques won’t stop the bad guys, but could greatly minimize the damage done once a compromise does occur.

Circumventing Automated JavaScript Analysis Tools

Billy “AJAX” Hoffman’s talk, titled, “Circumventing Automated JavaScript Analysis Tools,” focused on why current attempts to run malicious JavaScript within sandboxes are failing. With the increasing popularity of sandboxes, including SecureWorks’ own Caffeine Monkey, JavaScript-based malware is being forced to play “catch-up” with x86 malware with regard to sandbox detection. These techniques revolve around writing code which behaves differently in a browser than in a sandbox. Using the “quit” command within a try/catch block is a perfect example. This command, which does nothing when run from within a web browser, will exit Mozilla’s standalone JavaScript interpreter. Billy listed at least 20 pages of similar techniques (each needed to be coded for explicitly). Two main alternatives exist:

1) Analyze malware using a real browser within a VM. JavaScript can tell when being run from within a sandbox, but not while running in a real browser in a VM.

2) Modify the Mozilla JS interpreter to run in headless mode. This would break the majority of Billy’s attacks, and raise the bar significantly for malware authors. The analysis needed to detect this form of inspection would be easy to identify and evade.

Writing good antivirus software is hard. Just ask the developer at a major antivirus company who was infected with the Coreflood trojan on his personal computer for over a year. Perhaps he was just testing their product, but it seems odd to have allowed the trojan to capture some of his personal information. Fortunately the antivirus developer was not a domain administrator on the company’s network, so Coreflood didn’t spread to every other system in the Windows domain like it did at several other businesses, hospitals and government organizations.

One might assume that by now, that the antivirus company, employing the developer, would detect the specific version of Coreflood that he was infected with on February 23, 2007. Sadly, they still do not. The reason probably stems from the overarching problem that all antivirus companies face, and Coreflood is as good an example as any. There have been dozens upon dozens of Coreflood variants over the last six years. Virus and trojan authors these days are in it for the money, and more infections equals more money. And less detections equals more infections. So constantly rebuilding the Coreflood trojan to evade detection is part of the bad guys’ business model. And it’s easy – programs that scramble a trojan’s code to avoid anti-virus detection are available everywhere and most of them are free. The antivirus industry is really fighting a losing battle – they have to invest as much effort in reverse-engineering executable packers as the whole of the criminal underground spends in writing them, and this translates into a lot of time spent (and profits lost), since it always takes longer to reverse-engineer something than it did to engineer it. Therefore it’s not surprising that AV detection rates for new variants of most malware are simply abyssmal.

But while the packed Coreflood code might change weekly, it is interesting to note that the network traffic pattern that Coreflood uses when checking in with the controller has not changed substantially in the last two years! The intrusion (really extrusion) signatures we wrote for our clients back in 2006 are still effective at locating Coreflood infections today. It goes to show that fighting malware requires a multi-faceted approach: defenses against the infection vectors (exploits and social engineering), system-level protection, and extrusion detection to fill the gaps. Increasingly we are using our iSensor(™) intrusion prevention platform to do just this. Every day our malware research department analyses a large number of malware samples in order to improve our clients’ security posture and prevent information leakage by botnets like Coreflood.

Of course, we’re not alone in recognizing extrusion detection as a key part of defense-in-depth. For example, the Emerging Threats project maintains sets of extrusion-detection rules for the open-source Snort IDS platform. Since Snort operates in detection (instead of prevention) mode, using it won’t stop data leakage or malicious commands from being downloaded by infected systems, but it can at least alert network administrators of infected workstations so that they can respond, and hopefully re-evaluate their defenses based on the frequency and types of infections occuring on their network.

At its core, the determination of malware versus non-malware with 100% certainty can only be accomplished by knowing the intent of the author, something that can’t always be divined by scanning the bits and bytes of the code. Thus, no product can ever provide a 100% solution against past, present and future malware infection. However, extrusion detection and prevention continue to be invaluable tools in today’s world, where botnets lurk in the shadows and siphon data from every corner of the network.