AutoIt and Malware: What’s the Connection?

McAfee

Aug 28, 2012

5 MIN READ

During the last couple of weeks I’ve come across three malware samples packed using compiled AutoIt scripts, so I decided to explore the connection between AutoIt and the malware world. I took the latest 50 samples marked as AutoIt that were submitted to the free scanning site VirusTotal.

Here are the statistics:

11 wrongly classified as malware. Four are RAR executables, two are packed with UPX (Ultimate Packer for eXecutables)
36 AutoIt executables
2 AutoIt scripts
1 too well packed for me to easily see if it is AutoIt related

Around 20 of the samples were packed with UPX. (When using AutoIt3Wrapper, UPX compression is on by default.)

After unpacking the UPX (when needed) and filtering the AutoIt executables, I used myAut2Exe, an open-source AutoIt decompiler. One nice thing about myAut2Exe is that you can run it with command-line arguments from a script. I found a number of common AutoIt scripts used to pack or drop different malwares and a couple of full-blown malware written entirely in AutoIt.

Common Types:

7 samples were packed using an obfuscated script that uses x86 code to decode its payload using a buffer and a password which are transferred as parameters. The x86 code is stored as a byte array in the AutoIt script. After decryption, another process of the malware executable is created in a suspended state: The script replaces the segments with the decrypted executable, patches the main thread context, and resumes the thread. The encrypted executable is concatenated to the end of the executable.

The decrypt function reconstructed C code can be seen here.

5 samples were packed using RazorCrypt, an obfuscated script that uses the Microsoft Cryptography API to encrypt its payload. In this case, too, another process of the malware executable is created in a suspended state: The script replaces the segments with the decrypted executable, patches the main thread context, and resumes the thread. The encrypted executable is saved as an AutoIt script attachment and is dropped to disk before decryption and deleted after running the process.

The decrypt function reconstructed C code can be seen here.

5 samples used the utility BaSupportVNC, a legitimate tool. I’m not sure if it was caught by mistake or was it a part of some hacking activity. The tool was written by Biesbroeck Automation of the Netherlands.
2 samples contained AutoIt worms capable of spreading through removable media and Windows shares. They can download malware and send instant messages.
1 sample installed itself and a Bitcoin miner to make money for the originator.
1 sample was an AutoIt-written malware that communicates over TCP with a control server. The script is obfuscated using Obfuscator.
1 sample was an AutoIt-written malware that communicates with a control server using the WinHttp.WinHttpRequest.5.1 object. It is also obfuscated with Obfuscator.
I’ve saved the best for last: When running myAut2Exe on the final sample, the process creates a very small file containing the string “Hacker. Nice try, but Wrong :).” When looking in the file with a hex editor, I noticed (as expected) a second small compiled AutoIt script concatenated to the end of the executable. By deleting this section and rerunning the decompiler, I got the “real” script and a few payloads. The script drops an autoextracting RAR file that contains two executables and a resource directory. One of the executables looks like a patcher/crack for a game; the other is another AutoIt dropper using the same two-scripts technique. This dropper drops two files, again one of them is an AutoIt dropper with the same two-scripts technique that also drops the same file which was dropped previously. The last two AutoIt scripts contain a lot of functionality, including a GUI and an x86-shellcode. The scripts’ messages and comments are in Turkish.

Conclusions

For malware developers:

AutoIt is a very convenient environment for malware and tools development
AutoIt allows both easy interface creation for rapid development and full Windows API access for whatever is not supported directly
The output is a single executable, with no dependencies, that contains a script and attached binaries
AutoIt is very easy to obfuscate. It supports the Execute() function, which lets a code writer use string manipulations and run the resulting string as part of the script.

For us:

AutoIt is easy to decompile. Even with the multiple scripts example, the open-source decompiler can easily be extended to support multiple scripts.
Most obfuscation techniques can be overcome using a short script.
Because AutoIt is a scripting language, eventually after deobfuscation we have a script with a lot of meaningful strings that can be reverse-engineered easily (with AutoIt functions and the Windows API in clear text).

Python scripts from the research:

Restore Strings:A common method of simple AutoIt obfuscation uses a binary hex string instead of clear text. The Execute(BinaryToString(“0x2030783130303037”)) script converts them back to strings.
AutoIt Deobfuscator: AutoIt Obfuscator moves the strings from a script to a table in a separate file. Its content is loaded from the file to a table. Then the script runs and loads strings from the table to variables at each function.