Tornado exploit pack

Like most other exploit packs it's written in PHP with a MySQL backend. Control panel supports configuration options for several users (attackers).

Has the ability to control incoming traffic. It can either:

- Ignore
- Redirect
- Display custom page

based on several criteria such as:

- Country of origin
- Visitor uniqueness
- Vulnerable client
- Not vulnerable client

Displays several different statistics based on:

- Victim's Country
- Originating web site (referer)
- Exploits used
- Detailed Log (IP, time, browser, exploit used, infected (yes/no), and referer)
- Overall Summary - OS and Browser breakd down of traffic and exploit effectiveness

Exploit is delivered in the form of obfuscated javascript. Obfuscated ASCII encoded code and decryption function are delivered to the client as a single long line. This content is unique on every visit except certain parts of the decryption routine. Upon successful exploitation another request will be made to the exploit server to a different script which will deliver the binary to execute.



The following is a list of exploits available to the attacker, which can be individually selected to target:

- MDAC (RDS)
- WebViewFolderIcon.SetSlice
- VML
- MS06-044
- WMF Firefox
- WMF Opera 7
- QuickTime
- WinZip
- Zenturi
- Yahoo Webcam
- Opera 9 - 9.20
- XML Core Services
- Java bytecode
- ANI

Default script for exploit delivery is "count.php", while individual exploit modules are located in the "exploits/" directory with the following naming convention: "x#.php" where # is the numeric value starting with one (1).

Upon successful exploitation another request will be made to retrieve a binary for execution on victim's computer. By default the requested script will be "getexe.exe" with the following parameters:

?o= integer value to identify attacker
&t= integer value represents time the exploit was generated
&i= integer value represent IP address of victim
&e= integer value represents exploit number used

Following is the schema of the database:

CREATE TABLE `stats1` (
`ip` int(10) unsigned default NULL,
`time` int(10) unsigned default NULL,
`country` tinyint(3) unsigned default NULL,
`browser` tinyint(4) default NULL,
`version` varchar(8) default NULL,
`os` tinyint(4) default NULL,
`refdom` varchar(32) default NULL,
`status` tinyint(4) default NULL,
`loader` tinyint(4) default NULL,
`expl` tinyint(4) default NULL
) ENGINE=MyISAM DEFAULT CHARSET=cp1251;

