blog.sat0ri.com

Originally posted on opensc.ws the 2nd of January 2010, the Spy Eye information theif appears to be a very promising info-stealer with much functionality, similar to that of the notourius ZBot. Spy Eye, which could originally be purchased for 500 USD, currently costs 1000 USD and contains much functionality including the following:

• Form-grabbing
• Password stealing
• API-hooking
• PHP/MySQL cpmtrol panel
• Daily back-ups sent via e-mail
• Multiple protocol grabbing
• Hides it in other processes
• Creates invisible files/autorun keys
• Operates in ring 3
• Works on Windows 2000 -> 2007

What do you get for your money? You get a promising way to help earn you a quick buck. And with the proper choice of pay-per-install in place, your chances go up even more. Spy Eye is comprised of two main components; the builder, which builds the individual Spy Eye servers, and the drop-site/command and the control server, which is the PHP/MySQL web-application where harvested information is posted/bots are controlled.

The builder is a Win32 application, programmed in C++, which can be used to create server components. The builder provides the possibility for the user to specify settings, used by generated servers. Here is a list of the options:

• Path to the main control panel
• Alternative path to the main control panel
• Path to the formgrabber control panel
• Encryption key
• Connector interval (in seconds)
• UPX compression option
• Kill Zeus option

The Spy Eye server, when executed on a system, injects itself into explorer.exe and creates a new section within the process with read, write, and execute permissions. Spy Eye then calls a LPTHREAD_START_ROUTINE routine, which resides within the injected section located in explorer.exe’s memory space. This is done using the CreateRemoteThread() API. Shortly after, the Spy Eye server termimates execution by calling ExitProcess(). Spy Eye, from within explorer.exe, then begins writing files to disk including the following:

1. C:\cleansweep.exe\
2. C:\cleansweep.exe\cleansweep.exe
3. C:\cleansweep.exe\cleansweepupd.exe
4. C:\cleansweep.exe\config.bin

The Spy Eye payload is executed every time the system boots by adding the path to the payload (2) to the Run Registry Key. Configuration data is stored in encrypted form within the Spy Eye binary and is read using the LoadResource(). This configuration data includes the information defined in the builder as previously mentioned.

While Spy Eye boasts of being able to kill Zeus, the current implementation of this functionality is limited to Zbot versions 1.4 and prior, as it appears only to monitor two Zbot mutexes, illustrated below:


<snip>

if (strstr((LPSTR)name, "__SYSTEM__") || strstr((LPSTR)name, "_AVIRA_")) {

...

}

</snip>


If you’re interested in viewing the entire source code, search the web for the following: C++ Zeus Killer [SOURCE].

Will this spark the beginning of yet another bot war? Let’s watch and see.

Based on the Insight-article entitled: Technical Analysis of the Spy Eye Trojan (CSIS).

The Win32.Silon information thief  (hereafter referenced as Silon) is a relitively new information stealer, which surfaced early 2009. It has the ability to steal log-in information and commit financial fraud via many popular online banks. Currently it has been seen it the following two versions (dubbed by CSIS):

• Win32/Silon.A (SA)
• Win32/Silon.B (SB)

Due to the fact that the malware doesn’t have its own installation functionality, it relies on installers and other pay-per-install services to set up an infected environment. In order for Silon to properly be able to function, the installer must do the following:

• Create the registry key: HKEY_CLASSES_ROOT\CLSID\{<value calculated based on the vol ID>}\InprocServer32
• Add required values to the above key (presented below)
• Drop the Silon payload to %systemroot%\system32\msjet51.dll (SA) or %systemroot%\system32\msls50.dll (SB)
• Alter the predefined value specified in HKEY_CLASSES_ROOT\CLSID\{50D5107A-D278-4871-8989-F4CEAAF59CFC}\InprocServer32\(Default) so it points to the Silon payload (originally set to C:\WINDOWS\system32\msimtf.dll)

The above information can of course also be used when attempting to identify the presence of Silon. That’s more or less it. When Internet Explorer is run, the Silon module will be executed instead of the previously defined module, and will run within the context of the Internet Explorer process. Upon execution, the Silon module throws more than 28000 exceptions in an attempt to cause analysis confusion via the lock xor eax,eax instruction. The exception handler is responsible for decrementing the counter, initially set to 6E00h/28160d (the number of exceptions) until it is equal to zero.

I have implemented a simplified version of the mentioned exception joy in challenge nine, so if you’re curious about how it works, debug challenge nine (80).

Eventually, RtlAllocateHeap is called to allocate heap space to which the encrypted instructions are written. This encrypted data is then xor’ed with the static dword key DC887163h and then rolled to the right (ror) by the hex value 39h. If you step into and follow this loop for a few interations, you will be able to see the decrypted executable (MZ…) beginning to take form. The code is then copied to the original entry point of the executable. After the copying is done, the module is unprotected.

Silon has some nice functionality including API patching, which enable it to handle calls to wininet.dll specific APIs prior to the actual called API itself. Application data is then at the disposal of the malwware until code execution returns to the called API. Silon patches the following APIs:

• InternetCloseHandle
• HttpQueryInfoA
• InternetReadFile
• InternetQueryDataAvailable
• HttpSendRequestA
• InternetSetStatusCallBackA
• InternetQueryOptionA
• HttpSendRequestW
• InternetReadFileExW
• InternetReadFileExA

Data intercepted via the patched APIs is logged locally prior to being sent to drop-servers in the %systemroot%\Temp directory, the file name equal to the current computers volume id, hyphen not included. All configuration and drop-site information is stored in the registry under the previously mentioned key in encrypted (RC4) form, and is illusrated in the screen-dump below (truncated due to file size):

The following provides an explanation for the above mentioned encrypted data written to the registry by the installer:

• 0: Injected HTML data (e.g. fields and forms)
• 1: Command & Control
• 3: Control data
• 4: Control data

The Silon gang mean business, so we can expect to see some new versions in the future.

FISH version 0.0.3 beta with numerous improvements is now available for download. Expect to see trememdous performance increases in this release as well as many other improvements including the following:

Version 0.0.3 (second public release):

• This version is at least 30 times faster than version 0.0.2
• Implemented a new hash function
• Optimised the iterative function used to iterate files
• Time stamps are now included in database files as well as reports
• It is now possible to limit file selection to a specific size (calculating the digest of a 7GB vm image is a really bad idea)
• Restructured database files
• Restructured report files
• Introduced more logging to ensure that the user knows exactly which files were skipped (if they are too big according to the configuration)

If you find any bugs or have any ideas for improvement, please don’t hesiate to let me know.

FISH can be downloaded here: fish 0.0.3 (98). This is still a beta release so use at your own risk.

The other day I was looking at a friend’s computer. I was browsing his user profile directory in search of something intersting to show him and came across something that I had never seen before; the Default User’s Temporary Internet Files directory was filled with temporary Internet files (hence its name ) as though this user had been using Internet Explorer to browse the Internet, which is not possible when using Windows normally. Furthermore, he mentioned that his anti-virus (Trend Micro Officescan: TM) identified the file “C:\Documents and Settings\Default User\Local Settings\Temporary Internet Files\Content.IE5\SN8PI1DA\raedwev[1].jpg” as WORM_DOWNAD.DAM. According to the file extension it was an image (JPG), but the content of the file appeared to be binary in nature. I uploaded the file to VirusTotal but the results came back blank.

A couple of hours later I came to the conclusion that another computer had probably attempted to infect his computer with the Conficker worm by exploiting the vulnerability described in MS08-067. This assumption was based on the presence of the mentioned file in the default user’s (Default User) Temporary Internet Files directory.
The default user is used as a template for new users and it is not possible to log on as this user. If the temporary Internet files directory does become populated with cache files, it may be because Internet Explorer had, at some point, been executed with SYSTEM user privileges (browse the Internet using Internet Explorer with SYSTEM privileges and you’ll see what I mean, which is a really bad idea). Usually, when a user uses Internet Explorer, it will run with the same privileges as that user. That is, if Internet Explorer is running with SYSTEM rights, it is somewhat unusual and therefore probably malicious.

Assuming that my friend’s computer is vulnerable to the MS08-067 vulnerability (it was), if an attempt to exploit this vulnerability is successful, this could (depending on the exploit payload) result in a new process with SYSTEM privileges. The Conficker worm (WORM_DOWNAD) spreads by exploiting MS08-067, which results in the UrlDownloadToFileA() API in Urlmon.dll being called with SYSTEM privileges in order to download additional files (configurations, payloads, etc.). When this newly created SYSTEM process calls the UrlDownloadToFileA() API in the Urlmon.dll, which can be said to be one of Internet Explorer’s core components, it is as if Internet Explorer itself is being used to retrieve the file. This means that any files downloaded in this way will be written to Internet Explorer’s Temporary Internet Files directory before reaching their final destination (typically the currently logged on user’s desktop).

While the Conficker payload was being downloaded, my friend’s anti-virus was able to identify the malicious payload and thus interrupt the download process prior to its completion, which is what caused TM to issue the initial alert. Additionally, the reason TM identified the file as WORM_DOWNAD.DAM is due to the fact that the payload had not successfully/completely been downloaded and was thus damaged, hence the name issued by TM: WORM_DOWNAD.DAM (DAM for damaged).

If you see temporary internet files in the Default User’s Temporary Internet Files directory, you may want to have a closer look. Hiding malicious payloads in TMP and JPG files (among others) is common play for malware, so keep an eye out for these. Check out NASTI (below), which will help you identify the presence of such files.

I hope you found this interesting.

Special anniversary greets to divine dinne.

Recently whilst analysing the PSP2-BBB banker trojan, I discovered that this particular trojan, as well as many others, downloaded malicious payloads to the currently logged on user’s “Temp” and “Temporary Internet Files” directories, located in the “Local Settings” directory, on a Win32 system, and saved them as temp files with a random four character name plus the .TMP extension (e.g. 23D4.TMP). Knowing this, it would be nice to be able to identify executable files with inconsistent file extensions (e.g. executable files with  .TMP as the file extension), as this would aid in the identification of potentially malicious files and thus speed up the analysis.

For the sake of illustration, if we look at one of the examined TMP files in a hex editor (presented in the following screen dump), we can clearly see that it is a valid Portable Executable (PE) file:

NASTI’s configuration enables the user to specify signatures for known file types and associate file extensions to this signature. When NASTI runs, it compares the current file’s extension with those supplied in the configuration file. If they do not match, then the signature should not be present in the file. If it is, the file is flagged.

Here is a screen dump of NASTI in the middle of a scan:

NASTI can be downloaded here: nasti (50). This is a beta release so use at your own risk.

FISH is a free file integrity tool that creates a file signature database (default db.xml) for the file types (ie. exe, dll, sys) specified in the configuration file (config.xml). This signature database is then fed to the FISH (sigdb in the config) at a later date to check for the presence of new, deleted and altered files. A brief summary is written to the console and a report (default report.xml) is created, highlighting changes.

I use FISH on numerous servers to perform nightly file integrity checks. The results are written to the report which I have placed on the desktop. The path for the report can be specified in the configuration file (1).

FISH can be downloaded here: fish 0.0.2 (33). This is a beta release so use at your own risk.

1: If the path use specify in the configuration file contains reserved characters, remember to place the path in a CDATA section in the configuration file: <![CDATA[C:/Reports & Logs/FISH/report]]>