In 2008 I took part in the Malwarechallenge 2008.
The goal was to analyze a presumably malicious binary and learn as much as possible about it´s functionality.
My original submission is available as PDF at mwc2008-emre-bastuz.pdf.
Have fun reading!
Malware Challenge 2008 Behavioral analysis of a malicious Windows executable with an md5 hash of 59a95f668e1bd00f30fe8c99af675691, embedded in a ZIP archive with an md5 hash of 31d2ec3b312d0fd27940aae5c89e3787 Emre Bastuz
25. Oct. 2008 V 1.0
Description of the lab
VMWare Workstation 6.5 was used to create an isolated testing environment for the described procedures.
Two guest systems were created within VMWare one acting as a safegate and one acting as the victim.
Further more two virtual networks were configured. The first network was facing the internet. The second network was created as a so called host only network and was used to isolate the victim from the internet.
The safegate virtual system was equipped with virtual network interfaces in both, the internet and the isolation, networks.
The victim system was configured with a virtual network interface within the isolation network.
Logical network diagram:
Linux guest as safegate
For the safegate Debian GNU Linux (Etch) was used as operating system.
Iptables was used to ensure, that only specific network traffic was allowed from the victim virtual PC. The DNS configuration made it possible, to divert the traffic in order to log and also manipulate the requests from the victim.
On this machine several software components were installed to make manipulation of the malware communication possible:
- Bind9 was installed as a nameserver and configured to listen for requests on the victim-facing network. The ip adress of the safegate on this network was put into the Windows network configuration of the victim PC
- Squid was installed as an HTTP proxy to catch all software that might be loaded from the internet after the infection process on the victim PC
- As an IRC server ircd-ircu, the Undernet Internet Relay Chat Daemon was used.
The configuration of these services is described below in more detail.
The relevant configuration of iptables was as follows:
The rules for accepting DNS and C&C traffic are rather self explanatory, however the redirection for HTTP requires some explanation: when the victim does a DNS request to the safegate BIND server, it will always receive an IP address pointing again to the safegate (the nameserver is configured as a catch-all nameserver).
HTTP traffic is then received by the proxy which in turn will do required DNS requests to an unmanipulated nameserver and thus retrieve the requested binary and forward it to the victim.
- All HTTP traffic passes through the proxy
- All downloaded files are being saved on the safegate .
- No proxy configuration is required on the victim - HTTP is diverted transparently
As briefly mentioned, the Squid proxy is used to retrieve and log all binaries that might be requested from the victim system.
The service is configured to act as a transparent proxy:
If the binary were to use SSL encrypted traffic to further load software from some external source, the Squid proxy could also be configured to act as a man-in-the-middle and log the communication between the victim and another server in clear text.
Luckily, encrypted traffic was not an issue with the analyzed malware.
Bind was configured with just a single zone that was setup as a catch-all zone, i.e. all name-to-ip requests coming from the victim were answered with the IP address of the safegate machine.
Please see below for the main configuration (named.conf):
The zone file itself looked like this (db.catchall):
The IRC server ircd-ircu required almost no special configuration. To prevent DNS lookups and enable a fast login to the IRC server, this parameter was added:
Some tools were used on the safegate machine to take a look at the binary. The usage and the results are described below.
Upx is a command line tool to pack binaries. It can further check if a binary has been packed in a known format and eventually unpack it.
The result from running a first check on the binary was as follows:
Obviously the binary is packed but can not be unpacked with the tool Upx.
A second quick look was taken at the binary by extracting the ASCII characters with the command line tool 'strings'.
Only a few lines were kind of human readable:
From the point of view of a person knowing assembler, C or C++, the extracted information might be relevant.
Windows guest as victim
The operating system 'Windows XP Service Pack 2' was used for the victim PC.
To avoid network noise all unnecessary services were deactivated on the victim system using the DOS script svc2kxp.cmd. The 'harden system' option was used to achieve a maximum of service-deactivation.
The script svc2kxp.cmd is available at http://www.ntsvcfg.de/.
GMER (http://www.gmer.net/) is a tool primarily used for rootkit detection. It has also several features that make it possible to trace and block activity related to
- filesystem changes
- registry changes
- network activity.
Unfortunately neither GMER version 1.0.13 nor 1.0.14 worked reliably on the victim system.
GMER was not used in the analysis process.
PE Explorer (http://www.heaventools.com/) is a commercial product for inspecting Windows executable files. The demo version of the software was able to unpack the binary and made further analysis possible.
InstallRite is a tool that can be obtained from http://www.epsilonsquared.com/installrite.htm and used to create a database of a Windows installation.
In the initial stage, i.e. before execution of a file, the software reads the following information of the system and records it:
- Registry keys and values
- Filesystem information including the file's checksum and version
After running a software the mentioned information can be re-checked and the two states can be compared.
This tool will was used to detect what modifications had been done by the malicious software on the victim system.
Passive information gathering
First look at the binary
Unpacking the binary was simply done by loading the binary with PE Explorer and saving it again:
The unpacked binary had an md5 hash of 7a65b61fc8ce2156454944effc3a9702.
Further testing of the unpacked binary with "strings"
Taking a look at the ASCII characters in the now unpacked binary revealed a lot if information and made some assumptions on the functions of the software possible.
Assumptions so far
The extracted ASCII strings and the assumption derived from the text are listed below (offset and string).
Software identifier is 'Crxbot Alias REalmbot by Lindem'
IRC based software with C&C at testirc1.sh1xy2bg.NET
The hostname found in the text and several IRC related commands suggest an IRC server as command and control structure.
IRC Channel used is #chalenge
Passwords used are 'happy12' and 'gemp123'
Host auth pattern is '*@legalize.it'
Assumed functions of the software
The strings in the binary suggest what functions the software might have. Some of these functions will later on be validated.
An uncomplete list of the assumed functions is as follows.
SQL / ODBC based functions
Update site for software at http://www.Nivdav.net/Winsec32.exe
Capturing of login infos on pattern match
Password list for bruteforce attacks
Username list for bruteforce attacks
Remote shell capabilities
DNS & ARP related functions
FTP server capabilities
IRC related functions
Two keylogging mechanisms seem to exist in the software: one probably for catching almost all activity on the victim machine, the other one called Pay sites Keylogger probably can monitor user input and start logging keystrokes if a match occurrs with a predefined set of strings (see "Capturing of login infos on pattern match").
Pay site keylogging
Two strings suggest some VNC related functionality. The first line at offset 109208 is a parametrized command for the software. The other line at offset 157868 is some string that occurrs in web based vnc access (according to findings from looking for the string with a search engine).
How the VNC related function works is unclear.
DOS / DDOS features
Proxy / redirect capabilities
HTTP Server capabilities
Active information gathering
Record victim state with InstallRite
Prior to running the malware, InstallRite 2.5 was used to record the victim machines state. The settings were made to observe all registry keys and all filesystem changes (CRC and file version).
Running the packed binary
To verify the made assumptions the binary had to be run.
Taking a snapshot of overall system
After running the executable, a snapshot of the system was taken with VMWare. A quick peek at the saved virtual memory with 'strings' showed the strings that had previously been found by looking at the unpacked binary.
Gathering information from the save-state of a virtual machine would have been an alternative to the usage of the commercial tool PE Explorer.
Record victim state with InstallRite again
The status of the victim machine was recorded for a second time after the binary had been run.
No anti-vm techniques used
It was possible to start the software in VMWare. Obviously no anti-vmware techniques had been used with the executable.
Registry changes according to InstallRite
The assumed registry changes according to an anaylsis were confirmed by InstallRite (note the references to "Winsec32.exe"):
Filesystem changes according to InstallRite
The file installs itself on the system in the folder %Systemroot% as Winsec32.exe, which was also confirmed by InstallRite:
According to the nameserver query log, the victim machine queried the hostname testirc21.sh1xy2bg.NET:
According to a packet dump on the safegate machine, interface eth1, a connection was being made to port 6667, TCP:
Description of the C&C center
An IRC server was setup to listen on port 6667 on the safegate machine. After accessing the server the presumed C&C channel was entered.
To verify the assumed channel, #chalenge was entered. Another client (the malware) joined the channel shortly after the malware had been run on the victim system:
During the first analysis two strings that looked like passwords had been observed: happy12 and gemp123. To find out the channel password both were tried by setting the pw and kicking the software client off the channel.
The password happy12 turned out to be the channel password as the client was able to re-enter the protected channel.
Gaining admin access to the bot
As one of the passwordesque strings was identified as the channel password, the other one was tried as the administrative password for the software (gemp123).
IRC based malware often does not rely on a password authentication but is usually configured to match for a hostname identifier of another client that tries to obtain control.
A string *@legalize.it that looked like such a host identifier was found in the unpacked binary. For another client to fake this hostname part two ways exist.
Adjusting DNS configuration
The host identifier in IRC networks depends of the forward and reverse DNS lookup of hostname and ip address.
While it would technically have been possible to create a DNS configuration on the safegate to fake a host identifier of *@legalize.it, it would have made things a little bit more complicated.
The method of modifying the malware binary was chosen over a DNS configuration.
Modifying and running the binary
The host auth part of the binary was modified so that the string @legalize.it was replaced by *@ and padded with zeros to match the length of the original string.
This modification was supposed to make the IRC client accept any host during authentication stage.
Authentication was achieved by sending a .login command to the software with the password gemp123 as a parameter:
There we go!
Verification of features
Requesting update of the binary
Starting and accessing HTTP server
Starting and accessing FTP server
Starting the FTP server was not possible. According to the output, the software tries to start an ftp server on port 0. This is either a bug in the implementation or some unknown parameter that is required for starting the daemon.
Starting a normal keylogging session
First the keylogging is started:
Some text is typed in the victim system:
The text is being logged to the IRC channel:
Starting a remote Shell
Default behaviour when entering IRC channel
The malware will try to execute the topic of the irc channel as a command upon entering.
Further more it will try to change the channel topic to .asc vnc 100 0 0 -r -b as soon as it enters the channel.
Accessed URLs and Domains
One hostname and one URL was found in the strings of the binary:
As described before, testirc1.sh1xy2bg.NET is the name of the C&C.
The URL seems to be an update site for the software. However this assumption could not be verified as it was not possible to initiate an update from the URL by means of triggering some default behaviour.
Classification of the binary
The binary has functions that definitly classify it as malicious:
- remote control.
However, there was not much of an effort put into hiding the binary from the operating system or from analysis:
- no anti-vmware techniques
- no changing filename (always installed as Winsec32.exe)
- unpackable by off-the-shelf software
In detail I would classify this software simply as a (not-so-resilient-but-nevertheless-malicious-) irc bot.
Purpose of the binary
The purpose of the binary is to give another party control over an infected system without the system-owner knowing it.
Once infected, keystrokes, files and other information can be retrieved from the infected system.
It can further be used to act as a proxy to disguise the attackers identity or to launch attacks against third parties.
Obtaining the source code
Several strings within the binary were used in different combinations with a search engine to acquire the bot source code.
Finally it was found on a popular, web accessible, filesharing plattform.
The found collection of bot code contained the source for Crx-realmbot.VNC+RFI which is either the code for the analyzed malware or some variation of it.
Creation of a detection and removal tool
The malware makes changes to an infected system, the relevant ones being:
- Copy itself as Winsec32.exe to %Systemroot% with flags hidden and write protected
- Modify registry key Software\Microsoft\Windows\CurrentVersion\Run to contain Winsec32.exe
- Modify registry key Software\Microsoft\Windows\CurrentVersion\RunServices to contain Winsec32.exe
- Modify registry key Software\Microsoft\OLE to contain Winsec32.exe
To create a tool that checks for these changes and removes them, Perl and Perl2Exe were used.
This script has been converted to a Windows executable file with a trial version of Perl2Exe (details see http://www.indigostar.com/perl2exe.htm). The executable has been added to the submission to the Malware Challenge 2008.
The script works as follows:
- if no parameter is given, the usage will be printed
- a parameter of --test will simply check for the existence of the relevant registry keys
- a parameter of --remove will kill a running Winsec32.exe process, remove the three relevant registry keys and remove the file Winsec32.exe from the folder %Systemroot%
To run the script the following Perl components Win32::Process::Info and Win32::TieRegistry are required.
For running and compiling the script, Perl 5.8 has been used.
Screenshots are provided below.
Running the tool with no parameters
Running the tool on an uninfected system
Running the tool on an infected system in test mode
Running the tool on an infected system in remove mode