Immanentize the Eschaton
A couple of weeks ago, my stepdaughter came home from college for a long weekend and brought her roommate's computer. Like most of us, I end up playing the leading role in the “Six Degrees of HelpDesk” game... you know... the one where you do technical support for a-friend-of-a-relative-of-a-next-door-neighbor-of-your-wife's-hairdresser's-second-cousin? For the most part, I really don't mind, because... well... it gives me a chance to pad out my collections of mp3s* and porn**.
The machine in question had more than a few issues. In its relatively short life, it had two different major AV packages installed. One of them had been rather incompletely uninstalled, leaving behind several running processes that were bogging the machine down horribly. The product that had been installed in its place wasn't doing too well either. Most all of its detection functionality was disabled (more on this later) and it hadn't been updated in months. I tried to jump-start the AV, but something kept shutting it off.
To those problems, add the fact that a glance at the registry showed several suspicious “RUN” values, and what should have been a rather peppy machine took nearly 15 minutes to fully boot. Not good.
My stepdaughter brought the machine home for me to see if I could get the wireless network card to work, but networking this box would be like... well... like asking Lindsey Lohan to drive down to the corner liquor store and pick you up a bottle of Jack Daniels....
So... I set to work doing my normal computer cleanin' schtick. I keep a bunch of tools on a USB key for jobs like this, and after whacking more than a few ugly little critters, I tried kicking the current AV program to life.
Big mistake.
The program started up just fine, and once it realized that it was waaaay past due for a full system scan, it fired up a window and started listing off the files that it was dutifully inspecting. As I watched the list scroll by, it slowly dawned on me that the filenames seemed awfully familiar. For whatever reason, the program had decided that the first disk it was going to inspect was my USB drive.
Suddenly, a little red window popped up and announced that the program had found and removed some malicious code... a little executable called Spycar.exe.
For those of you who don't know, Spycar is a suite of programs the I wrote about 18 months ago to test the behavior based detection capabilities of anti-spyware programs. Ed Skoudis and I were reviewing enterprise anti-spyware for Information Security magazine and we needed a repeatable way to test specific spyware-like behavior. The Spycar tools do about 25 different “things” that spyware typically might do (it will drop a program and install it to automatically run at startup, it will change and lock IE's homepage, it will drop and launch a keystrokes logger, etc... and when its all done, it'll clean up after itself). While Spycar represented only a small portion of our overall testing strategy, our release of the tool following our testing apparently immanentize the Eschaton (look it up... from the first line of a very cool book) as far as the anti-spyware folks were concerned.
Holy Smoke! It was like Tom and Ed had shown up naked for church (something which I would heartily discourage... pews are cold, and there's the ever-present danger of splinters...) The Skodo-Liston hate-fest flew to fever-pitch when Consumer Reports, in a display of poor judgment, used Spycar as the sole criteria for their own magazine's anti-spyware shoot-out (Note: That was done without contacting us to ask what we thought of the idea... it was also in direct violation of Spycar's online documentation and EULA. Worse still... they didn't comp either of us with a free subscription... )
So here we are, a year and a half later, and I'm watching an AV program eat the copy of Spycar that I had on my USB key. What the heck? Spycar isn't malicious, its a testing program. It isn't evil – its just a tool for testing the limits of anti-malware's behavior-based detection capabilities. So why tag the executable as malicious and delete it?
But wait... the funny thing was, the version of Spycar that was detected and removed was one that had never been publicly released. It was a copy of Spycar version 2 that was written about nine months ago, and sent out to select AV vendors for comment. Interesting... here it was being detected just sittin' around on my USB key.
Hmmm... suppose you have an anti-spyware tool that doesn't have behavior-based detection. Or, what if you do have behavior based detection, but it's pretty crappy. What better way to deal with Spycar than to write a signature for it, EVEN BEFORE IT IS RELEASED...
Huh... seems that Spycar can detect lousy behavior-based detection without even being run.
I'm a better programmer than I thought.
(FYI: By the way, right now, Skodo and Matt Carpenter are testing various enterprise anti-malware tools and are using a massively polymorphic version of Spycar 2 that I whipped up to evaluate their behavior-based detection capabilities. Happily, the polymorphism stuff I brewed in the lab quite effectively dodges their signature defenses, so we can separate out their behavior-based detection abilities. Awww... too bad AV dudes...)
-Tom Liston - Intelguardians
* To all my friends at the RIAA: I'm talking about free, legal, re-distributable music here, of course. Believe it or not, some artists release their work for free and want it distributed far and wide without involving record companies. I know, I know... it's sacrilege.
** Honey... it's a joke... really. Honey? Sweetheart? Hello?
Deobfuscating VBScript
Couple of days ago Maarten wrote a nice diary about an iframe tage pointing to a “benign” VBScript that was planted on a relatively high profile web site in Belgium (the original diary is here: http://isc.sans.org/diary.html?storyid=3324).
I’ve been thinking about writing a diary about how to deobfuscate VBScript for quite some time and recently even received couple of e-mails about this (since we covered JavaScript deobfuscation pretty thoroughly here I would say), so here we go ..
The main problem with VBScript is that you basically have to run it on Windows – there aren’t any stand alone VBScript interpreters for Linux (as far as I know – if you know of one please let us know through our contact form).
As we have to work with malicious VBScript programs on Windows platforms this means also that we have to be extra careful – we are actually using the platform that the original exploit was written for (virtual machines come to help here – you don’t want to infect your main host accidentally). As an analyst, you now have the following options
- Use Windows Script Host which can execute VBScript from the command line (the wscript command).
- Use Microsoft Script Debugger from Internet Explorer.
- Use Microsoft Script Editor from Internet Explorer
I will explain methods 1) and 3) here and leave 2) for a future diary (or as an exercise to you, if you find this whole diary interesting). The example malicious VB Script is almost the same as the one Maarten analyzed (and which one is pretty popular. The screenshot below shows the important part where the decoded content is executed with the execute(decode(cde)) call (the program first calls the decode() function and then executes its output):
Windows Script Host
Wscript is an interpreter that comes with Windows and that can easily execute VB Script programs. When deobfuscating VB Script programs with wscript, almost same rules apply as when using Spider Monkey with JavaScript. As we typically want to see what will happen when the current layer is deobfuscated, the most important part of the deobfuscation process is to change the execute() calls to Wscript’s equivalent of print, wscript.echo, so the final two lines will look like this:
Wscript.echo (decode(abc))
Wscript.echo (decode(cde))
You will also have to strip all non-VB Script content (similarly as you have to strip out all non-JavaScript content when running a script through Spider Monkey) and change the extension to .vbs, so wscript will know how to execute this. After this is done, you can just start the script with:
wscript sina.vbs
And the output will look like this:
This is pretty much self explanatory … Let’s see the other method.
Using Microsoft Script Editor
Microsoft Script Editor is a powerful utility that comes with Microsoft Office so in order to install it you have to have a Microsoft Office license (I will cover the free Microsoft Script Debugger in a future diary – there is a reason I picked this one, as you will see in a future diary as well). Microsoft Script Editor will not be installed with Office by default, so you’ll have to add it (it’s under Office Tools and is called Microsoft Script Editor (HTML Source Editing)).
It is easy to check if it’s installed correctly since we have to configure Internet Explorer to use it as well. So first start Internet Explorer and go to Tools -> Internet Options -> Advanced and deselect Disable Script debugging (Internet Explorer). Now restart Internet Explorer and if everything is fine under View you should have an option called Script Debugger:
If you click on Open, Internet Explorer will allow you to choose between available debuggers, if you have more of them.
Now that we have our environment ready, let’s prepare the malicious VB Script. A nice thing when debugging programs like this is that we don’t have to strip out any HTML tags since Internet Explorer will parse that properly for us. There is one thing I like to do in advance, though. While you can tell Internet Explorer to break the script at the next statement, I prefer to do this manually by adding the statement “stop”. This is similar to a breakpoint, so the result will look like this:
<Script language="VBScript">
stop
abc = "006F006E002000650072….. [rest of the code]
Now we basically execute the file from Internet Explorer (double click it, but do this in an isolated virtual machine) and Internet Explorer will immediately ask us which debugger we want to use. Select Microsoft Script Editor and you will end up debugging the file:
You can now use all debugging features you want, set breakpoints and see what’s going on. Microsoft Script Editor is an extremely powerful tool, so if you often have to analyze malicious JavaScript/VBScript files you should get familiar with it. Next time I will show you how you can use Microsoft Script Editor to defeat a very complex obfuscation method with only two clicks.
I have to stress out, once again, how important it is to do this in an isolated virtual machine since you will be executing the malicious code.
--
Bojan
Comments