Bruce Schneier just posted an interesting article on his blog entitled “Interview with an Adware Developer“.
This article reinforces many of the things I have been telling people for a very long time, but for whatever reason never sinks in.
I should probably first speak about how adware works. Most adware targets Internet Explorer (IE) users because obviously they’re the biggest share of the market. In addition, they tend to be the less-savvy chunk of the market. If you’re using IE, then either you don’t care or you don’t know about all the vulnerabilities that IE has.
IE has a mechanism called a Browser Helper Object (BHO) which is basically a gob of executable code that gets informed of web requests as they’re going. It runs in the actual browser process, which means it can do anything the browser can do—which means basically anything.
Aside from reinforcing that Internet Explorer is a poor choice to use for web browsing (unless you enjoy collecting and cleaning malware… you know, for practice), it also outlines an interesting new technique that I recently witnessed as I was cleaning a machine.
If you also have an installer, a little executable, you can make a Registry entry and every time this thing reboots, the installer will check to make sure the BHO is there. If it is, great. If it isn’t, then it will install it. That’s fine until somebody goes and deletes the executable.
The next thing that Direct Revenue did—actually I should say what I did, because I was pretty heavily involved in this—was make a poller which continuously polls about every 10 seconds or so to see if the BHO was there and alive. If it was, great. If it wasn’t, [ the poller would ] install it.
During my live analysis of this machine I used the ms/sysinternals filemon program to watch for a bit and noticed explorer.exe doing something similar to what the author describes.
34139 6:32:11 PM explorer.exe:2916 OPEN C:\NTDETECT.COM:QebiesnrMkudrfcoIbamtykdDa.exe:$DATA NOT FOUND Options: Open Access: Read
The article explains how they will create a seemingly random named file (a hash of the mac address) and use that as the installer. This one appears to be a variant on the technique that takes it a step further and uses hidden data streams (or alternate data streams). These are data streams that I had previously detected and removed.
The article also has an interesting point about evasion.
Next we made a function shuffler, which would go into an executable, take the functions and randomly shuffle them. Once you do that, then of course the signature’s all messed up. [ We also shuffled ] a lot of the pointers within each actual function. It completely changed the shape of the executable.
In the virology and malware world this is known as polymorphism, and is a very effective technique for evading most anti-virus/spyware programs.
Now the truly frightening part mentions using interrupt handlers instead of executables and states that they decided not to do it. Because the concept is written, someone will run with it.
There was one further step that we were going to take but didn’t end up doing, and that is we were going to get rid of threads entirely, and just use interrupt handlers. It turns out that in Windows, you can get access to the interrupt handler pretty easily. In fact, you can register with the OS a chunk of code to handle a given interrupt. Then all you have to do is arrange for an interrupt to happen, and every time that interrupt happens, you wake up, do your stuff and go away. We never got to actually do that, but it was something we were thinking we’d do.
What this all boils down to is that the malware authors once again have leap frogged the anti-virus industry. Microsoft also needs to take a more proactive role in securing IE and Windows against these sorts of threats.
The days of recycling the old code as variants is over and its time that we prepare ourselves for a whole new world of malware threats.