CREATE TABLE `users` (
`id` smallint(5) unsigned NOT NULL auto_increment,
`user` varchar(16) default NULL,
`pass` varchar(32) default NULL,
`premis` tinytext,
`options` tinytext,
`lasttime` int(10) unsigned default NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=cp1251 AUTO_INCREMENT=1;

Improvements to Zeus

Zeus's development is active these days. Below is a table of release dates for each version:

2008/12/20 - 1.2.0.0
2008/12/30 - 1.2.1.0
2009/03/11 - 1.2.2.0
2009/03/28 - 1.2.3.0
2009/04/02 - 1.2.4.0

This change log entry states that during HTTP communication of the Trojan with the C&C server the User-Agent used will be that of system's Internet Explorer. Before, it was a constant string embedded in the binary, which could have raised suspicion or blocked by ISPs.

Zeus / Zbot / Prg / Ntos / Wsnpoem

Real name of the trojan package is Zeus. It comes with a PHP based control panel and a Windows executable to build the trojan. Builder's job is to parse a text based config file, encrypt it, and embed some options into the trojan. The builder can also remove the infection from the system.



Main scripts of the control panel are:

"in.php"

Script which controls authentication to the admin panel as well as all reporting and configuration options of the botnet.

"s.php"

This is the script which accepts all communication from the bot client on a compromised computer. Depending on configured options it will either insert the data into a MySQL database, or store inside a seperate directory, or both.

It's responsable for decrypting the POST data and parsing individual stolen records. Basically, this is the main C&C script of the botnet.

Keep in mind that these filenames are not hardcoded anywhere but are only the defaults. If the filename is changed on the server then the bot client must be updated with a new configuration file, which it periodically polls off the server. Typical configuration file will have entries similar to the ones on this screenshot.

Currently, Zeus' build tree is 1.2.x.x which, depending on subversions, will utilize either RC4 encryption or a simpler form of it. Otherwise, the record and configuration structures remain the same between different 1.2.x.x builds. Older versions, prior to 1.2.x.x used a completely different structure and obfuscation method. They contained a unique field in the HTTP headers during C&C communication and thus were easily detected via IDS signatures from Emerging Threats (2003182, 2003183, 2007688, 2008100, 2008326)

So, what can this bot/trojan do?
It has the following abilities:

Credential stealing of FTP and POP3 on any TCP port.

Via a custom build can capture any data.

Capture of HTTP and HTTPS traffic.

Proxy server via Socks 4/4a/5, even if compromised device is behind a NAT.

Screenshot capture of the desktop.

Theft of "Protected Storage" data.

Here's an example how a communication flow between bot/trojan and C&C server will look like.

Unique Pack

Exploits for Opera9, Firefox, Internet Explorer 4, 5, 6, and 7. Seperate module to exploit Adobe Reader util.printf() (CVE-2008-2992) vulnerability. Also, includes a module to deliver binaries via social engineering the visitor into accepting the download, similar to Fake AV.

So, what's so unique about it? Nothing really. Perhaps the fact that it obfuscates its PHP code which contains exploits, which isn't difficult to take off. Also, maybe because it doesn't use any parameter passing to scripts via URL, as most other packs do. Here's a summary of some scripts:

"cfg/config.php"

Defines variables for loader and exploit URLs, database credentials, and control panel credentials.

URLs are defined for loader script ("load.php") and Adobe PDF exploit ("pdf.php").

Filename of binary which will be dropped ("1.exe").

Database host, name, credentials. Default DB name is "spl".

Control Panel's script name ("admcp.php"), username, and password (double MD5 hash of real pass). Default user is "root".

"cfg/options.php"

Defines functions and text for 404 page. Functions to identify browser, operating system, country (based on GeoIP), and encoding function to Unicode for Javascript (eg: "%u9090").

"cfg/mod_vparivatel.php"

Configuration variables for social engineering module to convince the user to download the binary, similar to the idea used in RogueAV schemes.

"install.php" or "_install.php"

Database creation script. Will connect to the database with configured credentials and create necessary table.

CREATE TABLE `statistic` (
`id` int(10) NOT NULL auto_increment,
`ip` varchar(15) default NULL,
`os` varchar(30) default NULL,
`br` varchar(30) default NULL,
`country` varchar(2) default '--',
`good` int(1) NOT NULL default '0',
`mv` int(1) NOT NULL default '0',
`refer` varchar(300) NOT NULL,
`date` datetime default '2008-10-01 00:00:00',
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=cp1251 AUTO_INCREMENT=1;

"index.php"

Checks for presence of "install.php" and executes it. If visitor's IP was already logged then aborts with HTTP 200 status but shows a 404 page as defined in the variable of the "cfg/options.php" file.

Identifies country, browser, operating system, referer, IP address and updates the database. Includes "sploit.php" file for exploit generation.

"sploits.php"

Checks if "Unique" name is defined and aborts with 404 message from predefined variable if not defined. Determines the browser and loads appropriate exploit script:
"sploit/op9.php" - Opera
"sploit/ff.php" - Firefox
"sploit/ie7.php" - Internet Explorer 7
"sploit/ie.php" - Internet Explorer 4, 5, or 6.

"load.php"

Reads the executable which was defined in config file and serves it to the user. Updates database column "good" for this connection's IP address.

"pdf.php"

Contains the exploit for Adobe Reader ; CVE-2008-2992 ; util.printf(). Interestingly, the file contains obfuscated PHP script to generate the exploit. It has some protection against people attempting to modify the code and print out the exploit. It reads itself and looks for calls to "print | sprint | echo" and aborts if found. This prevents people from simply modifying the "eval" statement to see the real exploit code.

"vparivatel.php"

Delivers an executable file using social engineering technique similar to RogueAV by convincing the user of a threat or some required update. Messages can be customized per browser, operating system, and country.

Checks if visiting IP was already given a binary using this method and aborts if found.

If GET parameter "?a" is set then delivers the binary otherwise displays a convincing message and redirects back to itself with proper parameter.

Armitage 1.0

This is a rather old version dated back to November 2007 but perhaps someone will find this info useful.

On the server side it's driven by PHP with MySQL as the backend. File structure is similar to other packs. One noticable difference in the way statistics are tracked, as all packs track visitors and these numbers are used in marketing of packs.

Armitage has an additional section to calculate how many visitors were actually compromised. Typically this is done by recording how many people request a download of a loader (trojan binary) which means the exploit worked. However, this does not account for the fact that loader may have been blocked on the client due to various defenses. Any pack's job is to deliver an exploit and load some binary and many packs are satisfied with just recording such requests. In Armitage's case it is accomplished by recording an additional request which must be made by this loader. This statistic will represent how many devices have been compromised and have gotten the loader to fully execute and check-in. It is unclear why this decision was made for a generic pack since loaders will now have to be specifically written to perform this check-in function. Such loader was not distributed with the pack itself so it is possible that this was not written for general public.

"config.php"

Contains password variables for admin and guest.

"db.php"

Defines variables needed to establish database connection (host, schema, user, and password).

"install.php"

Establishes a database connection and creates the necessary tables. Once complete shows a link to admin page and required credentials.

"admin.php"

Defines two valid accounts admin and guest. Shows traffic and loads statistics as well as has the ability to upload a new trojan and change passwords.

"index.php"

Defines various functions which identify the visitor based on UAS.

Creates the URL for loader "exe.php" and if GET contains "?ex=" integer then this value will be passed to "exe.php?ex=".

Checks visitor's IP address for previous visits and aborts if one is found. String "^_~" is returned upon abort.

Identifies the browser, the following list is used: Opera, Konqueror, Lynx, Links, Internet Explorer, Netscape, Firefox, Mozilla, Other.

Identifies the OS with the following list: Windows (95, NT 4, 98, ME, 2000, XP, 2003, Vista), Linux, Mac OS, Other.

Identifes the Country based on GeoIP library from visitor's IP address. Geoip files are borrowed from Icepack.

Updates statistics for HTTP Referrer, domain only. Sanitizes the referrer domain to avoid SQL injection.

Updates statistics for Browser, OS, and Country. Inserts visitor's IP address and time of visit.

Exploit is served for Internet Explorer from "e.php", for Opera from "opera.php", and Firefox from "ff.php".

"exe.php"

Second stage of the exploit sequence, which serves the binary file. By default it is "./load/file.exe", but if GET "?ex=" integer was set then file with that value is delivered (eg: "./load/file20.exe"). Identifies the visitor (Browser, OS, Country) and updates "loads" statistics table.

"lds.php"

Identifies the Country based on Geoip of the connection and updates the "ots" (otstuk) statistics table. This is the place where loader's check-in stats are kept.

"e.php"

Serves the MDAC exploit slightly obfuscated. CVE-2006-0003 ; MS06-014 ; MDAC (BD96C556-65A3-11D0-983A-00C04FC29E36). If this fails then will load "bof.php".

"bof.php"

Contains the shellcode for buffer overflow exploits.

Serves the WFI exploit. CVE-2006-3730 ; MS06-057 ; "WebViewFolderIcon.WebViewFolderIcon.1.setSlice()".

At the end display the 404 Not Found page which is fake since real HTTP Status code is still 200 OK.

"ff.php"

Serves exploits for Firefox browsers

"opera.php"

Serves exploits for Opera browsers

PE offsets within malware

Building on work mentioned in the previous post couple of more interesting facts were identified. Realizing that implementing the Snort's SO rule may not be feasible in some infrastructures, depending on the design and configuration of the sensors, it would be beneficial to identify most common offsets used by malware and how they compare to legitimate executables.

After reviewing offsets found in an installation of Windows XP SP2 system utilizing 8000 samples, both executable and DLL files, and then comparing with offsets found in malware collected over the last year and a half (450 samples) there were several unique offset identified which were solely used by malware.

As a result of this several regular Snort signatures can be written which will alert on download of binaries which should raise suspicion.

alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"LOCAL Suspicious Executable (PE under 128)"; flow:established,from_server; content:"MZ"; rawbytes; byte_test:4,<,128,58,relative,little; content:"PE|00 00|"; rawbytes; within:130; sid:62; rev:1;)

alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"LOCAL Suspicious Executable (PE offset 12)"; flow:established,from_server; content:"MZ"; rawbytes; byte_test:4,=,12,58,relative,little; content:"PE|00 00|"; rawbytes; within:14; sid:53; rev:1;)

alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"LOCAL Suspicious Executable (PE offset 16)"; flow:established,from_server; content:"MZ"; rawbytes; byte_test:4,=,16,58,relative,little; content:"PE|00 00|"; rawbytes; within:18; sid:54; rev:1;)

alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"LOCAL Suspicious Executable (PE offset 64)"; flow:established,from_server; content:"MZ"; rawbytes; byte_test:4,=,64,58,relative,little; content:"PE|00 00|"; rawbytes; within:66; sid:55; rev:1;)

alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"LOCAL Suspicious Executable (PE offset 96)"; flow:established,from_server; content:"MZ"; rawbytes; byte_test:4,=,96,58,relative,little; content:"PE|00 00|"; rawbytes; within:98; sid:56; rev:1;)

alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"LOCAL Suspicious Executable (PE offset 124)"; flow:established,from_server; content:"MZ"; rawbytes; byte_test:4,=,124,58,relative,little; content:"PE|00 00|"; rawbytes; within:128; sid:57; rev:1;)

alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"LOCAL Suspicious Executable (PE offset 144)"; flow:established,from_server; content:"MZ"; rawbytes; byte_test:4,=,144,58,relative,little; content:"PE|00 00|"; rawbytes; within:146; sid:58; rev:1;)

alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"LOCAL Suspicious Executable (PE offset 152)"; flow:established,from_server; content:"MZ"; rawbytes; byte_test:4,=,152,58,relative,little; content:"PE|00 00|"; rawbytes; within:154; sid:59; rev:1;)

alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"LOCAL Suspicious Executable (PE offset 160)"; flow:established,from_server; content:"MZ"; rawbytes; byte_test:4,=,160,58,relative,little; content:"PE|00 00|"; rawbytes; within:162; sid:60; rev:1;)

alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"LOCAL Suspicious Executable (PE offset 512)"; flow:established,from_server; content:"MZ"; rawbytes; byte_test:4,=,512,58,relative,little; content:"PE|00 00|"; rawbytes; within:514; sid:61; rev:1;)

Couple of interesting and important notes. There was not a single legitimate binary which contained a PE offset under 128 bytes. The offsets in malware which did not match those of legitimate files occured in %25 of malicious samples.


All offsets found:

Suspicious PE offsets (malware of 467 samples):
-----------------------------------------------
12, 16, 64, 96, 124, 144, 152, 160, 512

Legitimate PE offsets (XP Sp2 8582 samples):
--------------------------------------------
128, 168, 176, 184, 192, 200, 208, 216, 224, 232, 240, 248, 256, 264, 272, 280, 288, 296, 304, 312, 320, 336, 344, 392, 584, 592, 600, 608, 616, 624, 632, 1024, 7680

