The fight against malware is a cat-and-mouse game. It is constant and constantly escalating. They make a move, you counter it, they counter your counter, lather, rinse, repeat.
What’s more: malware almost always has the advantage. Our software Malwarebytes Anti-Malware earned a reputation for having a high success rate in combating new in-the-wild malware infections: in contrast to other security vendors, we can often successfully remove malware that others can only detect. What that means in practice though is that we are often installed after-the-fact to clean up malware that is already entrenched in a system, waiting, holding the upper hand.
Given our position as a cleanup tool of choice in the anti-malware war, it is no surprise that malware quickly began to institute countermeasures against us. There were simple attacks and more sophisticated attacks, ranging from straight-up task-killing our process mbam.exe, to injecting a thread into it that removed the malware dynamically from our scan results window. I’ve even seen malware that insults our VP of Research Bruce Harrison (a.k.a. nosirrah) and our Assistant Director of Research Mieke Verburgh (a.k.a. miekiemoes) directly in the malware binaries:
C:UsersDougDesktop> strings svch0st.exe | grep “miekiemoes”
We love that stuff, it lets us know we’re getting to the bad guys.
It became apparent to us that we needed a way to ensure that Malwarebytes Anti-Malware would be able to run even on heavily-infected boxes. This is a tall order! Modern rootkits hook into the Windows kernel at a very low level, corrupting the “eyes and ears” functionality that the operating system is supposed to provide, and giving malware full control in theory. Indeed, a “certain community of Windows kernel experts” (hint hint) has been known to argue that anti-malware is doomed to failure from the start: a well-written rootkit can’t be beaten, they say, and infected users should just give up and format the hard drive. (Let’s put aside the fact that several rootkits these days have been known to persist even beyond a reformat!)
However, most users don’t like to hear that there’s no way to save their programs and data, and fortunately for us we’ve come up with plenty of innovative technologies to clean up real-world rootkits and save the box. It’s hard, but not impossible. We’ve never shied away from tackling hard problems at Malwarebytes, and we thought we could do it.
We began by examining the malware that attacked us. Quick disassembly showed that many so-called “rogue anti-malware” applications were filtering process creations, and allowing only a whitelist of known process names to start. For example, the malware would allow processes called “iexplore.exe” and “winlogon.exe” (known Microsoft Windows processes), but not “mbam.exe”. So, our support team began to instruct affected users to rename mbam.exe to one of the whitelisted process names. Then it would run, would clean up the malware, and all was well.
This trick worked surprisingly well for a surprisingly long time. We created a small automated support utility to rename mbam.exe automatically to one of several commonly-whitelisted names, which we whimsically named “Malwarebytes Chameleon” (“now you see it, now you don’t!”).
But malware adapted, and soon we began to see infections that filtered process creations by more than just image file name. Some infections were simple, like the ones that just searched the binary for the string “Malwarebytes” and killed any matching processes. (You might think it’s surprising that malware would target us so overtly, but in a billion-dollar malware industry, the bad guys are always paying attention to us – after all, we’re a serious threat to their bottom-line.) Well, the solution to that one was easy enough: we just removed all such strings from our binaries (Jalwarebytes Anti-Jalware, anyone?).
But we wanted a solution that we could deploy with a production version of Malwarebytes Anti-Malware, that wouldn’t require affected users to come into our support forums and ask for help to get our software to run. We wanted a robust solution, one that would protect our software against today’s malware and tomorrow’s too, a place a user could always go to get the scanner running in a one-touch way.
So we began to develop Malwarebytes Chameleon from a small utility that renamed mbam.exe, into a full-blown kernel-level self-protection system. We built kernel-level filters of our own to protect our files, our processes, our registry keys, and our drivers from malware interference on every operating system version from Windows 2000 on up. We incorporated the original Chameleon renaming features to block attacks like Image File Execution Options hijacks, or other user-space policy restrictions. When Malwarebytes Chameleon beat every piece of in-the-wild malware we threw at it, we released it to the public with Malwarebytes Anti-Malware 1.60.
In the meanwhile, O Loyal Reader, we challenge you to beat Chameleon. We know it’s possible! – our developers have done it, and are constantly working on improvements. (Indeed, most of the improvements made in every new version of Malwarebytes Anti-Malware are under-the-hood, and you never see them directly! That’s why it’s so important to keep your security software up-to-date.)
If you can find a way to block Malwarebytes Anti-Malware from running while Malwarebytes Chameleon is active, Private Message me on Malwarebytes forums (I’m Swandog46 on forums.malwarebytes.org) and you’ll win a mention in the next Malwarebytes Unpacked, and perhaps a guest post of your own!