Kahu Security http://www.kahusecurity.com Sun, 14 Dec 2014 01:16:33 +0000 en-US hourly 1 Wild Wild West – 12/2014 http://www.kahusecurity.com/2014/wild-wild-west-122014/ http://www.kahusecurity.com/2014/wild-wild-west-122014/#comments Sun, 14 Dec 2014 01:16:33 +0000 http://www.kahusecurity.com/?p=13309 Added the following packs:

Null Hole
“Hanjuan EK”
“Archie EK”
“Astrum EK”
“SPL2 Pack”

Special thanks to Kafeine for his valuable input.


http://www.kahusecurity.com/2014/wild-wild-west-122014/feed/ 0
Registry Dumper – Find and Dump Hidden Registry Keys http://www.kahusecurity.com/2014/registry-dumper-find-and-dump-hidden-registry-keys/ http://www.kahusecurity.com/2014/registry-dumper-find-and-dump-hidden-registry-keys/#comments Sun, 07 Dec 2014 02:28:35 +0000 http://www.kahusecurity.com/?p=13303 Continue reading ]]> The cybercriminals behind Poweliks implemented two clever techniques in their malware. The first was leveraging rundll32.dll to execute Javascript and the second was using a method to hide/protect their registry keys. I’ll be focusing on the second method.

The technique of hiding/protecting registry keys using a non-ASCII character goes all the way back to over a decade ago. It’s remarkable in a sense that after all these years, it still works on the latest Windows platform.

Here we see the built-in Windows Registry Editor choke on the hidden/protected key after infecting the computer with Poweliks.


Clicking past the error dialog, you should see something like this. This default key is exposed and fully downloadable/viewable. However, there’s another key that contains the “trigger” that’s not visible.


If we need to research what this particular malware is doing, we ought to find out what else is hiding there. For that we need to find a tool to help us view these hidden registry keys.

With online registry viewers/editors, you can get mixed results. Some seem to work well but lack some basic functionality like exporting keys as text. Others get confused and display the wrong key.




Offline registry viewers/editors fare much better and offer consistent results. However, you will need to log into a separate account on the computer and use this tool. Or you have to copy the registry off of the infected machine and view it on a computer with the tool installed.


I prefer to do an initial triage on the live machine and get to the data as quickly as possible. Since I couldn’t find a portable, online tool that had the features I wanted, I figure I would try my hand at creating one. The tool is called Registry Dumper and uses a DLL which interacts with the registry via NT native APIs that was written by Hoang Khanh Nguyen.


This tool allows you to scan for null characters in a given path. It will iterate through the path to find all the keys with nulls in them.


If you click on the “Show in Hex” checkbox, you can see the key names in hex. Here you will notice that the second entry’s name is “010001” which is equivalent to 0x01 0x00 0x01. This is impossible to view, edit, or delete using the Windows’ Registry Editor.


From here you can copy/paste the path over to the left side and dump the keys to a text file.


Here’s the text file containing all the key values in the given path.


With this tool you can create hidden keys for testing purposes. And if you wanted to delete that impossible-to-remove key, you can use this tool by entering “[x01][null][x01]” as the key name.


The obfuscated data you see there is the result of running it through Microsoft Script Encoder. To deobfuscate it, you can use an online decoder or download a VBS decoder. A fellow by the name of Lewis E. Moten III wrote a decoder program. I repackaged his function in the following tool.


Here is the decoded version. You will notice that I didn’t have to strip away everything else but the encoded string. The decoder program will look for the start and end markers of the encoded text and replace it with the decoded result.


Just recently, a newer variant of Poweliks was found. It uses a different registry hiding technique based on user permissions. You can read about it here.

If you use this tool to access one of these keys, you will get an error message saying that the key doesn’t exist. It does exist but it’s just that it doesn’t have the rights to view it.


Here’s the permission properties of the key using the Windows Registry Editor. Notice that the current user has no read permissions.


You can still use this tool to dump the keys but you first need to grant permission to the user account that’s running the tool. Just click on the Set Permission to User button and the permission is changed to allow the current user the rights.


Now you can access the key:


Here is the dump of the keys:


And the decoded string:


By the way, that Javascript in the “(Default)” key can be deobfuscated easily using Converter. You will see that the value in between the quotes are shifted over by one character (e.g. the word hello = ifmmp). Just enter the value “-1″ and click on the SHIFTx button (or you can click once on the minus button on the right).


You can download both tools here.

http://www.kahusecurity.com/2014/registry-dumper-find-and-dump-hidden-registry-keys/feed/ 0
Securing KeePass with a Second Factor http://www.kahusecurity.com/2014/securing-keepass-with-a-second-factor/ http://www.kahusecurity.com/2014/securing-keepass-with-a-second-factor/#comments Thu, 27 Nov 2014 08:02:22 +0000 http://www.kahusecurity.com/?p=13278 Continue reading ]]> Cybercriminals are now stealing password managers so it’s time to make them more secure. You can check out this article for details about how it’s being done.

I wrote this up as a guide to help friends secure their password manager by implementing a second factor. The second factor will come in the form of a USB token that you insert into your computer when you need to run the password manager. If your password manager database and master password gets stolen by Citadel or anything else, criminals won’t be able to open the database without the physical USB token you have in your possession.

Two popular password managers are currently being stolen based on the article above — Password Safe and KeePass. There is a nice walkthrough on Yubico’s website on how to enable YubiKey for Password Safe here. YubiKey can also be used to secure LastPass, Passpack, and others.

Getting YubiKey and KeePass to work was a little tricky so I’ll be describing my experience here.

1. YubiKey made by Yubico

What’s great about the YubiKey hardware is that it supports a number of use cases such as computer logins, disk encryption, and web applications like WordPress, Google, and others. Unfortunately, not all YubiKey hardware supports all applications so be sure you pick up the right YubiKey hardware.

There are basically two types of hardware and the one you want to get to protect KeePass will either be the Standard or Neo version. The FIDO U2F Security Key doesn’t appear to support the protocol we need.

2. YubiKey Personalization Tool

This software program will allow you to configure your YubiKey. We will be configuring the second slot since the first slot is apparently reserved according to Yubico’s website — “Re-programming your YubiKey’s 1st configuration slot will overwrite the YubiCloud configuration, and you cannot undo this action!”

3. KeePass Professional Edition

You may need to install Microsoft .NET Framework 2.0+ if it’s not installed already.

4. KeePass plugin

You have a choice between two different security models — One-Time Pad (OTP) and Challenge-Response. Here are the links to the KeePass plugin that you’ll need:


If you decide on the OTP method, you can follow the instructions on Yubico’s website. It works but I had trouble. I had it generate three sets of OTP values which required three button presses on the YubiKey. Using the YubiKey Neo version, it worked most of the time. With the YubiKey Standard version, it rarely worked for some reason. I think it has something to do with how quickly you can press the button to generate the values. Tinkering with the OtpKeyProv settings (e.g. counters, look-ahead windows) did not yield consistent results but YMMV.

I opted for the Challenge-Response method via KeeChallenge which I’ll be describing here. With KeeChallenge, I didn’t have any problems like I did using the OTP method.

The KeeChallenge plugin can be downloaded directly from here. You will also need to download the latest YubiKey-Personalization release (download both Windows 32- and 64-bit versions) from Yubico. This was the part that I got hung up with but a helpful tip on a discussion board provided the solution.