Neosploit devel/updates retired! However...

It seems that development of this exploit pack has ended. The message basically states that efforts which are put into development are not returning enough income and supported is ending.

However, this does not mean that you will no longer see exploits delivered via this framework. There are many installations of it out there and it's still one of the best exploit packs, although it was expensive. Also, the Neo folks have released instructions/script on how to move the CGI program from one server to another. Previously, this had to be done with the help of Neosploit Support, as the binary was compiled for specific server. If source code is leaked out or released then it's highly likely that more malware will be delivered through it.

Now, that background info behind us, we have seen something interesting which leaves more questions then answers. We have identified a site which utilizes this pack to drop a binary which seems to be associated with the recent fake Antivirus malware.

What is of most interest is the fact that the obfuscated script, mainly the deobfuscation function has some modifications to its code. Several key statements were rearranged in such a way that logic isn't changed.

Why make such a change? Is it a change or some older build which had a short life span and wasn't updated since? We've been keeping an eye on Neosploit's progress for many months now and have never seen this code sequence. We have observed similar minor changes before, during active development, but now since it's supposedly retired the update does stand out. Is it possible that source code was leaked? or did someone just modify the binary in place, and for what purpose, evade detection?

More research is needed to confirm if this change occurs elsewhere, on other domains hosting Neosploit.

le fiesta - another exploit pack

This is yet another web based exploit pack which utilizes PHP and SQL. Overall, it's similar to the other PHP based packs except here the file structure is much more compact, not that it really matters, and it's less smart about serving out exploits (not loaders) to already visited victims.

Uses two layers of encryption/obfuscation via Javascript with random function and variable names upon each visit. Here's a rough list of included exploits:

COM objects

(see metasploit)

"?spl=com"

EC444CB6-3E7E-4865-B1C3-0DE72EF39B3F CreateControlRange

"?spl=vml2"

DirectAnimation.PathControl

"?spl=wfi"

WebViewFolderIcon.WebViewFolderIcon.1 setSlice()

"?spl=zango1"

8C875948-9C60-4381-9248-0DF180542D53 DownloadAndExec()

"?spl=zango2"

BFC08CFF-C737-4433-BD5A-0EE7EFCFEE54 DownloadAndExec()

"?spl=myspace"

48DD0448-9209-4F81-9F6D-D83562940134

"?spl=ymj"

5F810AFC-BB5F-4416-BE63-E01DD117BD6C AddImage()

"?spl=buddy"

Sb.SuperBuddy.1 LinkSBIcons()

The ?spl= parameter will be passed to "load.php" which will update statistics of each exploit.

Analysis of the Adobe exploit within Neosploit

It appears that currently the toolkit is under active development. Adobe vulnerability which is exploited is one from CVE-2007-5659 disclosure.

We have seen some old exploit being added, removed, then added again. This was the MS06-067 DirectAnimation.PathControl.KeyFrame() vulnerability. More on this one later.

The function which exploits Adobe vulnerability (CVE-2007-5659) will try to load ActiveX controls in the following order:

1. AcroPDF.PDF
2. PDF.PdfCtrl

If successful then it'll identify the version in use and will continue only if it's below 8.1.2, which makes sense since Adobe realeased an unpdate with this version that fixed the issue. Then, the version is inserted into an already embedded URL string to download the actual PDF file.



Returned PDF file is around 10K in size and contains Zlib compressed obfuscated Javascript. Thus, any IDS detection which looks for the vulnerable code will not pick this one up. Obfuscation method is the same as for all other pages. After peeling this layer off one finds the familiar heap spray function to populate memory with the shellcode. Then, once again a version check is performed. Finally, a long string is created (~ 44K) and used as an argument to Collab.collectEmailInfo() method.



If the overflow works, then the shellcode will GET a URL which is the same as the one before except for one changed byte (from 01 -> 02), perhaps to track which stage is requested. That file is an Executable which will be saved in the user's Temp directory as "sxoC.exe".

For those who rely on HIDS/HIPS, AV, nIDS/nIPS chances are nothing will be seen, unless the dropped binary gets picked up by AV (right!).

Neosploit development update

For the past month or so we have been observing more activity in Neosploit's development. Exploits are being removed then added and new ones introduced. To be fair in relation to the previous post we can now confirm that Adobe exploit IS being used by this toolkit.

Another interesting change is less obvious and not so important to Incident Responders but more so for Intrusion Detection folks. The main Javascript deobfuscation function has seen some changes recently. So, those of you who depend on IDS to detect the script should probably review their traffic, honeypots, hids, etc... for new changes.

Neosploit update and changes

Some interesting changes we have observed:

- URL scheme changed
- Javascript deobfuscation updated
- Vulnerabilities exploited changed

Javascript deobfuscation code has changed a bit. Previously, to get to the actual exploit code one had to go through two decryption stages, this time an additional stage is added to the very first layer. This additional layer does not make a request out to the server.


