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.