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

Detecting packed/crypted executables with Snort

As a result of some research into various trojans it was identified that majority of them rely on packers, crypters, and anti debugging tricks. Nothing new here. However, what was interesting is that some of them were completely missed by Snort. Rulebase included default signatures that come with base installation, community rules, and Emerging Threats (ET).

It turns out that analyzed trojans modified the executable's header which did not fall within signature's patterns. This can be partly fixed by creating a signature to detect the PE header's magic value within a certain distance from the start of the DOS header. However, the trick here is to pick a distance which will not produce false negatives. If it's too short then it's doomed to miss lots of stuff. Higher values may produce false positives, more research into this is needed.

It's best to detect executables by reading their structure. PE/COFF format states that the offset to start of PE header is found 0x3C bytes from start of DOS header. I was not able to achieve desired results using the regular Snort rule syntax but using the dynamic rules feature worked perfectly. It's written C and must be compiled. Download it here.

Importance of verifying vendor's protection claims

One of my favorite fundamental security principles is perfectly summarized by this blog post: "Are you Secure? Prove it.

This is true for any situation more so for high severity issues like the MS08-067 vulnerability. So, one of the big names in enterprise security products came out with couple of signatures in their end user protection product. I won't name which one since it doesn't really matter in this context.

Taking into account that not all organizations can patch immediately, in large enterprises there are many factors which can contribute to the delay, the last resort to protect users is to rely on security software on their workstations. Antivirus can only go so far and it's largely useless these days. However, some HIPS signatures can limit the exposure.

So, this HIPS product rolled out signatures to supposedly detect and prevent the attack. After testing their claims it turned out that it only blocks exploit attempts from the workstation which has this HIPS installed. Any attacks against this workstation will be successful. It is beyond me why this decision was made. It'll stop the worm from spreding but it won't protect the client from being infected by the trojan which can easily be downloaded by the shellcode.

Interestingly, the response from the vendor was that they created detection for the most common exploit vector. I understand that it's not always possible to create signatures for the vulnerability, product has its limitations, thus only specific exploit vectors are detected.

But in this case it wasn't event the most common vector. My tests used the code which was published on milw0rm by stephenl and at that time had just over 10,000 views, currently at over 16,000. I would think that the vector used in that PoC would be the most common since it's quickly copied by many other hacking sites.

Thus, if organizations rely on their security vendor's claims and don't have in-house expertise to verify those claims then they're at a high risk of having a false sense of security. Considering that this product is from a rather large security vendor then the list of those organizations is rather large.

On the upside, vendor was notified and is currently working on updating their detection.