Drupal 7 SQL Injection Info

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!

Posted in Malscript | Tagged , , , | Comments Off

Tools Update

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!

Posted in Tools | Comments Off

Javascript Deobfuscation Tools Redux

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.


Posted in Malscript, Tools | Tagged , , , , , , | Comments Off

Detecting Phishing Sites in Your Logs

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!

Posted in Tools | Tagged , , , | Comments Off

A Quick Peek at Network Injection

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)

Posted in Pentest, Tools | Tagged , , , | Comments Off