Basically, upon first visit to the Neosploit site a browser gets one big obfuscated Javascript page. It executes the decryption function which results in another obfuscated javascript layer. This second layer decrypts itself and then runs real javascript of the first stage. This stage adds some encoded parameters to the URL for the second stage.


URL scheme for requests to exploits and binaries has been updated. It appears that a full structure is passed as a parameter to the main script. This struct is hex encoded as a string and uses various flags and variables to track victims and statistics.


Javascript decryption function utilizes the "arguments.callee" trick to convert itself into an uppercase string and use offsets within this string to decrypt the payload. This is the main deobfuscation characteristic of Neosploit. Several changes have been made previously which break down the methods into seperate variables instead of using them directly.


An interesting addition has been included recently, which appends Neosploit's web address to the decoding offset string. Thus, to successfully decrypt the payload the original full address of the script must be known. Also, at the exploit stage there's a function which sets a unique cookie ("ID") with a specific value for a given exploit.


Stage 1

First stage is the initial visit (iframe, redirect, ...) to Neosploit page. At this point a structure is created based on public variables such as the User Agent string and IP address. Then the server returns obfuscated Javascript page, which is dynamically generated with random variables, and contains the first part of the URL for the next stage.

Stage 2

This stage is obfuscated with two layers and then attempts to identify the victim's Service Pack level, and system's language then builds a request string with these parameters to get the second stage. This request URL has a specific argument to the main script. First part is added by the server upon initial visit and consists of various hashed parameters then SP level and language string is appended.

Stage 3
Deobfuscation yields the exploit code for the following vulnerabilities (in exploit order):

- CVE-2006-0003 ; MS06-014 ; MDAC (BD96C556-65A3-11D0-983A-00C04FC29E36)
- CVE-2006-5820 ; "Sb.SuperBuddy.LinkSBIcons()" ; Cookie ID = 9
- CVE-2007-5779 ; "GomWebCtrl.GomManager.1.OpenURL()" ; Cookie ID = 13
- CVE-2008-1472 ; CA BrightStor ArcServe Backup AddColumn() (BF6EFFF3-4558-4C4C-ADAF-A87891C5F3A3) ; Cookie ID = 21
- CVE-????-???? ; "QuickTime.QuickTime.4" ; Cookie ID = 6

PS: Symantec stated that recent Adobe vulnerability was being exploited by this toolkit, however the instance which was analyzed for this post did not include any Adobe exploits.

Neosploit update

For a while now we have been observing version 2.0.15 used by many malicious sites. However, it seems that recently there's been an update to the toolkit.

There were two exploits added, initially reported by Exploit Prevention Labs, and some slight changes in the decryption function of the obfuscated Javascript. Also, minor changes in the URL scheme used to track statistics on visitors and victims.

Here are the vulnerabilities exploited as of today:

"Internet Explorer"

(3) - cve-2007-0018 "NCTAudioFile2" ActiveX control "SetFormatLikeSample()" method (77829F14-D911-40FF-A2F0-D11DB8D6D0BC)
(7) - cve-2006-4777 "DirectAnimatioin.PathControl" ActiveX control "KeyFrame()" method (D7A7D7C3-D47F-11D0-89D3-00A0C90833E6)
(9) - cve-2006-5820 "Sb.SuperBuddy.LinkSBIcons()"
(12) - cve-2006-3730 "WebViewFolderIcon.WebViewFolderIcon.1.setSlice()"
(13) - cve-2007-5779 "GomWebCtrl.GomManager.1.OpenURL()"
(19) - cve-2008-0624 Yahoo! Music Jukebox DataGrid ActiveX control AddButton() method (5F810AFC-BB5F-4416-BE63-E01DD117BD6C)
(20) - cve-2007-2222 MS07-033 Microsoft Speech API ActiveVoice control (EEE78591-FE22-11D0-8BEF-0060081841DE)

"Firefox"

cve-2006-0005 Windows Media Player Plugin MS06-006
cve-2007-0015 QuickTime RTSP Response Header Content-Type

Adpack analysis

Adpack stands for "Advanced Pack" and was written in PHP on the server side along with SQL backend for tracking and statistics.
Analysis was performed on a toolkit which had file timestamps of September 2007.
The pack attempts to exploit the following vulnerabilities:
- MS06-014 (MDAC)
- Java ByteVerify
- Opera 9 (?)

URLs as seen by the victim:

"index.php" - collects statistics and serves the obfuscated Javascript.
"index.php?java" - returns HTML page to load Java applet.
"java.php" - returns a JAR archive for the Java exploit.
"load.php" - returns an Executable file (default: "load.exe").

Details on server side execution of PHP:

"load.php"

Inserts victim's IP address into the database under the compormised table ("ips2").
If unable to INSERT then returns plain text string: "ai siktir vee?".
Increment the "loads" count.
Return an executable file ("load.exe") with MIME type: "application/octet-stream".

"index.php"

Check if configured to serve the Java exploit and URL parameter contains a request for it, and
IP address already visited this script (to get the redirect), and IP address has not been exploited,
only then serve the <applet> tag.

Insert IP address into the database under visitors table ("ips"). If IP address already exists the update will fail.
Failure to INSERT will abort the script and return the same string as for "load.php".

