Malware Challenge 2008

A walkthrough for the behavioral analysis of a malicious Windows binary

Posted by Emre Bastuz on October 28, 2008

Intro

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!

Title

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

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:

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.

Services

iptables

The relevant configuration of iptables was as follows:

# Flush the 'NAT' table
iptables -F -t nat
 
# Flush the 'mangle' table
iptables -F -t mangle
 
# Set a default of accept" for 'NAT' and 'mangle' tables
iptables -t mangle -P PREROUTING ACCEPT
iptables -t mangle -P OUTPUT ACCEPT
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT
 
# Accept traffic to and from the Internet
iptables -t mangle -A PREROUTING  -i eth0 -j ACCEPT
 
# Accept UDP traffic to port 53 to make DNS queries for the victim possible
iptables -t mangle -A PREROUTING  -p udp -i eth1 t -d 10.0.0.1 --dport 53   -j ACCEPT
 
# Accept TCP traffic to port 80 to make HTTP requests for the victim possible
iptables -t mangle -A PREROUTING  -p tcp -i eth1 --dport 80   -j ACCEPT
 
# Accept TCP traffic to ports 6000-7000 to make C&C traffic possible
iptables -t mangle -A PREROUTING  -p tcp -i eth1 -d 10.0.0.1 --dport 6000:7000 -j ACCEPT
 
# Drop and log the rest of the traffic coming from the victim (eth1)
iptables -t mangle -A PREROUTING -i eth1 -j ULOG
iptables -t mangle -A PREROUTING -i eth1 -j DROP

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.

This way

  • 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

Squid

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:

log_mime_hdrs on
 
logformat common %>a %ui %un [%tl] "%rm %ru HTTP/%rv" %Hs %<st %Ss:%Sh
 
access_log /var/log/squid/access.log squid
cache_log /var/log/squid/cache.log
cache_store_log /var/log/squid/store.log
cache_dir ufs /var/spool/squid 100 16 256
pid_filename /var/run/squid.pid
 
visible_hostname somehost.com
 
wccp_address 127.0.0.1
wccp2_address 127.0.0.1
 
http_port 10.0.0.1:80 transparent
 
acl all src 0.0.0.0/0.0.0.0
 
http_access allow all
http_reply_access allow all
 
logfile_rotate 30
 
forwarded_for off

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

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):

zone "." {
        type master;
        file "/etc/bind/db.catchall";
};

The zone file itself looked like this (db.catchall):

$TTL    604800
 @       IN      SOA     localhost. root.localhost. (
                               1; Serial
                          604800; Refresh
                           86400; Retry
                         2419200; Expire
                          604800 ); Negative Cache TTL
 
 @       IN      NS      10.0.0.1
 
*        IN      A       10.0.0.1

IRCD

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:

F:NODNS:TRUE

Tools

Some tools were used on the safegate machine to take a look at the binary. The usage and the results are described below.

Upx

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:

safegate:# upx -t malware.exe
 
                       Ultimate Packer for eXecutables
    Copyright (C) 1996,1997,1998,1999,2000,2001,2002,2003,2004,2005,2006
 
UPX 1.95 beta   Markus Oberhumer, Laszlo Molnar & John Reiser   Mar 18th 2006
 
upx: malware.exe: CantUnpackException: file is modified/hacked/protected; take care!!!

Obviously the binary is packed but can not be unpacked with the tool Upx.

Strings

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:

safegate:# strings malware.exe
[...]
XPTPSW
KERNEL32.DLL
WS2_32.dll
LoadLibraryA
GetProcAddress
VirtualProtect
VirtualAlloc
VirtualFree
ExitProcess

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.

Tools

svc2kxp.cmd

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

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

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

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

Unpacking the binary was simply done by loading the binary with PE Explorer and saving it again:

Screenshot PE-Explorer

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'

109012 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.

109056 testirc1.sh1xy2bg.NET
136856 NICK %s
136865 USER %s 0 0 :%s
136884 PASS %s
136896 MODE %s %s

IRC Channel used is #chalenge

109196 #chalenge

Passwords used are 'happy12' and 'gemp123'

109048 gemp123
109092 happy12

Host auth pattern is '*@legalize.it'

136728 *@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

