Scripting Bot Malware: No Need to Learn C to Launch a Cyber Attack
T wo weeks ago we came across a piece of malware that turned out to be a full-blown bot—one that is capable of taking full control over a user’s machine, and all encapsulated within less than 3K lines of source code! What’s scary is that writing it required no special skills. Access to some existing tools—and of course the desire to write malicious code—was all the author needed.
I won’t go into any further analysis regarding the identity of the attacker(s), how many there are, what they target, or what state(s) the majority of the attackers are coming from. I would rather focus on the technical details and share my findings.
My main concern is that this is not an isolated case and indicates a trend. While there is nothing inherently wrong with scripting frameworks implementing interpreters and JIT compilers for scripting languages, it would be helpful for them to give something to the security community to allow us properly assess any script embedded in any executable file that potentially may cause damage.
Here is the link and the VirusTotal report as of today, 26th of November 2013.
This is what the file looks like in Windows Explorer:
Dynamic behavioral analysis
I decided to run it through our Vinsula Execution Engine (VEE) to find out what it does.
After running the malware through the VEE, we generated a report that reveals what the malware does and which Command and Control (CnC) servers it talks with.
Here is the process tree that results from starting the main malware image file: vt-upload-fRDXv.exe.
+ Explorer.EXE [Process Id: 2128] + VEE001.exe [Process Id: 3028] [Parent Id: 2128] + vt-upload-fRDXv.exe [Process Id: 2396] [Parent Id: 3028] + extruster.exe [Process Id: 2964] [Parent Id: 2396] + netsh.exe [Process Id: 3096] [Parent Id: 2964]
The following list provides details about the command line with which each of the processes in the tree above is launched.
An interesting aspect of the behavior of this malware that at first drew my attention was that it uses netsh Windows utility to add a rule to the built-in Windows firewall.
vt-upload-fRDXv.exe Command Line: "c:\temp\170560b5bf004d34acf0ccdedc3cb8ea\vt-upload-fRDXv.exe" extruster.exe Command Line: "C:\Users\[UserName]\AppData\Local\Temp\extruster.exe" "del" c:\temp\170560b5bf004d34acf0ccdedc3cb8ea\vt-upload-fRDXv.exe netsh.exe Command Line: "C:\Windows\System32\netsh.exe" firewall add allowedprogram "C:\Users\[UserName]\AppData\Local\Temp\extruster.exe" "extruster.exe" ENABLE
How does this malware work?
After launching the main executable vt-upload-fRDXv.exe, it copies itself to user’s local temp folder under a different name: extruster.exe. The two copies—the main malware image file and the copy—are identical. The name is not random and although in an obfuscated form, it appears in the decompiled script from which we provide a snippet further down in this post.
Interestingly, this malware doesn’t quite look like a dropper since it doesn’t initially download any payload.
After copying itself, the main malware process vt-upload-fRDXv.exe launches the newly created copy of itself extruster.exe.
Before launching extruster.exe, vt-upload-fRDXv.exe creates a configuration file extruster.exe.ini in same folder (C:\Users\[UserName]\AppData\Local\Temp\extruster.exe.ini).
vt-upload-fRDXv.exe Event:Create File[C:\Users\[UserName]\AppData\Local\Temp\extruster.exe.ini] Event:Write File[C:\Users\[UserName]\AppData\Local\Temp\extruster.exe.ini]
It is a standard INI file with an empty section and key “usb” set to “N”. Here is the content of the configuration file:
The command line that vt-upload-fRDXv.exe passes to extruster.exe, instructs the child process to delete the parent process, thus hiding its tracks.
Once launched, the child process extruster.exe deletes its parent process, the main malware vt-upload-fRDXv.exe.
Next, extruster.exe, ensures that all its transport requirements are met and adds a custom rule to Windows firewall database to allow itself to send and receive data over TCP/IP on a non-standard TCP port: 8828. The way this is done is by using netsh Windows utility and passing the command line shown in the list with command lines above.
The following screenshot shows the result of executing netsh.exe utility and adding a custom rule to the built-in Windows firewall. Assuming that is not behind a corporate firewall, this effectively will allow extruster.exe to start communication with the CnC server and send and receive any data.
As with any other persistent malware, extruster.exe registers itself as a run at startup application by modifying the registry. Below is the entry in the VEE log showing this event:
Action:RegNtSetValueKey Key:HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run Node:[null] Name:extruster.exe Value:"C:\Users\[UserName]\AppData\Local\Temp\extruster.exe"
The screenshot below shows the registry change in Registry Editor.
To be sure, the malware needs to connect to the CnC server. For that to happen, extruster.exe attempts to connect to 22.214.171.124 (that resolves to “e7.sytes.net“) on port 8828. The IP address appears to be located in Germany. Below is the geographic location of the IP.
A quick static code analysis
Next, we decided to find out more about the executable by disassembling it using IDA-Pro. It didn’t take long to find a big “if” statement that indicates the executable was built using AutoIt – http://www.autoitscript.com (N.B. the AutoIT software was not utilized in any of this research).
Here is a quote from AutoIt’s Website:
AUTOMATION AND SCRIPTING LANGUAGE AutoIt v3 is a freeware BASIC-like scripting language designed for automating the Windows GUI and general scripting. It uses a combination of simulated keystrokes, mouse movement and window/control manipulation in order to automate tasks in a way not possible or reliable with other languages (e.g. VBScript and SendKeys). AutoIt is also very small, self-contained and will run on all versions of Windows out-of-the-box with no annoying “runtimes”...
AutoIt also allows malware authors to create a malicious script with full access to OS resources. The script gets embedded into a small standalone AutoIt executable—no need for Visual Studio or any other compilers to create an AutoIt executable with a script in it.
The following screenshot shows a bit of the disassembled malware code with the “if” statement and strings that clearly indicate that this is an AutoIt executable.
Following screenshot provides the “C” version of the assembly from the screenshot above.
Without going further, we decided to contact the authors of AutoIT to collaborate with them. We were unable to reach them through either their web site’s contact form, direct email, or phone.
Dissecting the AutoIT script
Our next step was to find out if we could disassemble the AutoIT script. Luckily, we were able to reverse engineer it and get the full, although obfuscated, source code of the AutoIt bot. As this is a full-blown bot capable of providing full control over the target computer, we are not going to disclose the full AutoIT script as that would pose a security threat by allowing other individuals to reuse it.
At the beginning of the script there are some heavily obfuscated constants and variables. Fortunately, it was not very difficult to convert them to the actual values used by the executable created by AutoIt.
One interesting element is that the authors hardcoded a timestamp, most likely indicating when the malware was published. Also of note, one of the very first things that the malware does is read the HDD serial number, which is likely used by the CnC server to identify the individual bots.
Following screenshot shows some of them:
After initializing the variables, the script connects to the CnC server using a TCP connection and starts listening for commands.
Depending on the command received from the server, the bot is then able to send any information requested by the CnC as well as execute local programs and commands right under the nose of the user, who will most likely fail to notice or detect these malicious activities.
The bot also has the ability to remove any traces of its existence on the system, if the CnC sends a command that instructs the bot to delete itself.
All the data that is sent to the CnC is in string format and authors decided to use “0njxq80” as a delimiter in the string to specify the boundary of the different segments of data being uploaded to the CnC host.
This is what one of the first data being sent to the CnC looks like:
lv0njxq8017-10-2013_20CB86D00njxq80[UserName]-BUSINE0njxq80[UserName]0njxq800njxq80WIN_7 X86 SP10njxq800.4d0njxq80N0njxq80—
The following screenshot reveals more details about the bot’s logic and how it handles commands received from the CnC host.
Debugging the malware
One of the steps in investigating malware is debugging the live executable and getting a better picture of what the malware is supposed to do. With this sample, after attaching WinDbg, a screen popped up indicating that the author embedded some sort of anti-reversing protection.
Using WinDbg and placing a breakpoint at kernel32!IsDebuggerPresent revealed that the executable uses a very simple anti-debugging technique. IsDebuggerPresent() Windows API simply reads the value of the PEB (Process Environment Block) BeingDebugged flag which is located at offset 2 in the PEB structure. Bypassing this protection is as easy as setting the value of BeingDebugged to 0.
With this particular sample, the CnC server has been shut down, but that wouldn’t stop the authors of the script from modifying it and repointing it to a different CnC host.
The hashes of the files related to this sample are copied below.
================================================== Filename : vt-upload-fRDXv.exe MD5 : 0829b1639d332fe3c5ee9190f67c2ff1 SHA1 : c146747ac00515a8f4c03160ed9d071604b96a9f CRC32 : 2313ec7a SHA-256 : 2e1bc172ab68b1c4a37614823620a264b38aa3ab1e104f6a0983ca8869726b87 Full Path : vt-upload-fRDXv.exe Modified Time : 11/14/2013 5:36:06 AM Created Time : 11/25/2013 7:31:06 PM File Size : 779,993 File Version : Product Version : Identical : Extension : exe File Attributes : A ==================================================