Increment statistical counts for Browser, Operating System, and Country.
The following browser strings are tracked:
"MSIE 7", "MSIE", "Nav", "Lynx", "Bot", "Firefox", "Mozilla".
Following is a list of Operating System strings which is tracked:
"Windows 95", "Windows NT 4", "Win 9x 4.9", "Windows 98", "Windows NT 5.0", "Linux",
"SV1" (as WinXPsp2), "Windows NT 5.1", "Windows NT 5.2", "FreeBSD", "Gentoo", "Ubuntu"

Uses the GeoIP library to identify visitor's country.
Stores the Referer's FQDN field and increments its count.

Passes control (include) to "exploits.php" which serves the Javascript.

"exploits.php"

Defines the Javascript's obfuscation code and the URL used to obtain the Executable file.
By default URL resides in the same directory as the "index.php" script and will be called

"load.php"

Javascript obfuscation function is a simple static single byte XOR routine.

If Java exploit was requested then serve the HTML applet tag with JAR archive as "java.php",
class to run "BaaaaBaa.class" and a single parameter "url" with value of the URL for the Executable.

OR, if browser is "MSIE" then return the obfuscated HTML page.
HEAD will contain a 3 second redirection timeout to the Java exploit URL ("index.php?java").
Rest is Javascript code for the MDAC (MS06-014) exploit.

OR, if browser is "Opera" serve an Opera exploit which will reconfigure a preference for the
TN3270 handler to execute the downloaded Executable file.

"mysql.php"

Connects to the database as defined in "config.php".
Contains definitions for various functions which are used by the toolkit.
:) - contains a blind SQL Injection vulnerability.

"install.php"

Creates the necessary tables in the database. If tables already exists they will be dropped.

"config.php"

Contains the Database configuration and credentials, pack's admin credentials, name of the Executable file.
Boolean toggle for Java exploit.

"admin.php"

Admin page which displays various statistics and allows to reset statistics.
Requires authentication.

Firepack Analysis

Firepack 0.18
Exploit toolkit which utilizes PHP on the server side, on the client Javascript and Vbscript and exploits only MSIE 6. Instead of using a SQL backend to keep track of visitors and victims it uses regular text files in the same directory.

Requests as seen by the victim:

"index.php" - Serves obfuscated Javascript with random functions and variables.
"breach.php?smc=" - if ms06-014 was exploited
"breach.php?cro=" - if one of the various COM objects were exploited via same method as ms06-014
"breach.php?mdac=" - if ms06-014 was exploited

The following text files are used for statistics tracking instead of a SQL database:

"brow.txt" - count of type of browsers ($ie|$other; eg. 10|0)
"ip_ban.txt" - if IP banning is configured then track here
"block.txt" - list of countries to ignore based on $HTTP_ACCEPT_LANGUAGE
"os.txt" - count of Operating Systems ($w95,$wme,$w98,$w2k,$wxp,$w23,$wvs)
"ref.txt" - more detailed statistics including referer (country code, country name, IP, browser, version, OS, referer, date, time)

The following are specific functions within the obfuscated javascript:

smc() - ms06-014 (BD96C556-65A3-11D0-983A-00C04FC29E36)
downloads EXE via Ajax, upon execution of EXE makes another request to:
breach.php?smc=<###########> - Math.random() number

cro() - looks like it's taken from the Metasploit module "IE COM CreateObject Code Execution"
BD96C556-65A3-11D0-983A-00C04FC29E30 - RDS.DataControl (ms06-014; cve-2006-0003)
BD96C556-65A3-11D0-983A-00C04FC29E36 - RDS.DataSpace (ms06-014; cve-2006-0003)
AB9BCEDD-EC7E-47E1-9322-D4A210617116 - Business.Object.Factory
0006F033-0000-0000-C000-000000000046 - Outlook.Data.Object
0006F03A-0000-0000-C000-000000000046 - Outlook.Application
6e32070a-766d-4ee6-879c-dc1fa91d2fc3 - SoftwareDistribution.MicrosoftUpdateWebControl.1
6414512B-B978-451D-A0D8-FCFDF33E833C - SoftwareDistribution.WebControl.1
7F5B7F63-F06F-4331-8A26-339E03C0AE3D - WMIScriptUtils.WMIObjectBroker2.1 (ms06-073; cve-2006-4704)
06723E09-F4C2-43c8-8358-09FCD1DB0766 - VsmIDE.DTE
639F725F-1B2D-4831-A9FD-874847682010 - DExplore.AppObj.8.0
BA018599-1DB3-44f9-83B4-461454C84BF8 - VisualStudio.DTE.8.0
D0C07D56-7C69-43F1-B4A0-25F5A11FAB19 - Microsoft.DbgClr.DTE.8.0
E8CCCDDF-CA28-496b-B050-6C07C962476B - VsaIDE.DTE

breach.php?cro=<#########> - Math.random() number

mdac() - uses Vbscript; ms06-014; BD96C556-65A3-11D0-983A-00C04FC29E36
"breach.php?mdac=<########>" - round(rnd*99999)

