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.