106048 SQLDisconnect
106064 SQLFreeHandle
106080 SQLAllocHandle
106096 SQLExecDirect
106112 SQLSetEnvAttr
106128 SQLDriverConnect
106148 odbc32.dll

Registry modifications

109284 Software\Microsoft\Windows\CurrentVersion\Run
109332 Software\Microsoft\Windows\CurrentVersion\RunServices
109388 Software\Microsoft\OLE
109412 SYSTEM\CurrentControlSet\Control\Lsa

Update site for software at http://www.Nivdav.net/Winsec32.exe

109452 http://www.Nivdav.net/Winsec32.exe

Capturing of login infos on pattern match

116872 e-gold
117000 PayPal
117128 StormPay
117256 WorldPay
117384 Fotolog.net
117512 Terra - Fotolog
117640 Yahoo!
117768 Domain Search
117896 Bienvenido a Gmail
118024 Welcome to Gmail
118152 Domain Name Registration
118280 Domain Name
118408 My Account Login
118536 MercadoLivre Brasil
118664 Iniciar sesi

Password list for bruteforce attacks

120988 zimmerman
121004 yellowstone
121020 wisconsin
121032 williamsburg
121048 wholesale
121064 topography
121076 temptation
121088 telephone
121100 tangerine
121116 supported
121128 superuser
121140 superstage
121156 stuttgart
121168 stratford
[...]

Username list for bruteforce attacks

136476 ADMIN
136484 ROOT
136492 GUEST
136504 fubar
136512 ADMINISTRATOR
136532 oracle
136544 database
136556 default
136564 guest
136572 wwwadmin
136584 teacher
136592 student
[...]

Uptime

145296 uptime

Driveinfo

 145276 driveinfo 

Threadlist

108900 -[Thread List]-
108916 %s: No %s thread found.
108940 %s: %s stopped. (%d thread(s) stopped.)
145552 threads.l

Network info

 

138336 RealmBoT (irc.p.l.g) .
138360 .  Network Info.

Service list

 

138544 RealmBoT (processes.p.l.g) .
138574 .  Proccess list.

Remote shell capabilities

 