vml() - ms06-055; cve-2006-4868; 10072CEC-8CC1-11D1-986E-00A0C955B42E

Detecting Malicious Javascript

Majority of malicious websites which attempt to exploit browser based vulnerabilities to install spyware/malware utilize various obfuscation methods to hide their code.

A typical "Drive-by" download consists of a victim visiting, or being redirected to, an attacker's webpage which serves obfuscated/encrypted code for the browser to execute.

Following is a Snort IDS signature which attempts to detect this obfuscated code:

alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"LOCAL Malicious script"; flow:established,from_server; content:"("; pcre:"/(\x27|\x22)[\w/@=+%!\\-]{500}/iR"; sid:1000;)

This signature has been successfully tested against the following exploit toolkits:

- Icepack
- Mpack (all variations: regular, obfuscated, and XOR encrypted)
- Firepack 0.18
- Neosploit (various builds of version 1 and 2)

Comments, suggestions, criticism, and optimizations regarding the signature are welcomed.

Antivirus against old threats

In light of the fact that many Information Security companies post their end of year reports as well as predictions for the new year we thought it would be interesting to perform another AV statistics study. Many researchers and professionals are begining to accept the long overdue fact that Antivirus products are losing the battle against modern malware. We decided to test samples of old malware which was collected between 04/2001 and 11/2006. Altogether, there were 86 unique samples. These samples were submitted to Virustotal in 01/2008 and here are the results:

% Found  Total   Missed          AV
------------------------------------------------------
59.00    86      36              VirusBuster
64.00    86      31              eTrust-Vet
64.00    86      31              FileAdvisor
66.00    86      30              ClamAV
66.00    86      30              TheHacker
69.00    86      27              CAT-QuickHeal
69.00    86      27              Prevx1
75.00    86      22              AhnLab-V3
80.00    86      18              eSafe
87.00    86      12              Sophos
87.00    86      12              Sunbelt
89.00    86      10              DrWeb
90.00    86      9               Rising
92.00    86      7               Authentium
94.00    86      6               Ewido
95.00    86      5               Panda
97.00    86      3               AVG
97.00    86      3               Microsoft
97.00    86      3               NOD32v2
97.00    86      3               Norman
97.00    86      3               VBA32
98.00    86      2               Avast
99.00    86      1               Fortinet
99.00    86      1               Ikarus
99.00    86      1               McAfee
100.00   81      0               Symantec
100.00   86      0               AntiVir
100.00   86      0               BitDefender
100.00   86      0               F-Prot
100.00   86      0               F-Secure
100.00   86      0               Kaspersky
100.00   86      0               Webwasher-Gateway

Neosploit server side execution

Toolkit is written in C and runs as a CGI program in the web server. Here are some details about its execution. Data obtained from analysis of version 1.0 of the toolkit. Current versions seen in the wild are 1.5 and 2.0, which may change or add some of the URL schemes.

Exploit URL sequence as seen by the victim:

"?p=user1" - serves the obfuscated Javascript code
"?u2_1_600_2_0_870665223_2792316769_2354152789" - gets the first stage loader (values are not static)
"?l=user" - second stage loader, first stage will contact this URL

*** Populate internal structures ***

Load environment structure obtained from web server's environment variables:
HTTP_USER_AGENT, QUERY_STRING, HTTP_HOST, REQUEST_URI, REMOTE_ADDR, HTTP_COOKIE, SCRIPT_NAME, HTTP_REFERER

Load the form structure obtained from values either in POST or GET request.

