Introduction

As part of the September Scan of
the Month, we analyzed a suspicious binary– it enabled us to hone our skills in
analyzing malware. This write-up describes how we analyzed the binary and our
findings from the analysis.

Even before we downloaded the
binary from the honeynet site, we reviewed two books “Malware: Fighting Malicious
Code”, by Ed Skoudis, Lenny Zeltser and “Computer Forensics: Incident Response
Essentials”, by Warren Kruse, Jay Heiser to refresh our concepts in malware
analysis.

Initial Setup and Analysis

Initial Setup

To welcome the binary, we setup a
small lab using VMWare. VMWare enables us to host multiple operating systems in
a virtual environment. Since the malware could potentially do damage, we wanted
a controlled environment where we could tinker with the little fellow.

Our lab consisted of a single
Windows XP host running VMWare and Windows XP Professional as the guest
Operating System. We setup the guest system with our favorite analysis
tools. (These tools are described in the Appendix). We also copied the malware
zip file into the guest operating system. Before executing the malware, we took
a VMWare snapshot of the system – this would enable us to revert to the initial
state at the click of a button whenever we wanted to. We expected the malware
would mess with a few settings, and we needed the flexibility to go back to the
original state once in a while. In the host system, we installed Snort IDS with
all rules enabled. The IP address we chose for the host OS was
192.168.0.101 and for the guest OS was 192.168.0.102. For now, the only user we
had on both these systems was the default Admin with administrative privileges.
After taking a VMWare snapshot of Guest operating system we started our
analysis.

Step by Step analysis

1.We extracted the malware to the
desktop using WinZip. It created a directory RaDa with single file RaDa.exe in
it.

2.Since RaDa.exe looks like a
Windows binary, we wanted to try disassembling it first. If we are lucky,
disassembling might give us a clue of what the binary does, especially by
analyzing the strings embedded in the program. Further analysis might even lead
us to reverse engineering specific sections of code, though of course that’s no
easy task. So, we opened the binary in IDA Pro. Oops…the disassembly failed!
Seems like the binary is doing some non-standard stuff that caused the
disassembly to fail. It probably has parts of it encrypted and an initial
section might decrypt it during initial load – that would certainly break the
disassembly.

3.Since the disassembly failed, we
are going to execute the RaDa.exe binary. First, we want to see it come alive
in memory and also see if it sends out any traffic. So we started Ethereal and
Process Explorer in the Guest system and Snort in the Host system.

4.We used a tool called Process
Explorer to view the basic details of RaDa when it was running. When RaDa
started running, we noticed that a new process by that name was created, and
that it also started an IE instance. This suggested that RaDa did not hide
itself like a kernel level root kit from process viewers, (which was good news)
and that it was also making use of IE. Hmm, that’s interesting!

5.Satisfied at seeing RaDa’s
activity in process explorer, we looked at the network to see if RaDa was
sending out traffic. For this we used Ethereal, the popular sniffer. We saw Arp
requests from the machine and 3 SYN packets to 10.10.10.10 on port 80. RaDa
seems to be contacting a web server on 10.10.10.10.

6.Now we need to find out whether
RaDa is doing HTTP request. So we changed IP addresses of Guest Windows XP to
10.10.10.9 and Host Windows XP to 10.10.10.10. Started Netcat on port 80 of
Host Windows XP. Yes, RaDa is making a HTTP request for
/RaDa/RaDa_command.html.

7.This is really interesting, we
need to explore more. So we replaced the Netcat apache and placed a test
rada_command.html file in the RaDa directory. RaDa downloaded the file all
right, but doesn’t seem to be doing anything on it. We guess that RaDa expects
some commands in the RaDa_commands file. So we changed the contents of
RaDa_command.html to <cmd> <mkdir test>. No luck! We probably don’t
have the correct syntax. We try different variations with different delimiters
etc, but the binary doesn’t yield to us. For now, we seem to have reached a
dead end here.

8.Let’s go back and see if we can
find any strings in the binary. Remember the disassembly had failed. But, it’s
a fair guess that the binary when it’s running in memory would have unpacked
itself. Now, that’d be a great place to search for strings. We used Winhex a
memory viewer to look at the process in memory. Yeah… here come the
author’s names: Raul Siles and Rez. The memory also shows references to vbaLenBstr, vbavartstne - VB internal function names.
Looks like our friends developed it in Visual Basic. Oh! They are generous -
even command line options used in RaDa.exe are also visible. (--server,
--visible, --uninstall, --help, --installdir, --cgiget, --cgipath).

