Protecting Your Malware IP Investment

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:

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.