Setting Up YubiKey
Install and run the YubiKey Personalization Tool then plug in the YubiKey into an available USB port.


Click on the Challenge-Response menu item at the top then click on the HMAC-SHA1 button.


Click on the Configuration Slot 2, ensure user input is required, and the fixed 64-byte input is selected. Click on Generate then on the Write Configuration buttons. You should get feedback that the configuration change was successful.


Make sure you copy and backup the secret key you generated! You will need this to setup KeePass as well as to regain access to your database should YubiKey fail for some reason. Store this in a safe place, preferably printed on paper and definitely not stored on the same computer that you’ll be using KeePass on.

If you want to set up multiple YubiKeys to work with the same KeePass database, just use the same secret key and write the change to the configuration.

That’s it for the YubiKey setup.

Setting Up KeePass and KeeChallenge
Download KeePass as well as the KeeChallenge plugin and Yubico’s YubiKey-Personalization release.

Install KeePass and go to the folder. Copy over the files and folders from the KeeChallenge plugin into the KeePass folder so it looks like this (the items in red belong to KeeChallenge):


Open the folder called “32bit”. See those DLL files? Replace them with the ones from the YubiKey-Personalization files you downloaded (the DLL files are located in the bin folder). Do the same for the 64-bit files.

Start KeePass and create or open an existing database.


Click on File > Change Master Key. Enter a new master password (twice). Click on the “Key File / Provider” checkbox and choose “Yubikey Challenge-Response”. Click on OK.


You will be asked for the secret. Paste the secret key you generated when you configured your YubiKey.


You will then be prompted to plug in your YubiKey if it’s not in already.


Tap the button on your YubiKey when you see this prompt on the screen.


Setup is done!

Usage and Recovery
To use KeyPass going forward, enter the password and ensure the Key File option is checked and set to YubiKey Challenge-Response.


Insert your YubiKey and tap on the button to log in.


You’re in!


If you lose your YubiKey, it broke, or you just can’t log in using it for whatever reason then unplug it, enter your password, and click OK. You will see this prompt. Choose “Recovery Mode”.


Enter the secret key and click OK.


And you’re back in!


You can feel a little more at ease now while shopping online!

http://www.kahusecurity.com/2014/securing-keepass-with-a-second-factor/feed/ 0
Drupal 7 SQL Injection Info http://www.kahusecurity.com/2014/drupal-7-sql-injection-info/ http://www.kahusecurity.com/2014/drupal-7-sql-injection-info/#comments Sun, 02 Nov 2014 23:52:28 +0000 http://www.kahusecurity.com/?p=13261 Continue reading ]]> There’s a lot of sites covering this vulnerability but I wanted to document some indicators for anyone who might need it.

Drupal Security Advisory
Drupal Public Service Annoucement
Drupal Documentation on “Your Drupal Site Got Hacked. Now What?”
Drupal Site Audit
Volexity Blog
Sururi Blog

What follows is a brief walk-through of evidence found on a couple of compromised hosts. YMMV.

Incident Response
Logging into phpMyAdmin and checking out the “users” table. Two accounts were created. The “drupaldev” account seems to have been found on many compromised hosts.


There was one host that had hundreds of accounts. What made the malicious accounts stand out was the missing mail field. This would occur if the user could get past the requirement on the registration page or if the account was added directly to the table.

Going to the “sessions” table, there’s one entry with the “uid” that matches the account created by the attacker. You can find out the attacker’s IP address this way.


Here’s info on this IP address:


The firewall logs showed activity over port 8888. If you visit the IP:port, you get this site:


Looking at the webserver logs, we can see POSTs hitting the user/login file on the host. The server 500 errors probably indicate a failed first attempt.


Going back to phpMyAdmin, a quick search for “.php” was done across all of the tables.


There was an entry found in the “menu_router” table which seems to be a very common indicator.


Clicking on the link, you can download the blob.


Going to the file system, there is a directory called “README.txt” with a php file inside. The folder and file names appear to be random but the script itself is the same as what others have reported.

This PHP script is particularly interesting, it’s a simple backdoor that’s triggered by a cookie. Sucuri covered this awhile ago.

Here’s a cleaned up version. If you hit the script straightaway, you will get the results of phpinfo(). If you wish to send your own commands, you need to pass three variables. The “Kcqf3″ variable contains a value that triggers the script. The second variable “Kcqf2″ will be preg_replace. “Kcqf1″ contains the command. I imagine the attackers might send commands along the lines of uname, wget, curl, etc.


I wrote a program to craft HTTP requests and can include my own cookie values into the header. Here, I’m sending the phpinfo command and you can see the result in the background. What stands out is its simplicity and cleverness.


You could create an IDS rule to look for HTTP requests that contain a cookie with the value “preg_replace” and detect/block those coming in. You can then follow up on the targeted host to see if the backdoor is there.

Good luck!

http://www.kahusecurity.com/2014/drupal-7-sql-injection-info/feed/ 0
Tools Update http://www.kahusecurity.com/2014/tools-update-2/ http://www.kahusecurity.com/2014/tools-update-2/#comments Sun, 05 Oct 2014 19:16:00 +0000 http://www.kahusecurity.com/?p=13247 Continue reading ]]> No significant updates, just several enhancements and bug fixes to four tools:

– Added new features to Custom PHP Search/Replace
– Added Convert Word (to decimal) feature
– Enhanced Key Search/Replace input checking (see Data Converter changes)
– Improved Beautify Generic routine
– Updated some labels to provide more clarity
– Fixed PHP decoder toggle
– Fixed Base64 by Delimiter option to handle nulls
– Fixed unescape issue by removing ` replacement
– Fixed Character Frequency array function to remove last item
– Fixed Base64 to Text function to properly handle CRLFs

Data Converter
Thanks to Thijs Bosschert for his suggestions. I still need to look into his additional enhancements without slowing things down but for now:
– Split by single char if key value is text
– Split every two chars if key value is hex
– Remove spaces and commas if input value is hex

– Added –ignore-ssl-errors=true option to PhantomJS call

– Added –ignore-ssl-errors=true option to PhantomJS call

Thanks for your support!

http://www.kahusecurity.com/2014/tools-update-2/feed/ 0
Javascript Deobfuscation Tools Redux http://www.kahusecurity.com/2014/javascript-deobfuscation-tools-redux/ http://www.kahusecurity.com/2014/javascript-deobfuscation-tools-redux/#comments Wed, 24 Sep 2014 06:00:35 +0000 http://www.kahusecurity.com/?p=13241 Continue reading ]]> Back in 2011, I took a look at several tools used to deobfuscate Javascript. This time around I will use several popular automated and semi-automated/manual tools to see how they would fare against today’s obfuscated scripts with the least amount of intervention.

Here are the tools I’ll be testing:
Javascript Deobfuscator (Firefox Add-On)

Javascript Debugger (all are similar; using Script Debugger for this test): Microsoft Script Debugger, Chrome Developer Tools, Firefox Developer Tools, Firebug (Firefox Add-On)

Here are the obfuscated scripts:
Sample 1
Dean Edwards Packer


Sample 2
HiveLogic Enkoder


Sample 3
For this sample, I used the same original HTML code as the above and obfuscated it using three online obfuscators in the following order: obfuscatorjavascript.com, www.gaijin.at/en/olsjse.php, www.atasoyweb.net/Javascript_Encrypter/javascript_encrypter_eng.php


Sample 4
Speed-Trap JS


Sample 5
Gong Da EK


Sample 6


Sample 7
Angler EK


Sample 8
Nuclear EK


My plan is simple. Use the tools to try to deobfuscate the above scripts without spending more than a few minutes on each one. If I can’t figure it out by making obvious tweaks along the way then I move on. To be honest, I’m no expert with all of these tools so I’m not taking full advantage of its capabilities but this should give you some idea of what you can expect.

I would encourage you to play along (the scripts are here) . Be sure you do this in a virtual machine because many of the scripts are real and very malicious.

JSUnpack is fully automated and can deal with a lot of scripts except the complex ones.








Javascript Deobfuscator
This Firefox add-on is quite robust and also completely automated. Interestingly, it is able to deobfuscate the hard ones but trips up on an easy one. This tool won’t be able to handle scripts that target Internet Explorer for obvious reasons. You might be able to comment out some browser sniffing routines though.









The SpiderMonkey tool would be similar to using Rhino or V8 engines but Didier Stevens adds some mods that has beefed up SpiderMonkey’s capabilities. DOM-based scripts tend to pose a problem for these engines but you can make several tweaks to the script and define objects to get around this.









This tool has a lot of capability and potential. The main reason it can’t deob the malicious scripts is probably because I suck at using it.









Javascript Debugger
Pretty much all of the Javascript debuggers work the same way so I just lumped them together as a single class of tools. Using a debugger can be slow because you have to follow along with the script and know where to place breakpoints but it is often the most effective way of deobfuscating scripts.









I would have hoped my own tool would do pretty well against these scripts and it did. The main challenge with using Revelo is that you need to understand the script you are working on and be able to recognize entry and exit points to inspect. This tool is definitely not for everyone but it has the capability to do just as well as a debugger.









Conclusion and Scorecard
As I mentioned earlier, I’m probably not making the most of every tool as they are quite capable and powerful in their own right. The end result is probably more of a reflection of my abilities rather than the tool so take this with a barrel of salt.


http://www.kahusecurity.com/2014/javascript-deobfuscation-tools-redux/feed/ 0
Detecting Phishing Sites in Your Logs http://www.kahusecurity.com/2014/detecting-phishing-sites-in-your-logs/ http://www.kahusecurity.com/2014/detecting-phishing-sites-in-your-logs/#comments Sat, 13 Sep 2014 05:48:30 +0000 http://www.kahusecurity.com/?p=13175 Continue reading ]]> I recently read the Anti-Phishing Working Group’s 2Q 2014 report and saw the number of unique phishing sites. I then compared the numbers with the previous year.


After more than 10 years of phishing it’s still around, and growing! Back then, there were companies offering clients a way to detect phishing attacks by analyzing their own web server logs. I wrote my own program in 2006 and decided to update it and offer it up as freeware in case anyone needs a tool like this (I wrote a Python script that does the same thing which I’ll probably push onto Github one day).

The idea behind this and other similar tools is to analyze referers in your web server logs. These referers are generated when a user visits a phishing page and submits the form. Upon receiving the user’s credentials, the phishing page will often redirect the user to the legitimate website. The referer will contain the URL of the phishing site.

In other phishes, the contents of the phishing page are composed of images, stylesheets, and Javascript from the legitimate site in order to make it look exactly like the original to fool unsuspecting users. Again, we can find out the URL of the phishing page by looking at the referers it generates.

Keep in mind that if the phishing website is self-contained (that is, does not need any files from the legitimate site) and does not redirect the user back to the legitimate site then there would be no trace in the web server logs.

Let’s take a look at a typical phish. Here I went to PhishTank.com and try to find a phishing site that’s still up:


Here’s what the site looks like:


When I proceeded through the pages where it asks for more and more personal and financial information, I eventually get to the last page:


Clicking on the Continue button takes me to the main Paypal site (it’s the Danish version for some reason):


I captured the source code of last phishing page and it looks like this. Notice that it contains links back to the real Paypal site. I’ve highlighted the link to the main logo graphic.


If we were to look at Paypal’s web server logs, it might look something like this (note the last line). There’s a GET request to the logo graphic and the referer is the URL of last phishing page that called the graphic up.


If we could find these entries in our log files, we’d find these phishing sites and get them taken down. And we don’t need to rely on users telling us about it. There’s also an added bonus. Sometimes phishers will test their creation first and their referers show up in the logs and we can take down those phishing sites before their phishing campaign can even begin!

Here’s where the program, Sounder aka FishFinder, comes in:


The top portion is where you define folders and filenames. You also need to define the column that contains the referer information (be sure your logs contain referer information or this program won’t work!) and line separator. There’s debug modes to help you.

You can have it check the Contents of the potential phishing site by scanning for content keywords as defined below. For example, if you enter login, password, email, and username that you see there, the program will check if the website has any of those keywords and tell you if there’s a match on the results file.

The Check Filename option will check if the referer contains any of the blacklisted items. The blacklist textbox should contain filenames of known bad referers. In the case of Paypal, it might be something like “paypal.com.html” or “logon.php”. The whitelist textbox would be URLs that you would want to ignore like partner websites, spiders, portals, etc.

If the Capture Screen option is set, the program will screenshot the page for visual inspection. This feature requires PhantomJS. I’ve included the required “rasterize.js” file in my download so you just need to copy the PhantomJS executable into the folder.

Finally, the Server File (Referers) textbox should contain the paths to files on your web server that is often used on phishing pages. Here, I’ve included the path to the logo file.

You can save (and load) the settings by clicking on the appropriate buttons on the bottom. The program uses an INI file which contains helpful descriptions and worth looking at before you use the program.


When Sounder is run, it will scan the files in the Logs folder and look for any HTTP request matching the items in the “Server Files (Referers)” textbox then inspect the referer. If the referer is known bad then it will automatically flag it. If the referer is on the whitelist, it will ignore it. If the referer is neither good nor bad then it will flag it as suspicious so you can have a chance to inspect it. You should then add the referer to either the white or black list as appropriate for future runs.

If the referer is marked suspicious then it will (optionally) visit the page and check if the webpage contents contain any of the items in the “Content Keywords” textbox and grab the screen, regardless of whether there were any keyword matches.


Here’s the results file that shows that this particular referer was suspicious and the keyword “login” was found on the webpage.


This is the screenshot that PhantomJS captured.


I hope you find this program useful!

http://www.kahusecurity.com/2014/detecting-phishing-sites-in-your-logs/feed/ 0
A Quick Peek at Network Injection http://www.kahusecurity.com/2014/a-quick-peek-at-network-injection/ http://www.kahusecurity.com/2014/a-quick-peek-at-network-injection/#comments Thu, 21 Aug 2014 03:15:05 +0000 http://www.kahusecurity.com/?p=13160 Continue reading ]]> Like many of you, I’ve been looking at the various NSA document leaks to see what kind of tools and techniques are being used. I suppose these releases will give cybercriminals new ideas and we will see some of these put to nefarious use sooner than later.

This particular article was very interesting, especially the concept of network injectors. I’ve heard about EvilGrade but never played with it. It seems as though QUANTUMINSERT and FinFly ISP do something similar.

I wondered how I could use this for a pentest. Getting inline with my target would be the first challenge. There are several tools I could use to route wired and wireless network traffic to my computer but maybe an easier way is to setup a proxy server then push out a proxy.pac file.

Here’s a website with a link to a setup file for Revelo.


When the user downloads the program, I can see their GET request and response. At this point the program gets downloaded. Here we see excerpts from Paros.


The way QUANTUMINSERT is described to work, the download request gets silently redirected to another server where an implant gets downloaded. And according to the FinFisher documentation, there is a method called “INJECT-EXE” which “infects the downloaded EXE file in real time. The agent is installed when the target runs the EXE file.”

There’s not too much details so I can only infer how this is being done. Maybe they would have pre-downloaded popular programs, binded it with a backdoor, then sent the file over via a forged HTTP redirect. This would allow the user to install the real program with real certificates but have their program run too.

But how could you do this in real-time, with any download? If I can write a program that intercepts the GET request to any EXE program, bind it with a backdoor in real-time, update the Content-Length field in the response header, and send the file along…it *should* work. ;)

After some coding, I came up with “Interjector” – Interceptor and Injector (because of the nature of this program I won’t be making this available, sorry). There’s not much to look at I know.


With Interjector off, when I download the file, it looks like this:


However, when Interjector is running, the same download dialog box now looks like this (note the file size):


What’s happening behind the scenes is that there is a specially-crafted EXE file that’s been added to Interjector as a resource. When the program sees a GET request to any EXE file, it loads the resource to a variable and gets ready. When the program sees the response, it reads in the Content-Length value, adds the length of the resource to it, and puts the updated value back into the header. Finally, it injects the variable containing the resource into the download stream.

The advantage of doing it this way is that I don’t need to redirect users to another server, I can intercept/inject any EXE file the user downloads, it’s very stealthy, and all of this happens in real time.

Here’s what it looks like when the downloaded file is executed:


Ugh, the icon makes it look fake but I can fix that. This is going to be a challenge for those programs with unique icons. The best way is probably to use a generic icon like this and hope users don’t notice.


What about the MD5/SHA hash? That’s the biggest hurdle to overcome. I could change the hash on the webpage to match the final file but only for the ones I know about by doing a global search and replace. Or I can search for any hash line and remove it from the webpage.


What if it’s a compressed file download (e.g. ZIP)? I think I would have to rezip the file with a new EXE or rebuild the download which changes the ZIP file to an EXE. The real-time requirement makes this difficult to handle without the user taking notice.

So what’s a user to do?
– Use HTTPS to download programs
– Choose to download a compressed version (e.g. ZIP) instead of a bare EXE/MSI file
– Pay attention to any anomalies and inconsistencies; when in doubt, stop
– Verify the program’s hash before installing (for the paranoid, use an out-of-band device like your phone to view the hash on the webpage)

http://www.kahusecurity.com/2014/a-quick-peek-at-network-injection/feed/ 0
Wild Wild West – 07/2014 http://www.kahusecurity.com/2014/wild-wild-west-072014/ http://www.kahusecurity.com/2014/wild-wild-west-072014/#comments Fri, 25 Jul 2014 19:15:55 +0000 http://www.kahusecurity.com/?p=13149 Added the following packs:

RIG Exploit Kit
Niteris aka “CottonCastle”

Special thanks to Kafeine for his valuable input.


http://www.kahusecurity.com/2014/wild-wild-west-072014/feed/ 0
Reversing a PHP Script Dynamically and Statically http://www.kahusecurity.com/2014/reversing-a-php-script-dynamically-and-statically/ http://www.kahusecurity.com/2014/reversing-a-php-script-dynamically-and-statically/#comments Sat, 12 Jul 2014 05:45:55 +0000 http://www.kahusecurity.com/?p=13140 Continue reading ]]> A reader sent me two PHP scripts because the PHP Converter program I wrote wasn’t able to handle it. They are both similar so I’ll just work on one of them in this post. Here’s what it looks like:


And this is what happens when you try to use PHP Converter:


Let’s reverse this script dynamically and then statically.

First, I’ll just change the ‘eval’ keyword to ‘echo’.


And take a peek at what’s going on.


Yikes, this is messed up! I thought the PHP file got corrupted somehow but then I looked closely and noticed several PHP keywords. This is actually a pretty clever technique. Basically the script is converting the strange characters to text but it’s surrounded by long, seemingly random strings that are variable names.

So I figure I would just write it out to a file and then change the ‘eval’ I noticed at the end to ‘echo’.


Here’s the resulting file:


I’ll just make that quick change and run it again.


Cool, now we know what this script does!

Now let’s reverse this script statically.

Here’s a new, fixed version of PHP Converter. I added a filter to present the results of the deobfuscation without stopping if it encounters any strange characters. The characters outside the alphanumeric range will be represented by a neutral character.


I also added the ability to output the result to Base64 format and/or to a file. With both options checked, you will get a text file of the result encoded in Base64 so the binary values will be preserved.


Now I can convert this base64-encoded string to text using Converter.


After cleaning this up, we can see that the section below is XOR’ing the blob using the decimal value of ’30’ which is assigned to the first variable.


I’m going to convert the base64-encoded string to hex this time.


Then send the data to Converter’s Key Search/Convert feature and set the values accordingly:


And I get this result. The junk at the top and bottom is the result of XOR’ing the original text so I can ignore that.


There are other ways to get to the final result but I think these two methods are straightforward and quick/easy to do.

The updated version of PHP Converter can be downloaded here.

http://www.kahusecurity.com/2014/reversing-a-php-script-dynamically-and-statically/feed/ 0
Deobfuscating PHP Scripts http://www.kahusecurity.com/2014/deobfuscating-php-scripts/ http://www.kahusecurity.com/2014/deobfuscating-php-scripts/#comments Sun, 01 Jun 2014 20:08:35 +0000 http://www.kahusecurity.com/?p=13126 Continue reading ]]> Occasionally people send me PHP scripts to help them analyze it. Most of the time, it’s simply unescaping the script and finding the right variable to echo. I got two tricky ones within the past couple of months and finally got around to writing a program to quickly deobfuscate them. These scripts represent obfuscation methods that make it difficult to read them but they don’t employ character rotation, XOR, base64, etc. I’m not sure if there’s an easier way to do this; if there is, I’d like to hear about it.

I already wrote a tool to handle an older variety of this method and I decided to add functionality to handle the newer ones. I also added a pretty basic (crappy) beautifier and making this available as a separate download (I think I’ll add this to Converter later).

Method 1 – Array Search/Replace
This script uses an array of base64-encoded strings. The second part of the script references specific values from the array. The obfuscated script looks like this:


The idea is to first base64-decode the strings and load them into an array. Loop through the array and replace the calling variables with the actual values.

You should concatenate the strings first. I use Converter but even Notepad will do.


Then you need to base64-decode the strings. Again I’m using Converter.


Using the PHP Script Decoder tool, I paste the result from above to the “Lookup Array” box. I paste the obfuscated script to the input box. When you choose the Array method you have to enter a delimiter (in this case the comma is used) and the search string. The search string is the variable you wish to replace with the value. In this case I enter “_449578015(#)”. The pound sign is a placeholder which the tool needs.

Here’s what it looks like. Now the deobfuscated script is much easier to figure out.


If you want to beautify the script, click on the “Copy Output to Input” button then click on the “Beautify” button.


The result is a simple and rough cleanup of the script.

Method 2 – Random Variables
This script uses randomize variable names and assigns a value to it. The later portion references the value. Here’s what this looks like:


The tool will parse the script and load each variable and associated value into an array. It then does a search for the variable and replaces it with the value.

I just paste the entire script in the input box and choose the “random vars” option. The delimiter for this script is a semi-colon and for the search string I enter ${“GLOBALS”}[“#”]=”*”; The pound sign is a placeholder for the variable name and the asterisk is the placeholder for the value.

Here’s the result:


Method 3 – Key Lookup
This script uses a lookup array to build the values for its variables. Each character in this string is loaded into an array:

“,`TD[r)Ej|4*^QXOK\t: @.tl#2%\\L\r_R-~b=Z7zaV{]S+’Gio>gd058up6C!HkwxmvN?nJI(\”FMWc3hYs\$&;\nBA