Populate statistics structure: Operating System (via UAS), Browser (via UAS), generate hash of referer, userid (toolkit is a multiuser system, this isn't the userid of the victim), Some additional data ("?a=").

Loads the structure with necessary filenames used for statistics and config (starts w/ name of script: "in.cgi")
"in.hits" = Traffic file
"in.loads" = Loads file
"in.loads2" = Loads 2 file
"in.key" = License file
"in.passwd" = Password file (username, passwd, user's configs)
"in.refs" = Referers

*** Generate exploit code and URLs ***

Check if REMOTE_ADDR is in traffic file (.hits). If IP is visiting again within the block time (default 60m) then abort, otherwise serve exploit.

Check if query contains a referenced user ("?p=user") then use his config otherwise default.

Exploit is served based on browser (exploits reside in seperate header files).

Exploitation of Firefox, Netscape, and Opera is configured during toolkit's build time. Internet Explorer is always enabled.

Build a URL to download the loader in format of "%s?u%hu_%hu_%u_%hu_%lu_%lu_%lu_%s": Script name, OS, Browser, Browser Version, Exploit used, additional (??), Hash of REMOTE_ADDR, Hash of HTTP_REFERER, Exploit user.

Shellcode and Loader's URL are inserted into the dynamically generated Javascript code with random variables names and sent to browser.

*** Response to shellcode's request ***

Populate log structure with data taken from GET URL ("?u1_1_10_...")

To get the loader the following conditions must be true: Browser is one of: IE, Firefox, Netscape, Opera; OS is one of: 95, 98, NT, XP, ME, 2k, 2k3 (? Vista); Browser version is set; REMOTE_ADDR is in statistics file ("in.loads") within the block time (IP isn't compared if current time is passed the block time); and the IP's hash in the request URL has to match hash of REMOTE_ADDR.

If unable to open malicious EXE file to send to victim then responds with message: "can't open (pipe stream|file) ${EXE_path}".

Log visitor's IP and time into loader's log ("in.loads").

*** Second stage loader ***

Initial loader may be part of multi-stage loading sequence. If configured as such then first stage loader will callback for the second stage EXE w/ request URL in form: "?l=user".

Check if REMOTE_ADDR is in statistics file ("in.loads") and is within the block time (IP isn't compared if current time is passed the block time). Record IP and time into "in.loads2" file.

If second stage loader exists then serve it.

MPack Analysis

Has the ability to serve exploits to a defined set of countries. If it is configured to block duplicate visitors, which is done by checking the MD5 hash of REMOTE_ADDRESS and User Agent String, then changing anything within UAS will serve the exploit again.

If a database is not utilized to track statistics then everything is kept in text files ("ip_${stat}.txt"): 0day, all, expl, firefox, jar, opera7, file, qtlexp, ani2 (e.g. "ip_all.txt").

"users.txt"
used to track visitors to "index.php" if DB isn't used, contains MD5 hash of IP and UAS.

"maketable.php"
creates the necessary DB tables for tracking statistics.

"settings.php"
configuration such as use DB, credentials, exploit only once.

"admin.php"
displays statistics for exploits and loads (requires DB login, via POST).

"stats.php"
displays statistics, requires only the password via GET "?pass=mpack" (seperate from DB credentials).

"flush.php"
deletes all statistics, requires a password via GET "?pass=mpack" (not DB credentials).

"index.php"
serves the obfuscated javascript code, increments total traffic count. Accepts an optional parameter "?id=168" for different loader which will be passed to "file.php". Calculates MD5 hash of IP + UAS, if identical entry is found it will not serve the exploit, returns:
";[" - if DB isn't used, or
":[" - if DB is used.

"file.php"
serves an executable (1st stage), increments exploited counter. Accepts an optional variable via GET "?id=trojan" which is stored on the filesystems as "loader_trojan.exe".

"fout.php"
serves the 2nd stage (last) executable, increments "loads count". Basically, this is the sure way to tell if the 1st stage loader made the callback home.

Neosploit exploit toolkit

The Neosploit toolkit is an advanced exploit framework to compromise web site visitors. It was written by "grabarz". It is unknown if this is a group or an individual. There's some information which suggests it is an individual.

It's not as popular as the Mpack toolkit but is gaining popularity steadily. It was written in the C language and is used as a CGI script. It can support multiple users from the same script. The exploit code will be the same from all users but the delivered executables can be different.

Similar to other toolkits this one provide various statistics too. Instead of using a database as the means to store them Neosploit uses several files with specific internal structures. The following information about the visitor is logged: Operating System, Web browser and its version, IP address, and the Referer.

Delivered exploit code is obfuscated using custom Javascript decoding function. The function name and all local variables are random in order to avoid detection by Network IDS. Often, several layers of obfuscation with anti-decoding tricks are used to deter the faint-hearted.

Toolkit's URL scheme is designed in such a way which will prohibit thecurious of obtaining the executables even if the same one is used from previous exploits.

Perhaps the reason for its slow adoption is its high price. It ranges, depending on version, from $1500 to $3000. Common version seen today in the wild is 1.5.x, with 2.0.x in beta mode. First detected version was 1.0.x early this year.

More in-depth analysis will follow.

How effective is AV?

To see how effective AV engines are at detecting threats some malware samples were sent to Virustotal for analysis.

Samples used were binaries which would end up on victim's computer by exploiting vulnerabilities in web browsers or addons/controls associated with browsers.

Upto %65 of the submitted executables were obtained from fall of last year to spring of this year and checked by AV this month. Others are mainly from this summer.

%Found   #Total  #Missed         AV
------------------------------------------------------
29.00    369     264             FileAdvisor
33.00    369     249             eTrust-Vet
45.00    369     203             ClamAV
45.00    369     204             TheHacker
45.00    369     206             AhnLab-V3
46.00    369     201             Ewido
46.00    369     202             VirusBuster
48.00    369     195             Norman
49.00    369     190             McAfee
51.00    369     182             Authentium
58.00    348     147             Prevx1
58.00    369     156             Sunbelt
60.00    350     141             Rising
60.00    369     148             F-Prot
61.00    369     146             Microsoft
62.00    364     139             Symantec
62.00    369     143             Fortinet
67.00    368     124             Avast
68.00    369     119             eSafe
68.00    369     120             VBA32
69.00    369     115             Panda
69.00    369     117             Sophos
70.00    369     112             Kaspersky
71.00    361     107             DrWeb
71.00    364     107             F-Secure
71.00    368     107             NOD32v2
72.00    369     105             AVG
72.00    369     107             CAT-QuickHeal
74.00    369     96              Ikarus
74.00    369     99              BitDefender
79.00    378     81              AntiVir
84.00    354     59              Webwasher-Gateway