In this release, I’ve made a couple of bug fixes. I’m also using a traditional installer which should help the folks who are having trouble registering the OCXs. I tested this out on Windows XP 32-bit and Windows 7 32-bit and 64-bit without issue. Hopefully you won’t have issues too.
MD5: 76EE13D6B9A6BD5E505AC5CB7E98F73B
Download: http://www.mediafire.com/?kdb1enez1og2b85
Thank you all for your support and feedback with the release of Revelo (finally, I know)!
I wrote this program and tested it in Windows XP since I heavily use that in my VMs for analysis. For several of you, you are getting an error message when trying to run it in Vista or 7. My apologies! It was hard enough to write this let alone make it work on all platforms. 
In this update, I removed an outdated API call which caused the error. This latest version should work fine now on Windows XP through 7, 32-bit and 64-bit. For some of you who helped me test this new version on Windows 7 (thanks), there are apparently some inconsistent issues though (e.g. no messagebox popups, no traffic logs). I’ll have to look into this. Hmm, maybe I need to make a regular installer and not use Enigma Virtual Box. Anyway, I did say this was experimental software, right? If you’re having issues in 7, let me know and use it in XP for the time being.
I also got a few requests to go through a couple more examples so here we go…
Sample 1
This script was found in the wild a couple of days ago. The malicious script was injected into a compromised host at the very top of the page. Interestingly, it started with “<body><script>…” That was a clue. Be sure you copy preceeding tags like this to Revelo as you’ll see why.
Here’s the script we will be working on:
Depending on what you are trying to accomplish, you can click on “Execute” and the redirect URL will appear. All done!
If you click on the “Element Tree” or “Element Detail” tabs, you can see that an iframe was created by the script.
If you want to take this further then we have to pick this script apart a bit. You’ll notice there’s a lot hex characters here. You could go through each section and replace the hex with ASCII so you can see what the script is doing. For example, we see this:
var d=document['\x63\x72\x65\x61\x74\x65\x45\x6c\x65\x6d\x65\x6e\x74'](‘\x69\x6e\x70\x75\x74′);
If you convert the hex values, you’ll get this:
var d=document['createElement'](‘input’);
You could also do a search/replace, being careful not to wipe out something important. Or you can let the browser clean it up for you…
I just wrapped the code with “alert(unescape(” and looked at the result. Keep in mind when you do something like this, there may be some unintended consequences. If I paste the result back to Revelo, the script won’t run correctly as something broke. All we’re doing here is trying to understand what the script is doing. By the way, you can do a control-a then control-c to select-all and copy the messagebox contents.
Here we see why it needed the “<body>” tag. Okay, we now know that this script uses DOM.
And then we find this:
So back at Revelo, we can choose the “Intercept DIV Attach with ID” and type in the letter “l”:
You might have noticed too that the script defined attibutes for the element so we can select “Intercept DOM with Variable” and enter “l” then check out the bottom part of the results:
Sample 2
I also found this script in the wild a few days ago.
Clicking on “Execute” shows us the redirect:
Seems easy enough, we just use “Replace Verbs…” or “Redirect Eval…” options then go to the “Results” tab:
It’s using cookies so subsequent visits won’t work! Let’s first copy this over to the main tab. Then get rid of the cookie check. You can delete it (and fix up the rest of the script) or change the logic.
Notice the “document.write” call? Let’s “Redirect Doc.Write to TextArea” and see the results:
I added a neutered version of the above two scripts in the documentation so you can give them a try yourself. Same disclaimer as before. Have fun!
MD5: 83004DEB60FC9765AA09441F4F139E26
Download: http://www.mediafire.com/?6rdb8bwjo9jdylj
I mentioned a new tool I’ve been developing to help with Javascript deobfuscation months ago. I’ve been working on it off and on but it’s taking me awhile. There’s still more to do but I think it’s ready for a public release. Consider this tool experimental!
The purpose of this program is to assist the user in analyzing obfuscated Javascript code, particularly those that redirect the browser to malicious URLs. My hope is that this tool helps you learn more about deobfuscation and eventually shed the need to use these training wheels.
The tool works by writing the Javascript with some user-based modifcations to an HTML file, opening the file inside of the tool, and extracting deobfuscated elements using the Internet Explorer engine. This tool does rely on the user to make some choices based on some understanding of the obfuscated script.
While this tool does have some protections built into it, it may execute malicious code that could harm your computer so use it in a virtual machine. It’s been tested to run on Windows XP. There’s a helper document inside the zip file which includes safe samples to play with.
Features:
* Analyze a script quickly by loading a file or pasting in Javascript code
* Includes several methods to deobfuscate Javascript
* Includes a built-in browser proxy which displays the URL of outgoing requests
* Displays the Document Object Model (DOM) elements
* Includes a packet sniffer which logs incoming and outgoing requests
* Includes a software firewall to prevent the program from accessing Internet content accidentally
* Ability to act as a web proxy to catch and block redirects
* Beautifies Javascript code to make it more readable
* Ability to clear the browser cookies
* Ability to spoof the user-agent string
Before I show you how this works on some live samples, I should tell you about one new thing I’m trying out. I like portable apps but my tool is not since it relies on several OCX controls. I wanted to virtualize it but VMWare ThinApp was not an option due to the high cost. After searching a bit, I found several other options:
PortableApps
BoxedApp
MoleBox
JauntePE
Cameyo
Enigma Virtual Box
After looking into each one and testing some of them out, I found Enigma Virtual Box to be the best for me. It’s flexible, has a small footprint, and it’s free! Caveat is that it may trigger AV.
Now onto the samples…
Sample 1
=======
Here’s what we are trying to deobfuscate:
You can leave the options alone and just click on the “Execute” button. If it’s a redirect, you’ll see the URL pop up.
If you go to the “Traffic Detail” tab, you can see the GET requests made by the script. Because the program’s Internet Connectivity option (left panel) is set to “block”, the requests were dropped and never left your PC. Notice also that this script sets a cookie. If you don’t clear the cookie after each execute, the script may not do anything.
On the main tab, let’s scroll down to the bottom of the script. You can see there’s an eval call, a strange-looking call, and a likely variable.
Let’s use the “Intercept Function with Name” method and copy/paste that decodeURIComponent call then go to the “Results” tab. Cool…we just got the hex values of the deobfuscated script!
Let’s do one better. Let’s use the same method and copy/paste the eval call instead.
If you’re not getting the results you want or if you like to manually deobfuscate scripts then you can click on the “Unmodified Request” option and make manual changes to the script yourself like so:
Sample 2
=======
DOM-based scripts, like this one, give a lot of tools headaches. What this tool does is enumerate the DOM objects and display what’s there.
Let’s just click on “Execute” so we can see if there’s a redirect:
Now let’s see the DOM elements so click on both of those tabs. Note: you may need to click on “Execute” twice to get the elements to populate.
Let’s analyze the script further. This code is messy so let’s beautify it. Click on “Beautify” then “Copy to Main”. You will have to fix the HTML code (e.g. script tags).
Scrolling down near the bottom, you’ll see “i.body.appendChild(B);”. Ah, so the results get attached to the body. Okay, let’s select the “Intercept DOM with Variable” method and type in “B”.
Now let’s have a look at the “Results” tab:
Sample 3
=======
Here’s a live script that needs to be deobfuscated in two steps. We have to first deobfuscate the bottom half then tack that part to the first half to view the final script. You can see two distinctive parts of the script.
At the bottom of the script, we can see an eval. Let’s choose the “Redirect Eval to TextArea” method.
Nice, we deobfuscated the first part.
Let’s copy that over to the main tab and replace the bottom script with our newly deobfuscated code:
Hmmm, it’s not clear exactly what’s going on so let’s click on the “Highlight Decryption Clues” button. This highlights some key functions and more importantly, variable accumulators. Now we can follow what’s going on. Look at the variable “V3NsLL” and how it contains “eval” then becomes “xTlHf” and finally “X9DfwSP”. Ahh, so at the very bottom it looks like the variable “uXGJZXGp” is getting eval’d.
Let’s use the “Intercept Function with Name” and paste in “X9DfwSP” and go to the “Results” tab. We can see the deobfuscated source which is exploit code.
Last thing to mention is that the tool creates a temporary file called “~temp.html” which contains the original script plus its attempt to deobfuscate the code. You can have a look to see what it’s doing by opening this file in Notepad (do not open it with your browser directly since you will render the code without protection!).
Above is the code it used when we intercepted the function “X9DfwSP”. If it’s wrong, you can always copy and paste the fix over to the tool, make corrections, then click on the “Unmodified Request” option and check out the results.
There you go…I hope this tool helps you!
No warranties, program is made available as-is. Credits to: Eric Wolcott (firewall) and Michael D. (proxy).
MD5: D6444A02BDE034B81E4BEBB55009B656
Download: http://www.mediafire.com/?2c5m50p8qm6q5wv
I wanted to copy over some of my tools into a remote host via VPN. The remote host was locked down so emailing files to myself or downloading files from a website or local drive was not possible. The only thing that was allowed was the clipboard so copying/pasting worked.
There have been previous articles and discussions about converting binary content into text to move files in and out of VPN and other similar technologies so I searched for and found some tools on Internet that I could use but they were kludgy, bloated, or cumbersome to use.
So here’s a quick, little tool I wrote with the least creative name I could come up with and the UI to match. It converts a binary file into text which shows up in the text box which you can copy/paste over to a receiving program which converts text back into a binary file.
To get the receiving program into the remote host, click on the “Create VBS File” button. The textbox will populate with a VBS script.
You just copy the text, switch over to the remote host, and paste it into a text document then save it as “file.vbs” and run it.
When the script runs, a “lite version” of the program will be written out.
In my example, I zipped up my tools on the local host:
Then I clicked on “Read Binary File”. The program converts the binary file into text. I just right-clicked and choose “Select All” then “Copy”.
I went over to the remote host and pasted the text into the textbox. When I clicked on “Write Binary File”, the zipped file appeared on the desktop.
I probably need to mention that companies should already know about this threat. Antivirus should protect against moving malware into the remote host and DLP should protect against data exfiltration. If the security gap is still too big then you can disable the clipboard via group policy.
Last thing. VB Classic was used to code this program. Textboxes in VB Classic is limited to 64K, however, a smart fellow came up with a way to break this barrier. Credit and thanks to Tom Moran. I think I’ll be using his code snippet in my projects since it works great and seems stable (albeit slowly when dealing with large files). This program is available as-is, without warranties.
Filename: Binary File Converter.zip
MD5: 1C9766C1A7A18DB7736CB709090C4C22
Download: http://www.mediafire.com/?zdb2pli66vw9gs7
If you’re into malware analysis or incident response, I’m sure you’ve come across a number of malicious Java applets lately. And perhaps you’ve noticed some new tactics being employed which are quite clever and probably effective in getting past perimeter and desktop security.
Here are three related articles that caught my eye:
A unique ‘fileless’ bot attacks news site visitors
An interesting case of JRE sandbox breach
New Java Attack Rolled into Exploit Packs
As noted by Brian Krebs, the latest Java exploit, CVE-2012-0507, will be added to exploit packs soon. Some people believe that the Eleonore Exploit Kit is the first kit to use this exploit. An announcement at the end of 2011 revealed version 1.8.91 which included Java Rhino.
Eleonore Exploit Kit v1.8.91
Private sheaf exploit
Coder – Exmanoize
Are included new exploit:
java_rhino
pdf libtiff
pdf u3d new
flash pack
quicktime
iepeers
mdac
Average having punched on a sheaf: 15-25% Depends on the traffic.
On сео traffic can be 25-35%
* Knock standard, even hardly above the standard:
> Zeus = 50-60%
> Loader = 80-90%
The price of last version 1.8.91 :
> Cost of the sheaf = 2200$
> Cleanings from antivirus = от 50$
> Domain change free of charge, change ip = 50$
> Updates = от 100$
* Sheaf with a binding to the domain or IP .
It’s very possible that Eleonore has been updated since then with this new Java Atomic exploit as Exmanoize has added 0days to his kit before.
Microsoft researchers have already dissected this but let’s have a quick look at this Java exploit anyway…
The exploit file has a hidden class in the applet (“arrayOfString”):
I used my Converter program to swap one character every one position to reveal the magic number for class files, “CAFEBABE”:
After writing that out to a binary file, we can see that it uses two alternating values to XOR an encrypted file:
Since the file is encrypted and looks like a bunch of random bytes, it’s very likely it would download just fine and land on the victim’s PC as it’s decrypted and executed by the applet.
Here’s another tactic I found that’s similar. This was part of a malvertisement campaign on a Chinese news site discovered the other day. Instead of downloading a separate binary file that gets decrypted and executed, malware authors are using a self-contained applet which includes the encrypted payload.
The entry point reveals a call to an external Javascript file, some encodings, and a redirect:
Here’s the Javascript file doing the encoding:
You have to nail the referer and the parameters just right or you’d end up with this innocent JAR (I’m noticing that some new exploit kits require the same attention to details or you’ll get a goose-egg):
If you’re successful, you’ll get the malicious applet.
The pl.class describes rotating four values to XOR decrypt a resource file that’s actually included right in the JAR file itself. It’s the CMQSQVRW file seen on the left-hand side.
Here’s how the encrypted file looks like:
I wrote a quick and dirty program to XOR files using multiple values for added flexibility:
Sure enough, you end up with an executable, actually a DLL. You’ll notice that the first two bytes are not “MZ”. Those bytes are written out by the applet (see the above code) which my program didn’t do.
When the applet runs, it decrypts the resource file, then writes it out to the temp folder as an innocent looking “htm” file:
The DLL file is then called up which scans the registry for known AV products. When done, it makes an HTTP request for a “tracking.gif” file which includes information in its user-agent string and cookie.
This behavior sounds similar to what the Kaspersky researcher found that preceded the Lurk infection.
Going back to the applet, I tried to look for clues that would tell me which Java exploit was used but there’s nothing there. I noticed a Corba import and makes me wonder if this is using the vulnerability described here:
CVE-2012-0506 – “Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 Update 2 and earlier, 6 Update 30 and earlier, 5.0 Update 33 and earlier, and 1.4.2_35 and earlier allows remote untrusted Java Web Start applications and untrusted Java applets to affect integrity via unknown vectors related to CORBA.”
There are no further information or technical details about this vulnerability so I can’t confirm. Since Oracle indicated that they have fixed this vulnerability in Java SE 6u31, I installed this version and executed the applet. Nothing happened. The applet failed to decrypt and write out the DLL file to the temp folder.
DLL MD5: 52FA85A43AE7666DAAB7893385FA2F7F
VT: 0/42
Anubis results
JAR MD5: 08331A5C7564FD61A84EDEA7FBCF56FC
VT: 0/42
