From: DESCLAUX Fabrice [desclaux@enseirb.fr] Sent: viernes, 03 de septiembre de 2004 19:42 To: sotm@honeynet.org Cc: team@droids-corp.org; crew@rstack.org Subject: Scan of the month 32 Hello, here is the work i have done for the SotM 32. Thanks for it, serpilliere. (_.- SotM 32 -._) 1. Identify and provide an overview of the binary, including the fundamental pieces of information that would help in identifying the same specimen. The binary has a size of about 20Ko. A quick look at the binary informs that its sections are not common, and maybe packed: instead of the classical .text and .data sections, there are JDR0 and JDR1 sections. The string MSVBVM60.DLL leads us to think that it may has been coded in Visual Basic. 2. Identify and explain the purpose of the binary. The goal of the binary is to spy and control/gather informations of the victim. Reverse of the soft: The soft is packed. This means that we cannot disassemble the binary code: the only part we can statically disassemble is the code of the packer. To recover the unpacked binary, we will do what is called a "manual unpacking". The main idea is to let the packer do his job, ie unpack the soft in memory, and then dump this to the disk. In order do to so, we must stop the execution just after the packer has completed his work, and before the first "real" instruction of the effective binary has been executed. To see this crucial point, some tips can help: the packer starts with a "pushad", so its last instruction may be "popad". Moreover, the final jump to go to the Original Entry Point (OEP) often means a jump to another section: here, to the JDR0. So the instructions combo: popad jmp 40XXXX could be the good one. (with 40XXXX in the JDR0 for example) At this point we can stop the execution and dump the memory to the disk. Some modifications can be done to have a fully functional dump like fixing imported fonctions (manualy, or with tools like ImpRec), but here the aim is just to get a soft that could be disassembled. There are many ways to reverse a code but this is how I do it in this case: here, reading of the static listing shows the goal of functions revealed by some string references like "screenshoot" or "MacAdress". So we can make a first quick pass in which we will note simple and easy to guess functions. Then we can use them to understand the aim of other ones. To finish with, a dynamic study with a debugger is done in order to confirm the way the binary works (and dump of the network traffic). 3. Identify and explain the different features of the binary. What are its capabilities? Once the binary is first launched, it creates a Reg value in HKLM\Software\Microsoft\Windows\CurrentVersion\Run\. The binary is then launched every time Windows boot. It can execute other binaries remotely, download files, upload files, take screenshot, and stay sleepy. Most of the functionalities can be tweaked by args at launch time: --visible : allows some visible "debug" windows --server : changes the default server --commmands : changes the file to get for remote commands execution --cgipath : set cgi path --cgiget : set cgi download path --cgiput : set cgi upload path --tmpdir : changes tmp rada dir --period : changes the remote lookup time interval --cycles : number of http remote command look --help : shows link to the sotM goal web page --gui : beautiful vb box to install/uninstall rada ;-) --install : install dir of rada --noinstall : don't install rada --uninstall : uninstall rada --authors : show Copyright (C) 2004 Raul Siles & David Perez (with conditions given below) --verbose is a dummy option. 4. 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 binary connect to a server by http, get the html page in rada directory (or another theawed one) and download the page. Once this job done, it parses the web page. The page has the following format:
...
The name represents the action to do. These are the actions allowed: "exe" : execute the application named "value_passed" "get" : download the file named "value_passed" "put" : upload a file named "value_passed" "screenshot" : take a screen shoot called value_passed and write it in rada tmp dir "sleep" : have a sleep of value_passed long The binary uses a VBSscript using IE+ADO for transfering datas (Copyright (C) 2001 Antonin Foller, PSTRUH Software :) The signature can use those term to detect rada: name="exe/get/put/screenshoot/sleep" But we also can use the particular string of the uploader "---------------------------0123456789012" to detect when a file is uploaded alert tcp $EXTERNAL_NET 80 -> $HOME_NET any (msg:"Reverse trojan RaDa-like detected"; flow:from_server,established; pcre:"/name=(exe|get|put|screenshoot|sleep)/"; classtype:trojan-activity;) alert tcp $HOME_NET any -> $EXTERNAL_NET 80 (msg:"Reverse trojan RaDa-like detected"; flow:to_server,established; content:"---------------------------0123456789012"; classtype:trojan-activity;) 5. Identify and explain any techniques in the binary that protects it from being analyzed or reverse engineered. First of all, the binary is packed. The section are renamed by JDR0 and JDR1 . This is not a well know packer, and maybe a home made one: JDR stands for "Jorge David Raul " the programmers' names. We are warned by the size of section 0: its raw size is 0 and its virtual size is B000. This typicaly means that the section will be decrypted/unpacked at run time. This job is done by the JDR1 section pointed by the binary entry point. The packer has deleted the import table, and a manual fix is necessary to get a working dump (a tool like ImpRec also does the job). Once the dump is done, we can see that it has been programmed in Visual basic which can be in a certain way a kind of protection: its sometimes hard to follow vb code :) (ok, i dislike VB in fact) String reference like : "Starting DDoS Smurf remote attack..." can be concidered as a certain anti-reverse protection: it could disturb the reverser (not for long). Some tricks are used to avoid the binary being analysed in vmware: it looks for the base registry HKLM\Software\VMware, Inc.\VMware Tools\InstallPath and moreover, exec a SQL command to look for the mac adresse to detect typical VMWARE 's one. (OUI 00:0C:29: 00:05:69: 00:50:56: ) We can notice that the binary has been 'defused': the default web server's ip is 10.10.10.10 and if its tweaked, a test is done to keep it in local network (172.16.*.* or 192.168.*.*) 6. Categorize this type of malware (virus, worm...) and justify your reasoning. This malware can be considered as a reverse trojan: it looks at a server web page in which it tries to find commands to execute. It has the ability to download/upload file and take screenshot : it can also be considered as a spyware too. 7. Identify another tool that has demonstrated similar functionality in the past. It can be compared to an ircbot that execute remote commands via irc instead of http. Backdoor.Dewin.k seems close to this one too (http reverse trojan) 8. Suggest detection and protection methods to fight against the threats introduced by this binary. The application creates a common base registry entry in HKLM\Software\Microsoft\Windows\CurrentVersion\Run\ this can be used to detect it. Moreover, it does web request every X second so this web traffic can be monitored. A protection can be to use a personnal firewall that monitors execution of applications or unautorised web access. ---------------- Bonus Question: Is it possible to interrogate the binary about the person(s) who developed this tool? In what circumstances and under which conditions? Yes, by passing the arg --authors to the application at launch time. But a test is done to detect vmware: the reg value and mac address. So the buddy can't have vmware installed. Another one is to be on a Windows version that is not Windows 98 : the way to get mac adress (SELECT * FROM Win32_NetworkAdapterConfiguration WHERE IPEnabled = True) is by asking to the winmgmts, which will crash the soft. (maybe a bug?) What advancements in tools with similar purposes can we expect in the near future? The first one is to delete the restriction to the local ip server. Another can be to take photos by webcam or else (sweet:) Second, delete the options of the soft (victims are not supposed to play with) A keyloger can be a good idea. Hiding the processus from processus list can improve its furtivity. We could use less fingerprintable traffic, with random time between requests to the server, in order to make detection by NIDS harder. Another idea can be to do a code injection in Internet explorer processus to let him do the web requests for us (and then avoid the warn of some firewall) We can try to fingerprint other BOCHS emulator, QEMU, or PLEX86 which could be used to study the soft, or run a Honeypot. A best packer could be used with anti soft ice tricks, anti soft and hardware breakpoint, CCA assembly code, hooked import functions, anti dump ... Serpilliere. Droids Corporation, official subcompany of RstAck www.rstack.org