138692 [REALMBOT] << Remote shell ready. >>
138732 [REALMBOT] << Couldn't open remote shell. >>
138780 [REALMBOT << Remote shell already running. >>
 

138892 RealmBoT (flushdns.p.l.g) .
138921 .  Failed to flush ARP cache.
138952 RealmBoT (flushdns.p.l.g) .
138981 .  ARP cache flushed.
139004 RealmBoT (flushdns.p.l.g) .
139033 .  Failed to load dnsapi.dll.
139064 RealmBoT (flushdns.p.l.g) .
139093 .  Failed to flush DNS cache.
139124 RealmBoT (flushdns.p.l.g) .
139153 .  DNS cache flushed.

FTP server capabilities

 

139400 [REALMBOT-FTP] : Server started on Port: %d, File: %s, Request: %s.
 

141608 NICK %s
141616 JOIN %s %s
141636 PART %s

Keylogging

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").

Regular keylogging

 

140860 RealmBoT (keylog.p.l.g) .
140887 .  Normal key logger active.

Pay site keylogging

 

140924 RealmBoT (keylog.p.l.g) .
140951 .  Pay sites key logger active.

VNC

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.

 

109208 .asc vnc 100 0 0 -r -b
157868 RFB 003.008

DOS / DDOS features

 

145344 RealmBoT (supersyn.p.l.g) .
145373 . Failed to start flood thread, error: <%d>.
145424 RealmBoT (supersyn.p.l.g) .
145453 . Flooding: (%s:%s) for %s seconds.
145492 supersyn
145920 Ping flood
145932 ping.off
145944 .u.d.p...
145956 UDP flood
145968 udp.off
145976 .s.y.n...
145988 Syn flood
146000 syn.off
146008 .d.do.s...
146020 DDoS flood
146032 ddos.off

Scanning features

 

145792 Scan
145800 scanstop
57016 RealmBoT (portscan.p
157068 RealmBoT(portscan.p
157097   Scan not active.
157116 RealmBoT (portscan.p
157146   Current IP: %s.

Proxy / redirect capabilities

146060 TCP redirect
146076 proxy.redirect.off

HTTP Server capabilities

145020 web.on
145028 httpd.on
157195   Failed to start server, error: <%d>.
157240 RealmBoT (httpd.p

Authentication functions

137152 RealmBoT (irc.p.l.g) .
137176 .  *Failed pass auth by: (%s!%s).
137212 NOTICE %s :No pass for you.
137244 NOTICE %s :Are you a Fucker?. (%s!%s).
137292 RealmBoT (irc.p.l.g) .
137316 .  Random nick change: %s
137344 [REALMBOT]  << User %s logged out. >>

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.

Observations

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"):

Ir_registry_1

Ir_registry_2

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:

Network connections

According to the nameserver query log, the victim machine queried the hostname testirc21.sh1xy2bg.NET:

safegate# tail /var/log/querylog
19-Oct-2008 23:33:51.649 XX+/10.0.0.2/testirc1.sh1xy2bg.NET/A/IN

According to a packet dump on the safegate machine, interface eth1, a connection was being made to port 6667, TCP:

safegate# tcpdump -n -i eth1 port 6667 and host 10.0.0.2
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
 
00:33:18.992897 IP 10.0.0.2.1050 > 10.0.0.1.6667: S 2965576967:2965576967(0) win 64240 <mss 1460,nop,nop,sackOK>

Description of the C&C center

Server

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.

Channel

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:

Channel password

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

Admin password

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).

Host authentication

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.

Logging in

Authentication was achieved by sending a .login command to the software with the password gemp123 as a parameter:

There we go!

:-)

Verification of features

Driveinfo

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:

  • keylogging
  • scanning
  • 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.

Perl script

#
# This software is part of a submission
# to the Malware Challenge 2008
# http://www.malwarechallenge.info/
# Further Details please see http://www.emre.de/ or
# http://www.emre.de/wiki/index.php/MWC2008
#
# 24. Oct. 2008 Emre Bastuz
#
# The Perl script is a proof of concept
# for the detection and removal of the
# malware that has been analyzed for
# the contest
#
 
use Win32::Process::Info;
use Win32::OLE;
 
my %RegHash;
use Win32::TieRegistry ( TiedHash => \%RegHash );
my $Registry = \%RegHash;
 
my @reg_paths = (
 "HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\"
   . "Run\\Microsoft Svchost local services",
 "HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\"
   . "RunServices\\Microsoft Svchost local services",
 "HKEY_CURRENT_USER\\Software\\Microsoft\\OLE\\Microsoft Svchost local services" );
 
my $process_name = "Winsec32.exe";
 
# Running in testing mode
if ($ARGV[0] eq "--test") {
 print "Testing for registry keys:\n";
 foreach (@reg_paths) {
  if ($Registry->{$_} eq "Winsec32.exe") {
   print "Found malware entry!\n"; 
  }
  else {
   print "No malware entry found in registry\n";
  }
 }
}
 
# Running in cleanup mode
elsif ($ARGV[0] eq "--remove") {
 print "Deleting malware related registry keys: ";
 foreach (@reg_paths) {
  print ".";
  delete $Registry->{$_};
 }
 print " Done\n";
 
 # Kill process and delete file
 Win32::Process::Info->Set(variant=>'WMI');
 my $pi = Win32::Process::Info->new();
 for($pi->ListPids) {
  my ($info) = $pi->GetProcInfo($_);
  if ($info->{CommandLine} =~ /$process_name/) {
   print "Found running malware process!\n";
   my $pid = $info->{ProcessId};
   my $mw_path = $info->{CommandLine};
   $mw_path =~ s/ .*//;
   kill -9, $pid;
   #unlink $mw_path;
   $objFSO = Win32::OLE->new('Scripting.FileSystemObject');
   $objFSO->DeleteFile($mw_path);
   print "Deleted malware $mw_path\n";
   print "Killed malware with process id $pid\n\n";
  }
 }
}
 
# Print usage
else {
 print "Proof of concept for the Malware Challenge 2008\n";
 print "http://www.malwarechallenge.info/\n";
 print "This is a testing and removal tool for the Winsec32.exe backdoor.\n\n";
 print "24. Oct. 2008 - Emre Bastuz\n\n";
 print "Usage: mwremove.exe --test | --remove\n";
}
 
exit;

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