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.

Apples for the Army

Forbes Article

In an effort to reduce vulnerability exposure the US Army is adding Mac OS X into the mix of possible targets.  There's nothing wrong with this approach.  These days different organizations apply various methods to reduce the risk of incidents.

In my younger and innocent days I was under the impression that the government utilized custom applications running on custom operating systems designed by them for them.  I guess the government doesn't have enough budget and resources to maintain teams of engineers and support staff to design and implement custom information technology infrastructure.

Most think and will say that this is a complicated issue with many pros and cons.  However, if one really thinks about it then it's not that complicated.  Investment into custom code will outweigh all the cons in the long term.  Look at all the recent reports about cyber warfare attacks and their success.  It was largely due to known vulnerabilities in the common software products.

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

IcePack Platinum Edition 2007

This exploit framework is nicely designed and has a somwhat object oriented approach.

Browser based exploit code is broken down into seperate modules. Its statistics engine logs several important user variables such as IP, Browser and OS version. By default, it performs a check of the visiting IP to determine if it's already been seen and if so then avoids further interaction with that session.

Another interesting aspect is that it uses output stream buffering with a callback function which will obfuscate all data to avoid detection and readability. Specifically, it uses a random ASCII based substitution table to create a Javascript function which will decode the payload and run it.

The people who wrote this framework (IDT Group), or at least that's their header on top of every source file, know what they're doing. Their code layout and some documentation is displayed in a manner often seen in professional programming projects.

Interesting "Downloader"

Get it offensivecomputing: "f5c3bf7be349b36983d2a07b917f4bb7"

It uses a rather simple walking XOR decryption with a single byte that decrements at each iteration. This is used to decrypt code and data.

Next, it will setup a Vectored Exception Handler and execute INT 3. So, if you're debugging and don't pass this to the code then nothing happens.

Another interesting aspect is that for every API name which it calls, obtained through PEB structures, is hashed. Thus, to call an API it calls an internal function with a predetermined hash of the API, this function traverses all current exports and hashes each one to compare. Once found, the API's address is returned in EAX, which is followed by "call eax".

Moreover, all data blocks are XORed with a different key and the moment this data is used the decrypted memory is cleared.