9.Well, now that we got
the command line options lets try it. We reverted the system to its original
state and ran RaDa with the various command line options. Here’s what we found.

--Any wrong options
will display a dialog box saying usage RaDa and the copy right information.

10.Now it’s the time to find file changes and
registry changes made by RaDa. To find that we reverted to the initial setup
and executed the binary again. But this time, we tracked the file and registry
activity of the binary closely with filemon and regmon. Filemonshows
the creation of directory c:\RaDa and two sub directories. The RaDa.exe is
copied to the sub directory c:\RaDa\bin. And an empty temp directory is also
being created. Regmon shows some registry keys being created.
<HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\RaDa
REG_SZ c:\RaDa\bin\Rada.exe>. The registry entry is for restarting the
binary automatically at reboot. I confirmed it with a reboot while I was
sipping my coffee.

11.TCPView and netstat doesn’t show any listening
ports. But, if this guy is a kernel level root kit, he could have hid himself
from these tools. I guess I’m just paranoicabout root kits
installed by binary. So I ran Nmap port scan from Host Windows XP to confirm no
ports were opened by the malware. None were.

12.Considering that the malware didn’t hide
itself from process viewers and netstat, I guess it’s not one of those kernel
level root kits.

13.Now one of our doubts was what will happen if
I login as lower privileged user and try to execute RaDa. Let us try and see.
RaDa.exe failed to load automatically throwing an error.

14.Based on our observations, we conclude that
this is a backdoor, awaiting commands from a master at 10.10.10.10. This kind
of backdoors can be used for distributed denial of service attacks.

Answers to Questions

Identify and provide an overview of the binary, including the
fundamental pieces of information that would help in identifying the same
specimen.

On execution RaDa.exe
will create RaDa directory in C: and two sub-directories in it. It then copies
itself into C:\RaDa\bin sub-directory. Registry entries are added to start the
binary on reboot. The binary will invoke Internet Explorer functions for
connecting to 10.10.10.10 using the HTTP protocol. It is trying to access
/RaDa/RaDa_command.html file on that server. RaDa keeps on trying this every
minute. This looks like a backdoor program which accepts commands from Master
to probably perform a DDoS. Some of the strings in the binary
refer to popular Denial of Service attacks, so this seems to be the most likely
function.

Identify
and explain the purpose of the binary.

The binary RaDa.exe is
a backdoor which connects to a master. The binary was connecting to 10.10.10.10
using HTTP to download RaDa_commands.html. It looks like it is trying to get
some commands from a master. Several RaDa.exe (slaves) could possibly be used
to do a distributed denial of service attacks. Some of the strings in the
binary refer to popular Denial of Service attacks, so this seems to be the most
likely function.

Identify
and explain the different features of the binary. What are its
capabilities?

The binary is a
malicious piece of code which will connect to a specific IP address 10.10.10.10
and download RaDa_commands.html. On execution of binary it makes sure that it’s
gets executed every time the system is rebooted by making a registry entry. The
binary will be executed with the logged in user privileges. However
Administrator privileges are required for executing this binary. A limited user
will get an error after logging into an infected system. The present binary is
capable of making a request 10.10.10.10 every minute and requesting a download
on RaDa_commands.html. Our assumption is the malware is trying to get some
instructions from 10.10.10.10 (master) for further actions. We have tried
different syntax in RaDa_commands.html but didn’t work.

The malware behaves
like a backdoor. A backdoor is an application which executes commands from a
remote attacker. In this case, RaDa connects to a Master periodically for
Instructions. Usually, this type of malware is used for distributed denial of
service attacks. RaDa.exe tries to download instructions every minute from
master 10.10.10.10. This 10.10.10.10 is configurable and the author of the
program can change this value to a desired value.

Identify
and explain the binary communication methods. Develop a Snort signature to
detect this type of malware being as generic as possible, so other similar
specimens could be detected, but avoiding at the same time a high false
positives rate signature.

The only communication
we have noticed is the http access to 10.10.10.10 at predetermined interval
which about a minute. One easy method to develop a signature is to use the
combination of IP address 10.10.10.10, port 80 and the request “Get
/RaDa/RaDa_commands.html. This will reduce the number of false positives but we
will not be able to capture even the simplest variants of the malware. So to
develop a generic snort signature we should find out repetitive requests for
same file. For example if a machine is requesting a file for more than 7 times
in 10 minutes. This will capture even the variants of this attack but it may
generate false positives because the legitimate sites which do continuous
refreshing will trigger this alert. Those sites are very less and can be
exempted from the signature.