The script concatenates each character of the value and assigns it to a variable. The tool again does a search and replace of each character. You can optionally concatenate the result. For this particular script, you then need to use the second method and replace the variable name with the value.


Here we go…the first step I do is paste the entire script in the input box and choose the key lookup option. The delimiter is irrelevant. I use $f9[#] as the search string. In the lookup key box I need to paste the key with the starting and ending quotes. The tool will unescape the value so you don’t have to do it yourself.


You can see that the strings should be concatenated so I check the box and click on Convert again.


Now I click on the “Copy Output to Input” button and choose the random vars option. I leave the delimiter to semi-colon and use $GLOBALS[‘#’] = ‘*'; as my search string.


Ah, much more readable! By the way, you may have seen this on several compromised sites as the output looks something like this:


This script is essentially an emailer.

You can find this program here.

http://www.kahusecurity.com/2014/deobfuscating-php-scripts/feed/ 0
Reversing RIG EK’s Flash File http://www.kahusecurity.com/2014/reversing-rig-eks-flash-file/ http://www.kahusecurity.com/2014/reversing-rig-eks-flash-file/#comments Sat, 24 May 2014 05:07:24 +0000 http://www.kahusecurity.com/?p=13112 Continue reading ]]> VirusTotal is showing 0 out of 51 for RIG EK’s SWFIE exploit (MD5: 65AFF3A3774298B3ED5BA2C43F8A1979). Here’s a really quick overview on how to reverse this exploit file so we can determine which vulnerability it’s using. This method can also be used on Infinity EK’s flash file and probably others.

First, you need to use your favorite method to decompile the SWF file. I always try to give ActionScriptExtractor the first shot. If it doesn’t work, you might have to use a commercial tool like I did. Looking over the decompiled code, there’s an interesting function called “onus”.


Variable _local5 is assigned a value of “4939333”. This value is used to XOR each value from the large array. The _local2 array consists of Qwords in decimal and hex formats.

I wrote a program that will convert the Qwords to decimals then XOR the values with an XOR key. It will then write it out in little Endian format just like the ActionScript indicates.


After converting the decimal values to hex and writing it out to a binary file, I get another SWF file (MD5: 04FC52BE437FF46465F42994F0DC5AAE). VirusTotal detects this with 3 out of 53 AV with one saying it’s CVE-2013-0634.


The decompiled version looks like this:


Here we see the exploit code:


This part here writes out the shellcode after base64-decoding it.


The Javascript from the landing page contains the base64-encoded shellcode which is read in by the ActionScript.


The code does look similar to CVE-2013-0634 but my understanding of the Flash exploit tells me this is really CVE-2014-0322.

Anyway, the point of this article was really to make available the tool to convert Qword, Dword, and Word values to decimal. I’ll continue using it and work out any kinks before adding it to Converter. You can download this tool here if you want to give it a try.

http://www.kahusecurity.com/2014/reversing-rig-eks-flash-file/feed/ 0
RIG Exploit Pack http://www.kahusecurity.com/2014/rig-exploit-pack/ http://www.kahusecurity.com/2014/rig-exploit-pack/#comments Tue, 13 May 2014 05:00:47 +0000 http://www.kahusecurity.com/?p=13102 Continue reading ]]> A new exploit pack has been marketed in the underground since last month and appears to be picking up some steam. The new pack is called RIG and touts the following exploits:

Java – CVE-2012-0507, CVE-2013-2465
IE 7/8/9 – CVE-2013-2551
IE 10 – CVE-2013-0322
Flash – CVE-2013-0634
Silverlight – CVE-2013-0074


The pack is said to have an average rate of 8-12% and costs $60 per day or $300 per week.

Here’s what a typical infection chain looks like. Look closely and you can see why this is being pegged as Infinity EK. There are similarities but they are different packs.


On a compromised website, the iframe tag leads to the TDS rotator:


If everything checks out then you get another iframe (the bottom part of the page appears to be a tracker):


On the counter.php page, there’s yet another iframe. This time you get to the landing page of the exploit pack:


The landing page is a large file and consists of five scripts. The top section, through some misdirection and obfuscation, assigns a value of “body” to the “vx” variable which is used by the following four scripts.


Each of the four scripts looks something similar to this. All it’s doing is building up decimal values that are on each line preceding with “pop” to the variable “bui” which is then converted to ASCII and appended to the body element.


This is the result after deobfuscating one of the scripts. This sets up the Java exploit.


Here’s one for Silverlight. You can see the URL to the exploit followed by the shellcode in Base64.


The D&E shellcodes which are passed as a parameter to the exploit code are XOR-encoded each with it’s own unique five-value hex key.


Since the landing page contains all of these scripts, you get hit with several exploits at once leading to multiple payloads asking to bypass UAC. It’s very noisy and inefficient.


If the exploit is successful, the payload is downloaded and executed and then requests are made to the following sites to download crimeware:

zemmes-gimbl .com/b/shoe/1928
chanse-leaf .com/com_phocaguestbook/jquery/

Files called “UpdateFlashPlayer_[random].exe” are downloaded to the temp folder with the hidden attribute set which prompts the user incessantly.

File: applet.jar
MD5: 9c6317f0c22b0782fac5858d0c4c4886
VT: 4/52

File: flash1.swf
MD5: 65aff3a3774298b3ed5ba2c43f8a1979
VT: 0/52

File: flash2.swf
MD5: 40fd69626f5248012b6d5bd2e4d2fc9b
VT: 0/52

File: 264078.exe
MD5: e4f53ece665e71955bf8f9170e3324a1
VT: 9/52

File: ewuwxeu.exe
MD5: ea8dbf470fb0dc41e10d2dcf69f53153
VT: 14/52

File: UpdateFlashPlayer_5386a177.exe
MD5: 60b1cbb5d9af6125d011bd7306afec64
VT: 2/51

File: UpdateFlashPlayer_9609e705.exe
MD5: 8caf8b2f7198bc757541a93267447460
VT: 10/52

http://www.kahusecurity.com/2014/rig-exploit-pack/feed/ 0
8×8 Script Leads to Infinity Drive-By http://www.kahusecurity.com/2014/8x8-script-leads-to-infinity-drive-by/ http://www.kahusecurity.com/2014/8x8-script-leads-to-infinity-drive-by/#comments Mon, 07 Apr 2014 05:40:37 +0000 http://www.kahusecurity.com/?p=13089 Continue reading ]]> The “8×8″ script I’m referring to includes a link that looks like this:
hxxp://www.example .com/JB3xd6iX.php?id=87342871

And can be detected using a regular expression that looks something like this:

One set of links redirect users to social engineering scams (e.g. fake Adobe Flash Player update) that I wrote about earlier. Another set redirects users to Infinity EK (aka “RedKit”, “GoonEK”).

First, let’s see how this drive-by looks like from the users’ perspective.

The user visits a website that’s been compromised. On one of the webpages, there’s a script with the filename containing eight random characters followed by an ID value which has eight digits (i.e. the “8×8″ script).


The user is then redirected to another legitimate website that’s been previously compromised. This site serves up a script that leads to another site.


This site is also legitimate and compromised. It houses the Infinity Exploit Pack script which tries to exploit the user’s browser.


This is what the deobfuscated version of the landing page looks like. If the exploit is successful, there’s a request for the malicious payload file back to the same site.


Infinity has an arsenal that includes two Java, two MSIE, Flash, and Silverlight exploits. The author(s) have been adding updates to their arsenal as well as modifying the links and infrastructure since the last time I analyzed it as RedKit v2.0.

Now let’s look at what’s happening behind the scenes. A webmaster provided me with suspicious files from his compromised website after I informed him his site was redirecting users to a drive-by. (I promised I would not reveal his site name so I redacted and/or modified the following screens.)

Turns out his site was compromised two different times. The first time, the attacker modified at least one HTML page and inserted the following script tags:


Sometime later, the/another attacker modified the index.php file and inserted a PHP script that would download content from another website.


Running this script, makes a request to a backend server and produces a seemingly endless number of new links:


I was very fortunate that the compromised website had both the infected index.php file and the 8×8 script on his server. The link above leads to a PHP script on another site but I’m pretty certain it’s the same as the one below (which is also the same as the one I wrote about earlier).


Deobfuscating the script is no longer a chore so I can extract the contents of the encrypted config string.


Running it produces the TDS IP, key, and other information:


So this is what’s going on…


Here’s a series of packets showing this:


The scripts are all the same and therefore appears to be the work of the same gang behind RedKit v2, Box Fraud, Goon EK, and Infinity.

http://www.kahusecurity.com/2014/8x8-script-leads-to-infinity-drive-by/feed/ 0
Wild Wild West – 04/2014 http://www.kahusecurity.com/2014/wild-wild-west-042014/ http://www.kahusecurity.com/2014/wild-wild-west-042014/#comments Sun, 06 Apr 2014 01:59:52 +0000 http://www.kahusecurity.com/?p=13072 sorry this is so late. added the following packs:

Infinity (aka “RedKit”, “GoonEK”)
Ramayana (aka “DotkaChef”, “DotCacheF”)
Top-Exp (aka “Magnitude”)


http://www.kahusecurity.com/2014/wild-wild-west-042014/feed/ 0
VBE Script Leads to Bank Fraud http://www.kahusecurity.com/2014/vbe-script-leads-to-bank-fraud/ http://www.kahusecurity.com/2014/vbe-script-leads-to-bank-fraud/#comments Sun, 06 Apr 2014 01:54:11 +0000 http://www.kahusecurity.com/?p=13069 Continue reading ]]> I only stumbled on this at the middle so I don’t know how this is being targeted to users. Apparently this particular scam has been out there since at least August 2013 and it’s still up and running.

This is a VBScript Encoded file (VBE) that starts off the fraud:


And it looks like this:


Using a VBE decoder, I can convert the file to get the following. You can go here or here for the decoder.


There’s several functions in this script and the one at the top deobfuscates the content by doing some math to convert decimal values to ASCII. The AppdataPath and File1 variables look interesting so I just add this to the script:


This pops up the deobfuscated values then quits before it executes anything further. Here’s the result which tells us where the file will be written to and where to download the file from.


Let’s get the second VBE file and decode that one as well.


While going through the script, this pops up:


This turns out to be a proxy.pac malicious script! Downloading the third file, I get this obfuscated proxy.pac file.


After I clean this up, here’s what we get:


After analyzing the scripts, here’s what it does…it changes the proxy values in IE and Firefox browsers:


Then, whenever the user visits one of the sites found in the proxy.pac file, they get redirected to a phishing page but the URL bar shows that they are at the right banking site.


Truncating the path reveals an open folder that contain files that make up the phishing page which is a sign we truly are not on the legitimate site.


Here’s what the real banking site looks like:


Packet captures shows that our traffic is indeed being sent to the phisher’s site when we attempt to visit one of those Brazilian bank sites.


Here’s information about the domains and files:

Domain: eua.bestworked[.]com
IP: 64.74.223[.]40

Domain: euas.bestworked[.]com:8082
IP: 64.74.223[.]40

Domain: mn.dmanwork[.]com:8082
IP: 8.5.1[.]49

Filename: update.vbe
MD5: a8f52fb1a543abf5ac18ae2dbc0351e8
VT: 3/48

Filename: seta.vbe
MD5: 3fc44dae258d0316179541db44d09ad7
VT: 4/51

http://www.kahusecurity.com/2014/vbe-script-leads-to-bank-fraud/feed/ 0
Scout — New Tool Released http://www.kahusecurity.com/2014/scout-new-tool-released/ http://www.kahusecurity.com/2014/scout-new-tool-released/#comments Wed, 26 Mar 2014 05:56:11 +0000 http://www.kahusecurity.com/?p=13053 Continue reading ]]> Here’s another tool that you might find useful when analyzing potentially infected websites. Scout is Pinpoint on steroids. Scout uses the Pinpoint engine and includes a feature from Revelo that makes this more functional and…risky. Let me explain.

Pinpoint downloads webpage components akin to using wget or curl. Pinpoint does not render the content making this safe to use even without a VM. Scout, on the other hand, gives you the ability to render content in select files so it can collect the URLs it’s trying to access (Revelo already includes this feature). This is great for those who don’t know how or have the time to deobfuscate Javascript. You just render the script and catch the results. However, if the file contains exploit code, your computer could get infected.

I did consider simply adding the new features to Pinpoint and calling it v2.0 but this could potentially cause confusion since Pinpoint is a safe tool to use so I decided to leave Pinpoint alone and create a new tool called Scout (I’ll still maintain both code bases). As its name implies, Scout seeks information about your target and does so rather progressively.

One other feature I thought would be useful was to give Scout the ability to take a screenshot of the webpage. The best and safest method I could come up with is using PhantomJS. It uses the WebKit browser engine so it’s way more safer than IE but there is added risk since the infected/malicious page has to be completely rendered. That’s the other reason why I wanted to separate this from Pinpoint.

So let’s see this in action…

Here’s Scout with its two new features:


To activate the screenshot capability, download PhantomJS from here and copy the Windows executable to the same folder that Scout resides in. Now the “Take Screenshot” option lights up and you can enable and disable it as you choose. Scout will automatically create “rasterize.js” which is used to produce the screenshot. You can modify it (e.g. change its user-agent string) and Scout will use it going forward.


Here’s what the workflow might look like. Enter a URL then click on start.


After Scout pulls down the main page, it will launch PhantomJS and perform a screenshot of the site which gets saved as a PNG file:


Viewing Scout’s capture file, we see some obfuscated Javascript in the source code. Since the Pinpoint engine won’t render it, we don’t know what this does.


Copy/paste the Javascript and save it to an HTML file. Be sure it has the <script></script> tags (or <html></html> tags as necessary).


Click on Tools > HTTP Request Simulator, choose the file, then click on Start.

What I’ve done is include some of Revelo’s functionality into Scout. There is a built-in WebBrowser Control that renders the URL. As the WebBrowser Control makes requests to external content (e.g. Javascript, CSS, images, etc) or redirects the browser depending on the webpage contents, Scout will collect the links then drop the HTTP responses before it reaches the browser. This should, in theory, prevent your computer from getting compromised but I can’t guarantee it so you ought to run this in a VM.


Here’s another example…

First, let’s paste in the URL and click on Start:


Here’s the screenshot of the site:


Reviewing Scout’s capture file, we see Javascript (exploit code) from Infinity EK:


Extract the script from the page and save it to an HTML file:


Since this has a lot of scripts, the internal WebBrowser Control may not be able to handle it so you can optionally use your Internet Explorer browser. When you run Scout and click on Tools > HTTP Request Simulator, Scout will automatically set IE’s proxy setting to “localhost:8080″ (which is changed back after you close HTTP Request Simulator). All you need to do is leave the “File” field empty, click on Start, then open the HTML page in IE (note: you can do this with Firefox or Chrome too as long as you set the proxy settings yourself).

Here we see IE executing the js.html file with the exploit code. Scout’s HTTP Request Simulator is catching the requests, dropping the responses, and displaying the results. The VM did not get infected but I’ll never run this on my host computer, just in case. And neither should you.


If you don’t see anything in the “results” box then maybe the script doesn’t have any redirect code or doesn’t reference any external content. Or maybe it relies on jQuery in which case you can paste in the jQuery script into your file.

You can download Scout from tools page.

By the way, I do appreciate all of your emails in support of Pinpoint! I’m glad it is helping you with your analysis and I hope Scout can further your research.

http://www.kahusecurity.com/2014/scout-new-tool-released/feed/ 0
Converter Updated http://www.kahusecurity.com/2014/converter-updated/ http://www.kahusecurity.com/2014/converter-updated/#comments Mon, 17 Feb 2014 22:34:48 +0000 http://www.kahusecurity.com/?p=13038 Continue reading ]]> The latest version includes several new features and bug fixes:

  • Fixed Mixed Octal to Hex function to handle null char at the end
  • Fixed and enhanced code related to keep/strip filtering functions
  • Fixed unescape handling of null bytes

Unescape File
Under the File menu > Unescape File allows you to unescape a text file. You have the option to beautify the Javascript using JSBeautifier (Note: if it’s not Javascript, you will likely get disappointing results).


Convert Binary File
Added the ability delete bytes in the File > Convert Binary File function. The bytes are deleted before any action is taken.


Sort Text
Under the Format menu > Sort Text you can now sort by characters, rows, or comma-delimited values.


Range Search/Replace
Under the Tools menu > Range Search/Replace enables you to do a search and replace using one of three methods. While you can also do this using regex in Search/Replace Text, this is another way I thought I’d add.



Key Search/Convert – Calculate Distance
Added a method to have Converter try to automatically find a multi-byte XOR key. You can read this blog post where I describe how this works.

Just import a binary file that you suspect is an executable. You only need the first 1K bytes so leave that checkbox at the top checked. Click on the “Calculate Distance…” option. It will automatically paste in the DOS header string and set it to auto mode. Converter will start using offset 1, 2, 3…until the (near) length of your search string. I found it generated too much false positives if I used the entire length. You can get false positives when you have a short search string or large offset.


Converter, File Converter, and Data Converter can all be downloaded from here. Thank you for your support!

http://www.kahusecurity.com/2014/converter-updated/feed/ 0
Exploring XOR Decryption Methods http://www.kahusecurity.com/2014/exploring-xor-decryption-methods/ http://www.kahusecurity.com/2014/exploring-xor-decryption-methods/#comments Wed, 12 Feb 2014 03:56:59 +0000 http://www.kahusecurity.com/?p=13029 Continue reading ]]> The use of XOR encryption to keep anti-virus, web filters, and even researchers at-bay have been used for many years. While there are stronger encryption algorithms, the XOR cipher is very easy to add to a project, has low overhead, and is still quite effective even today.

Converter has four ways to help you figure out what the XOR key is. For a single XOR key, you can use Converter’s Key Search/Convert. If it’s a PE file it may have the string “This program cannot be run in DOS mode” in the header. Let’s try that. We just need the first 1KB so import the file and leave the “Import First KB” checkbox checked. Make those setting changes and click on the Search button.


The XOR key of 0x8E was found!

If you’re not sure if it is a PE file, you can have Converter enumerate all the XOR values to a text file. To do this, check the “Output First…” box then click on the Search button. Scrolling through the results, you may come across the PE magic and part of the header. The value of 142 is the decimal equivalent of 0x8E.


For XOR keys with more than one value, there’s a couple of ways to find the key besides brute forcing each value. One way is import 1KB of the file once again then copy that to the main screen. Choose Stats > Hex Frequency. The output will show you the number of times each hex value has been seen in the input. Notice that eight hex values show up over 80 times. This is likely the XOR key in no particular order. You can now start brute forcing the file with these values. :)


The second way is to paste the imported data and then choose Tools > Pattern Finder. Converter will try to find the longest repeating pattern in the data string. This will take awhile but you will hopefully get decent results like this:


This isn’t the actual XOR key. You could copy the output to the input box and have it look for the next longest repeating pattern again (and again). But you don’t need to. Here is the result of the first pass:


You can see a pattern with the following string being repeated many times:


They look like hex values but we don’t know where one ends and the other begins. One clue is to look at the hex frequency screenshot above. It’s the same values! But we don’t know what is the first value of the XOR key is.

Going back to Key Search/Convert, delete all of the input data except for the first two characters which is 0x80 in this case. Search for “M”. We get the result 0xCD which is the first value in the XOR key.


Now we can figure out what the 8-byte key is:

0xCD 0x43 0x08 0x9E 0x77 0xA6 0x30 0xFD

Let’s test it out…it works!


A couple of weeks ago, I read an article called, “Efficient Detection of XOR-Encoded Traffic” by Josh Homan. This concept is not new but for some reason, his excellent write-up caught my eye so I started to study this more closely. I tried using other algorithms besides XOR but I couldn’t come up with anything more efficient and effective.

Please check out his article as he did a great job explaining the concept (thanks Josh!). The basic idea is to look for the same distance between two values in the input data. Let’s use the same string Josh used in his example,

This program cannot be run in DOS mode.

The distance between “T” and “h”, “h” and “i”, “i” and “s”, etc would be the same even though the string has been XOR-encrypted with a single XOR value. If the XOR key is four bytes for example, then you need to offset by the same value and look for the same distance between “T” and ” “, “h” and “p”, “i” and “r”, etc.

I’ve added the concept to the next version of Converter which I’m still testing. I had to modify the Key Search section to accommodate for this but it seems to work pretty well. I do get false positives when the search string is short or the offset is large.

To use this feature, import 1KB of your data and choose “Calculate Distance…”. Converter will pre-fill the Match String for you. If you toggle between Single Key Search and Calculate Distance, the Match String will switch between “This program cannot be run in DOS mode.” and “This program must be run under Win32″ for you.

If you leave the offset at 0, it will automatically go through the length of your search string and will try to find the first match. Enter an offset if you want to try a specific XOR key length.


The same 8-byte XOR key is found but again, we’re not sure what value goes first. Paste the key, set the options, and click on Convert. If that doesn’t work, you need to shift the XOR key over by one so just click on the new “Rotate Key” button and it does it automatically.


Once you have your key, use Converter’s File > Convert Binary File to process the entire file.

Again, it’s not perfect and you will encounter false positives but should give you a great starting point.

So then I thought, why stop at this — why not have a tool that can automatically XOR-decrypt a file? I needed to find a good live example to test my theory on…

By now I’m sure you have read about GameOver ZeuS now using encryption to get their files past network security. If not, you can read these two write-ups:

CyberCrime & Doing Time – GameOver Zeus now uses Encryption to bypass Perimeter Security
CrySyS Blog – GameOver Zeus now uses Encryption to bypass Perimeter Security – .enc encryption

Based on CrySyS’ writeup, the downloader program downloads an “.enc” file, XORs the file with a four-byte key, then decompresses it using LZNT1. If I had to do this manually, I would either extract the key from RAM after running the downloader or figuring out the key in Converter as described above. But by using Josh’s technique, I can automatically find the key.

Here’s the plan for a POC:

  • Open the “.enc” file and check for the “ZZT ” magic (0x5A5A5000)
  • Remove the magic bytes
  • Calculate the distance for “program” then shift the XOR key over by one
  • Decrypt the file using the XOR key
  • Write it to a temp file (for debugging purposes)
  • Uncompress the file using LZNT1
  • Write out the PE file

The LZNT1 tool they used isn’t able to decompress everything for some reason. I had the same problem too but this works most of the time. There is a debug checkbox that will show you the XOR key it found and preserve that temp file so you can check it out.

I found three live samples here:
hxxp://farmyarddog .co.uk/images/pdf.enc (97B200826B7A526D91FDA4C56DC438AE)
hxxp://svsmills .com/images/pdf.enc (2FF56C80DAE376FED059E12033690DFC)
hxxp://mararu .ro/Media/07UKex.enc (9DF4F00EF32806905C3E92286FDE7F0B)

Here’s the hex view of one of the files showing its magic bytes:


I run the program on each of the files:


And I get back three decrypted and uncompressed files automatically:

decrypted1.exe (542A5A6F04DDCAD3EFFC72121C59E332)
decrypted2.exe (11E9BF6E9FEDD3EC64163594371BA790)
decrypted3.exe (49686AB2AE3ECF219024A6E4F990AB79)

Here’s the hex view of the temp file (after it’s XOR’d and before it’s decompressed). If you look closely you’ll see that there are some null bytes in the DOS header which is why the program isn’t searching for the entire header string, just the word “program”.


Few notes:

  • If the .enc file doesn’t have the magic bytes then the program will end
  • If the XOR keys cannot be found automatically (probably because the file is not a PE), the program will end
  • If the decompression process fails for some reason then you might get a small file with partial results

You can download the tool from here.

http://www.kahusecurity.com/2014/exploring-xor-decryption-methods/feed/ 0
Pinpointing Malicious Redirects http://www.kahusecurity.com/2014/pinpointing-malicious-redirects/ http://www.kahusecurity.com/2014/pinpointing-malicious-redirects/#comments Sat, 08 Feb 2014 20:36:28 +0000 http://www.kahusecurity.com/?p=13017 Continue reading ]]> Cybercriminals are constantly thinking up new ways to redirect unsuspecting visitors to their drive-by landing page. The guys over at Sucuri often find really interesting redirects that they’ve come up with.

What I have been doing lately is documenting these redirection methods so that I can program Pinpoint to look for these methods when it analyzes webpages. I believe it’s useful to identify these methods so that you can tell if it’s an Infinity EK (aka RedKit, GoonKit), ramayana EK (aka DotkaChef), DarkLeech, or another type of website infection.

Here’s what I collected so far. Some of these methods are deprecated, browser-specific, or won’t work unless the browser is in compatibility mode but I’ve captured them anyway (btw, these two sites were very helpful).

Meta Refresh
<meta http-equiv=”location” content=”url=http://www.google.com” />
<meta http-equiv=”refresh” content=”0;url=http://www.google.com” />

Javascript Redirect

<div style=”width:expression(document.location(“http://www.google.com”))”>hello</div>

<img src=”missing.jpg” onerror=document.location=”http://www.google.com”;>

By changing the data type to Javascript, it will decode and execute the script that’s in base64:

<script src=”data:text/javascript;base64,dG9wLmxvY2F0aW9uPSJodHRwOi8vd3d3Lmdvb2dsZS5jb20iOw==”></script>

You don’t actually need to define the data type as this works too:

<script src=”data:;base64,dG9wLmxvY2F0aW9uPSJodHRwOi8vd3d3Lmdvb2dsZS5jb20iOw==”></script>

Same thing here except the data type is set to HTML:

<object data=”data:text/html;base64,PHNjcmlwdD50b3AubG9jYXRpb249Imh0dHA6Ly93d3cuZ29vZ2xlLmNvbSI7PC9zY3JpcHQ+”>

By saving the redirect content in an external file, it will be read and executed with this:

<object data=”redir.htm” type=”text/html”>

In this redirect example, the name of the file holds the key. The script reads in the filename and after subtracting 5 from the decimal equivalent of the characters, converts it to “google.com” which you are redirected to.


I saw a similar example in the wild awhile back. In this script, I assigned colors of various parts of the webpage but those are actually decimal values of the redirect script.


First, let me show you what the webpage looks like. I just searched for random images on Google and put them on the webpage.


Now have a look at the source code and you can see what I’m using the images for. The script grabs the width and height of each photo and converts these decimal values to text which is the redirect script. This one took a lot of patience since I had to resize each picture to the decimal values I needed without overly distorting the images.


For this redirect I use the obfuscation method found in live examples and combine it with the technique above. The logo.png’s width and height was also resized to the decimal values I needed then referenced by the script. This value is the key (multiplier) that converts the “x-y coodinates” at the top into the redirect script.


Here, I embed a secret value at the end of a PNG graphic file. I use VBScript to extract the bytes I needed which are converted into the redirect script.


Here’s the shot of the data I added to the graphic file using a hex editor.


Here’s a crude method to extract data from a photo, convert the bits into text then eval the result. This works on older versions of IE. The code, Binary Ajax, from this site can be used to make this work on newer versions.


To make this, I just grabbed a random image from Google:


Then I added the hex equivalent of the redirect script in the “Authors” field.


The bytes are extracted with the help of VBScript. The Javascript portion converts the hex to ASCII and evaluates it. And like the rest, you end up on google.com.

Besides detecting these methods (or at the least captures the main parts and writes it out to the cleaned up output file for your review), the latest version of Pinpoint now includes several new features and bug fixes:

  • Removed log option since that should always be enabled
  • Added stats to log file (multiple calls will be counted each time)
  • Included the HTTP request to the raw log file
  • Ability to add to the header (use ^p to insert CRLF)
  • Finds links on a webpage up to five levels deep
  • Ability to access webpages when a port is specified (e.g. example.com:8080)
  • Ability to make a GET or POST on the initial request
  • Unescapes links before making a request to them

Here’s a live example of Pinpoint doing its thing. (If you want to see more examples, you can read this introductory post.)


You can see an iframe tag with a strange-looking URL in the above pic. Viewing the log file reveals that this file has a high “entropy” value of 86.35% and is referenced on the main page.


The file called “pinpoint_clean.txt” is a cleaned-up version of the webpages that only shows key elements. Here you can see the malicious iframe tag.


You can download Pinpoint here.

http://www.kahusecurity.com/2014/pinpointing-malicious-redirects/feed/ 0