{"id":29166,"date":"2013-09-12T16:02:00","date_gmt":"2013-09-12T23:02:00","guid":{"rendered":"http:\/\/blogs.mcafee.com\/?p=29166"},"modified":"2025-05-27T22:19:25","modified_gmt":"2025-05-28T05:19:25","slug":"andromeda-botnet-hides-behind-autoit","status":"publish","type":"post","link":"https:\/\/www.mcafee.com\/blogs\/other-blogs\/mcafee-labs\/andromeda-botnet-hides-behind-autoit\/","title":{"rendered":"Andromeda Botnet Hides Behind AutoIt"},"content":{"rendered":"

Last month, I posted a blog<\/a> 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:<\/p>\n

\"anrdomeda_autoit_decode\"<\/a><\/p>\n

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:<\/p>\n

\"andromeda_files_dropped\"<\/a><\/p>\n

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\u2019s pop up those variables using the AutoIt MsgBox() function to see the actual code:<\/p>\n

\"andromeda_varibales\"<\/a><\/p>\n

The script sets the DLL structure data and executes the DLL procedure using AutoIt’s DllCall() function. The file f.txt contains the \u201cMZ\u201d 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.)<\/a> 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:<\/p>\n

\"andromeda_custom_hash_algo\"<\/a><\/p>\n

At the start, the binary checks for the mutex name \u201clol,\u201d 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:<\/p>\n

\"andromeda_custom_hash_utility\"<\/a><\/p>\n

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:<\/p>\n

\"andromeda_perl_hash_output\"<\/a><\/p>\n

I was able to get all the process names used by this binary. All hard-coded hashes correspond to process names shown below:<\/p>\n

\"andromeda_all_process_names\"<\/a><\/p>\n

If no matching process is found, then it will check for Sandboxie\u2019s sbiedll.dll.<\/p>\n

\"andromeda_sbiedll_check\"<\/a><\/p>\n

Andromeda trick fails<\/b><\/h2>\n

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 \u201csystem\\currentcontrolset\\services\\disk\\enum” registry key and then doing string matching and a timing check using the \u201crdtsc\u201d instruction for antidebugging. But both the tricks failed for this binary. Let\u2019s see why.<\/p>\n

\"andromeda_failed_checks\"<\/a><\/p>\n