Identify
and explain any techniques in the binary that protect it from being
analyzed or reverse engineered.

The binary protects
itself against disassembly and reverse engineering. The technique used seems to
be to encrypt part of the binary; this gets decrypted during initial load by a
built-in decrypting engine. Since this is a self-modifying piece of code,
static disassembly will fail. A method to overcome this is to execute the
binary (load binary into memory) and view the memory used by the binary. We
used Winhex for viewing the binary in memory.

Identify
another tool that has demonstrated similar functionality in the past.

This malware is
similar to any backdoor in master/slave mode. Slaves fetch commands from Master
and execute those commands. An example of similar tool is trin00 which was seen
in 1999. Trin00 uses UDP for communication while RaDa.exe uses TCP for
communicating with master.

Suggest
detection and protection methods to fight against the threats introduced
by this binary.

Do
not execute any binary unless it is from a trusted source

This
binary is harmless if it is not executed

Check
the system frequently for unknown processes

Check
firewall and IDS logs

Check
the computers for generation of abnormal traffic.

If your system is
infected then

Unplug
the computer from network if possible

Check
task manager for malicious processes

Find
out the files used by malicious process

Kill
the malicious process

Search
for file name in the hard disk including hidden directories and files

Remove
all files from Hard disk.

Search
Registry for malicious entries

Remove
all entries from registry

Reboot
the system

Check
the task manager for malicious process

Use
a sniffing tool like ethereal to make sure that all the traffic to and
from the system are normal

Educate
the users about malicious softwares

Bonus Questions

Is
it possible to interrogate the binary about the person(s) who developed
this tool? In what circumstances and under which conditions?

The binary is
protected against disassembly. So disassembly on the binary file will not give
any information about authors. A method to overcome disassembly protection is
to execute the binary and read the binary from memory. When we did
this and viewed the binary in memory using Winhex, we saw the name of the authors.
The names given in the binary were Raul Siles and Rez. Another alternative is
to try –-help options in command line. The –-help option can be found out from
string search in memory. This will show dialog box saying this copy righted to
Raul Siles and David Perez.

What
advancements in tools with similar purposes can we expect in the near
future?

Following advancements
can be expected

1.The traffic between
the malware and the Master system will be encrypted.

2.There will be more than
one master system for one infected system to connect.

3.The master systems be
will identified by names similar to legitimate sites like www.c1sco.com

4.The malware will
request for www.c1sco.com/index.html
and the master systems will reply back with similar index.html like Cisco with
some commands hidden in it.

5.Kernel level root kits
will load in the infected system which will make the detection much difficult.
The root kits will hide processes and files.

6.The infected machines
will attack some vulnerability in computers in the local network and replicate
(like worms)

Appendix: Tools Used

IDA Pro – IDA Pro is disassembler tool
which can be used to see the strings and other readable information from
malicious binary.

Winhex - Winhex is used to view the
contents of the memory. This tool is used to see the strings and other readable
information in executables from memory.

TCPView - TCPView is similar to Netstat
program and will show detailed listings of all TCP and UDP endpoints. This tool
is used to find out the open ports and connections initiated by the malware.

ProcExecNT – ProcExecNT is a process
explorer which will show details about processes. This tool is used to find out
whether the malware is opening new processes and what all handles and DLLs it
uses.

Filemon - FileMon is a file monitoring
tool. This tool is used for finding what all files and directories are accessed,
created, modified and deleted by the malware.

RegMon - Regmon is a Registry monitoring
utility that will show you which applications are accessing your Registry,
which keys they are accessing, and the Registry data that they are reading and
writing. This tool is used to find out what all modifications on registry are
done by malware.

Ethereal - Ethereal is a popular sniffer
which can capture and decode network data. This tool is used to capture all the
traffic between malware machine and other computers.

Snort - Snort is an intrusion detection
system. Snort is used to find out whether the malware is doing any known
attack.

Netcat – Netcat is a utility which reads
and writes data across network connections, using TCP or UDP protocol. This is
used to find out the request made by the malware.

Nmap – Nmap is a popular
port scanner. Nmap is used find out any ports open by Malware and hidden
from TCPVIEW and Netstat. (Hiding the open ports using kernel level root kits)

Apache – Apache is an open source web
server. This is used to cater the requested file for the malware.