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:

anrdomeda_autoit_decode

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:

andromeda_files_dropped

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:

andromeda_varibales

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:

andromeda_custom_hash_algo

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:

andromeda_custom_hash_utility

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:

andromeda_perl_hash_output

I was able to get all the process names used by this binary. All hard-coded hashes correspond to process names shown below:

andromeda_all_process_names

If no matching process is found, then it will check for Sandboxie’s sbiedll.dll.

andromeda_sbiedll_check

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.

andromeda_failed_checks

  • 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:

andromeda_createprocess

Before that, the malware uses the following Windows APIs to create different sections and map them with malicious code.

andromeda_section_mapping

Interestingly, the binary then injects some code at the entry point of wuauclt.exe. Here is the code injection:

andromeda_injected_code

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:

andromeda_run_payload

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.

Would You Like Some Fish with That Phishing Site?

Phishers are known for making their phishing sites look exactly like the sites they are spoofing. We have seen plenty of examples of the detail they employ, like using JavaScript to include the current date in their static pages. In recent times, Symantec have seen an increase in generic email phishing. Unlike normal phishing, where phishing messages usually have a target in mind (bank customers or social network users, for instance), the generic email phishing technique is slightly different. In generic email phishing, the phishers will target any email address; who the target is does not matter.
 
These generic phishing messages usually claim that the recipient's mailbox size has been exceeded, and direct them to urgently "re-validate" their mailbox to prevent disruption to their email. Symantec recently identified a generic email phishing website which, at first glance, appeared normal. It looked fairly amateurish—demonstrating phishers' poor design skills when they don't have a professional site to rip off—but the site was strikingly unusual for one reason: it had a fish pattern background.
 
phish_site_with_fish_600px.jpg
Figure. Generic phishing website with fish pattern background.
 
We are not sure exactly why phishers decided to use this particular background. Was it a random, unfortunate mistake? An inside joke among fellow phishers? Or perhaps a brazen but not-so-subtle hint to experienced users that it was actually a phishing site? Perhaps—since the site is partially in Italian—the phishers were unaware of the similarity between "phish" and "fish"?
 
To protect yourself from phishing scams, be wary of messages claiming that your account has been restricted or somehow needs to be updated. Keep your security software up to date. Symantec.cloud and Symantec Messaging Gateway customers are protected from these threats.