MWC2008
From Emre´s Wiki
Intro
Last year 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 http://www.emre.de/files/mwc2008-emre-bastuz.pdf.
I thought it might be good idea to put the stuff on a Wiki (since OpenOffice has an export filter for MediaWiki syntax :-)
Have fun reading!
Cover
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
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:
- Bind3 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:
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 controll 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. >>
DNS & ARP related functions
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.
IRC related functions
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"):
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 controll.
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:
- testirc1.sh1xy2bg.NET
- http://www.Nivdav.net/Winsec32.exe
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
