Debugging malicious windows scriptlets with Google chrome
As a part of my job as a security researcher at Cybereason, I had to do some windows malware analysis. I was analysing a malware sample that uses the windows script host for one of the stages of its infection. That malware sample is JS_POWMET which was also analysed by TrendMicro.
This stage of the malware (stage 2) was using a windows scriptlet written in JScript which was fetched by regsvr32 as a stealthy way to drop binary files onto the machine.
As we can see in the image, what have some heavily obfuscated JScript code and it is very hard to understand what this code actually does but it is quite clear that without setting a few breakpoints with a debugger and iterating through that code it will be impossible to determine the outcome of it.
Since I’m not experienced with debugging JScript (these kind of scripting languages were never my thing) I started by googling for any reasonable JScript debuggers. Sadly, most of the results I got were pointing me to expensive and over-featured products which I don’t really need. I then decided to try and use Chrome’s own debugger.
Since Chrome is a web browser, it won’t debug that script as is and a small adaptation had to be done — put that script in an html file as if it was an ordinary piece of javascript!
Since the scriptlet is wrapped in an XML file, we need to start by removing all of the XML tags and putting HTML tags instead:
Important note: The actual malicious code inside the original XML file was wrapped in a CDATA tag which means that it is not being interpreted as a part of the XML file. Since we are now converting this file into regular HTML file, these tags have to go too. Unlike other XML tags, the CDATA tag has a different syntax which looks like this:
After we cleaned up the file from all of the XML remnants it should look like this:
At this point, we can save this file as an HTML file, open Chrome (ON A VM OR ON A SEPARATE MACHINE DEDICATED TO MALWARE ANALYSIS)
As you can see, when we open the file with Chrome we get nothing by a blank page because there is nothing in that page that’s suppose to display any text (this isn’t your regular HTML file, remember?) But whatever JScript code that’s in there is actually running inside the browser.
Now, let’s open the Chrome developer tools (Use Ctrl+Shift+I or Cmd+Opt+I on Mac) and see what we have:
As we can see in the screenshot, developer tools are now open. Now, let’s click and collapse the “head” block (yes, although we didn’t create a “head” block in our html, chrome pretends that there is one. After we’ll collapse the head block we can see that there is also a script block — this is where our malicious JScript block is:
Let’s click and collapse the script block as well:
In order to actually start the debugging process, we need to now switch from the element viewer to the sources viewer by clicking the “Sources” button:
Since this script is obfuscated, chrome doesn’t display it right for some reason (word wrapping seems to be broken), however, chrome is clever enough to offer us to “pretty print” the code:
We can turn on the pretty printing feature by clicking the curly braces button on the bottom of the screen:
And there we go — we now have a beautiful debugger:
Setting a breakpoint is as easy as clicking the number of the line which you want to debug and refreshing the page.
As you can see in the image above, by putting a breakpoint and stepping through the calls, we can now see the de-obfuscated URL.
I hope that you found this post informative. Happy debugging!
Feel free to reach out over twitter: @0xAmit
