Total Members: 14197
Posted by: Pez
« on: 13. September 2013., 12:46:53 »Andromeda Botnet Hides Behind AutoIt
Last month, I posted a blog about an increase in the use of AutoIt scripts by malware authors to carry out malicious activities. Attackers have used AutoIt scripts for a long time, and they are gaining in popularity due to their flexible and powerful nature. We have now come across another piece of malware (which turns out to be part of the Andromeda botnet) compiled with AutoIt to execute its malicious code. The botnet uses an AutoIt script to hide its malicious code and executes the code using AutoIt’s APIs. The Exe2Aut program can extract the contents of the main binary file as shown below:
("click the images to make them larger")
As shown above, the script is easy to understand, and drops a source file containing script code and two embedded files–a.vbs and f.txt–whose contents are shown below:
These look like simple plain-text files. The script drops a copy of itself in the start-up directory with the name config.exe. It then copies dropped files into a temp folder and executes a.vbs, which contains a base64 string and code to decrypt it. Once executed, the malware will drop another file, ensambla.txt, in the temp folder. The script calls DllStructCreate(), which creates a structure similar in style to C/C++ to be used in DllCall() for f.txt and ensambla.txt. The script next executes two local variables containing binary data by using Execute(BinaryToString()). Let’s pop up those variables using the AutoIt MsgBox() function to see the actual code:
The script sets the DLL structure data and executes the DLL procedure using AutoIt’s DllCall() function. The file f.txt contains the “MZ” header, the malicious code that turned out to be a new Andromeda botnet sample. (A few recent blogs have covered Andromeda; one of them published a nice analysis.) The code from published blogs looks very similar to our dropped file, but different CRC32 hashes for process names at the start of the code drew my attention. After some analysis, it turned to be a variant of Andromeda using a custom hash algorithm to generate hashes for process names, as shown below:
At the start, the binary checks for the mutex name “lol,” gathers running process names, calculates hashes using a custom algorithm, and compares them with hard-coded hashes. I found a few obvious process names but not all. (I’d like to thank my colleague Subrat Sarkar, who quickly wrote a small utility based on the preceding algorithm. It gave me a custom hash for process names as shown below:
Guessing all the process names along with hard-coded hashes manually would be a bad idea. So the idea is to collect all antimalware tools, VMware/VirtualBox/Sandboxie, and other the analysis tools process names to generate and compare hashes. That will help us identify all the process names this binary is looking for. So I quickly wrote a Perl script to generate hashes for all candidates, as shown below:
I was able to get all the process names used by this binary. All hard-coded hashes correspond to process names shown below:
If no matching process is found, then it will check for Sandboxie’s sbiedll.dll.
Andromeda trick fails
I was aware of an anti-VMware and antidebugging trick used by Andromeda. It checks if you are running a virtual machine by looking for a key under the “system\currentcontrolset\services\disk\enum” registry key and then doing string matching and a timing check using the “rdtsc” instruction for antidebugging. But both the tricks failed for this binary. Let’s see why.
• The trick used to get the string “vmaw,” “vbox,” or “qemu” fails because VMware 9 has a different string in the registry. Thus EAX+8 fails to get the required string.
• Even if the trick finds “awmv” (the reverse of “vmwa”) for older VMware versions, it checks using “61776D77,” which when converted to characters becomes “awmw.” The hard-coded hex string is wrong in this case (because the last byte, 77, is wrong). It should be “61776D76,” which when converted to characters becomes “awmv.”
• The binary contains antidebugging code using the rdtsc instruction, which doesn’t have a jump instruction to exit (so you can continue your analysis without any worries).
I was not convinced about these failed checks and thought these flaws might exist only for this particular binary. To cross-check I examined a few samples generated by Andromeda 2.06 builder (leaked on the Internet) and found all of these flaws exist in all of the binaries.
Once you bypass all antireversing tricks, the binary calls the main payload, which creates the Windows process wuauclt.exe (Windows Update) in suspended mode, as shown below:
Before that, the malware uses the following Windows APIs to create different sections and map them with malicious code.
Interestingly, the binary then injects some code at the entry point of wuauclt.exe. Here is the code injection:
The binary injects “PUSH 000A13B9, RET” instructions. So when ZwResumeThread() is called, wuauclt.exe will push the address “000A13B9” on the stack and return. This way malicious code will be executed in the context of the Windows process wuauclt.exe, shown below:
The control server is still active at the time of writing this blog. Attackers are using AutoIt scripts to hide and install malicious payloads. This example shows that AutoIt has easy and powerful APIs for executing malicious code. The Andromeda sample we analyzed also shows us a variety of methods used by the attackers, including custom hash generation for process names, anti-VMware/antidebugging techniques, and process injection.
Original article: Thursday, September 12, 2013 at 4:02pm by Umesh Wanve
Last month, I posted a blog about an increase in the use of AutoIt scripts by malware authors to carry out malicious activities. Attackers have used AutoIt scripts for a long time, and they are gaining in popularity due to their flexible and powerful nature. We have now come across another piece of malware (which turns out to be part of the Andromeda botnet) compiled with AutoIt to execute its malicious code. The botnet uses an AutoIt script to hide its malicious code and executes the code using AutoIt’s APIs. The Exe2Aut program can extract the contents of the main binary file as shown below:
("click the images to make them larger")
As shown above, the script is easy to understand, and drops a source file containing script code and two embedded files–a.vbs and f.txt–whose contents are shown below:
These look like simple plain-text files. The script drops a copy of itself in the start-up directory with the name config.exe. It then copies dropped files into a temp folder and executes a.vbs, which contains a base64 string and code to decrypt it. Once executed, the malware will drop another file, ensambla.txt, in the temp folder. The script calls DllStructCreate(), which creates a structure similar in style to C/C++ to be used in DllCall() for f.txt and ensambla.txt. The script next executes two local variables containing binary data by using Execute(BinaryToString()). Let’s pop up those variables using the AutoIt MsgBox() function to see the actual code:
The script sets the DLL structure data and executes the DLL procedure using AutoIt’s DllCall() function. The file f.txt contains the “MZ” header, the malicious code that turned out to be a new Andromeda botnet sample. (A few recent blogs have covered Andromeda; one of them published a nice analysis.) The code from published blogs looks very similar to our dropped file, but different CRC32 hashes for process names at the start of the code drew my attention. After some analysis, it turned to be a variant of Andromeda using a custom hash algorithm to generate hashes for process names, as shown below:
At the start, the binary checks for the mutex name “lol,” gathers running process names, calculates hashes using a custom algorithm, and compares them with hard-coded hashes. I found a few obvious process names but not all. (I’d like to thank my colleague Subrat Sarkar, who quickly wrote a small utility based on the preceding algorithm. It gave me a custom hash for process names as shown below:
Guessing all the process names along with hard-coded hashes manually would be a bad idea. So the idea is to collect all antimalware tools, VMware/VirtualBox/Sandboxie, and other the analysis tools process names to generate and compare hashes. That will help us identify all the process names this binary is looking for. So I quickly wrote a Perl script to generate hashes for all candidates, as shown below:
I was able to get all the process names used by this binary. All hard-coded hashes correspond to process names shown below:
If no matching process is found, then it will check for Sandboxie’s sbiedll.dll.
Andromeda trick fails
I was aware of an anti-VMware and antidebugging trick used by Andromeda. It checks if you are running a virtual machine by looking for a key under the “system\currentcontrolset\services\disk\enum” registry key and then doing string matching and a timing check using the “rdtsc” instruction for antidebugging. But both the tricks failed for this binary. Let’s see why.
• The trick used to get the string “vmaw,” “vbox,” or “qemu” fails because VMware 9 has a different string in the registry. Thus EAX+8 fails to get the required string.
• Even if the trick finds “awmv” (the reverse of “vmwa”) for older VMware versions, it checks using “61776D77,” which when converted to characters becomes “awmw.” The hard-coded hex string is wrong in this case (because the last byte, 77, is wrong). It should be “61776D76,” which when converted to characters becomes “awmv.”
• The binary contains antidebugging code using the rdtsc instruction, which doesn’t have a jump instruction to exit (so you can continue your analysis without any worries).
I was not convinced about these failed checks and thought these flaws might exist only for this particular binary. To cross-check I examined a few samples generated by Andromeda 2.06 builder (leaked on the Internet) and found all of these flaws exist in all of the binaries.
Once you bypass all antireversing tricks, the binary calls the main payload, which creates the Windows process wuauclt.exe (Windows Update) in suspended mode, as shown below:
Before that, the malware uses the following Windows APIs to create different sections and map them with malicious code.
Interestingly, the binary then injects some code at the entry point of wuauclt.exe. Here is the code injection:
The binary injects “PUSH 000A13B9, RET” instructions. So when ZwResumeThread() is called, wuauclt.exe will push the address “000A13B9” on the stack and return. This way malicious code will be executed in the context of the Windows process wuauclt.exe, shown below:
The control server is still active at the time of writing this blog. Attackers are using AutoIt scripts to hide and install malicious payloads. This example shows that AutoIt has easy and powerful APIs for executing malicious code. The Andromeda sample we analyzed also shows us a variety of methods used by the attackers, including custom hash generation for process names, anti-VMware/antidebugging techniques, and process injection.
Original article: Thursday, September 12, 2013 at 4:02pm by Umesh Wanve