AutoIt and Malware: What’s the Connection?

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.