Authors
Gaurav Shukla, Gaurav.shukla@paladion.net, Paladion Networks
Rajesh Jose, Rajesh.jose@paladion.net, Paladion Networks
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
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.
--uninstall option will remove RaDa from C:\RaDa\bin\ directory and remove the registry entry <HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\RaDa REG_SZ c:\RaDa\bin\Rada.exe>
--help shows a dialog box displaying usage is RaDa and copyright to Raul Siles and David Perez.
--visible option displays
Internet Explorers connecting to 10.10.10.10
--GUI option shows a Graphical Interface for Installing, uninstalling, and executing.
--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. Filemon shows 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 paranoic about 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.
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.
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.
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.
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.
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.
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.
If your system is infected then
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.
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)
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.