AutoIt Malware: From Compiled Binary to Plain-Text Script

AutoIt is yet-another-development-language that malware authors leverage to create and obfuscate their malware. As a matter of fact, AutoIt is so closely associated with malware, that AutoIT’s website has a wiki article that “addresses” the fact that the legitimate AutoIt binary is often detected as malicious by AntiVirus.

In this post, I will not be going into end-to-end analysis of any one sample. Unfortunately, there are way too many different ways that malware authors have leveraged AutoIt for me to write a one-analysis-fits-all post. I will, however, attempt to provide you with a starting point by showing you how to get from a compiled AutoIt binary to a plain-text script.

AutoIT Compile Options

One of the first things that you’ll need to understand is that AutoIt provides its users with two different compile options: either a compiled script or a standalone executable.

Compiled Script

With the compiled script, the malicious payload will be presented as at least two files: one being the compiled script and the other being a legitimate AutoIt Interpreter. Here is an example of one such malicious sample:

Figure 1: AutoIt Interpreter and compiled script sample

In Figure 1, WinddowsUpdater.exe is the legitimate AutoIt interpreter that was simply renamed by the miscreant to hide the executable’s true identity. The first sign that is the case is the icon for the file, which is the AutoIt icon (extremely low fidelity)(Figure 2).

Figure 2: AutoIt icon

Second, if you inspect the version information for this file within PEStudio, you will see multiple references to AutoIt (medium fidelity)(Figure 3).

Figure 3: Legitimate AutoIt Interpreter version information shown in PeStudio

Third, you can compare the hash of the file in question to the hash of the actual AutoIt3.exe executable hosted on AutoIt’s website (extremely high fidelity).

Figure 4: Hash comparison between exe packaged with malicious payload and exe from AutoIt’s website

Figure 4 shows that the hash for WinddowsUpdater.exe matches the hash of AutoIt3.exe (v3.3.14.2 as specified in Figure 3) which was downloaded directly from the developer’s website.

The AutoIt interpreter, by itself, is benign. In order for it to facilitate malicious code execution, the interpreter must be fed a script. In the example provided in Figure 1, this would be, which is not actually a compressed archive, but rather a compiled AutoIt script. The script’s file extension is insignificant and can be set to whatever one feels like. The contents of this particular script is shown in Figure 5.

Figure 5: Contents of compiled AutoIt script

We can see how this malware is executed by inspecting the specified targets of the shortcut files also present within the same directory (Figure 6).

Figure 6: Shortcuts leading to the execution of the compiled AutoIt script

All of these shortcuts, when executed, will run the following command:

C:\Windows\system32\cmd.exe /c start ..\WinddowsUpdateCheck\WinddowsUpdater.exe “..\WinddowsUpdateCheck\” & exit

As expected, the malicious code is executed by passing in the compiled AutoIt Script ( to the AutoIt interpreter (WinddowsUpdater.exe) as its argument. Note that the method for getting the unsuspecting victim to execute the malicious AutoIt payload will likely differ between samples. This is just how this particular miscreant decided to trick the victim into running their malware.

Standalone Executable

With the standalone executable, the malicious payload will be presented as a single .exe file (Figure 7), which is actually an AutoIt Interpreter with the compiled script embedded into it as a resource.

Figure 7: Figure 1: AutoIt standalone executable sample

Because the script is embedded, you will not be able to use the file’s hash to verify that the executable is a legitimate AutoIt binary, as discussed in the previous section.

You are, however, able to determine whether or not the executable you are dealing with is an AutoIt standalone executable by analyzing it with something like PeStudio and looking for an AutoIt overlay, manifest, and/or strings (Figure 8 and 9).

Figure 8: Manifest/overlay information for the AutoIt standalone executable
Figure 9: AutoIt-related strings found within the AutoIt standalone executable


Could we simply load a sample, with either compiled option, into a debugger like OllyDBG and step through the code in order to determine it’s functionality?… Sure! But if we are able to obtain the original plain-text code by decompiling the binary, it will enable us to expedite our analysis, analyze coding characteristics in an effort to identify code sharing and/or actor/campaign tracking, etc…

Bottom line, any time you have the opportunity to obtain and analyze the original source code, you take it!

So how do we get from a compiled binary to the original plain-text script?


Exe2Aut is an application that enables simple drag-and-drop decompilation of compiled AutoIt scripts. The most recent revision that I could find is v0.10, which claims to support AutoIt v3.2.6.0 – v3.3.11.2.

Figure 10: Exe2Aut’s simple user interface

If you are dealing with a compiled script, simply drag-and-drop the AutoIt Interpreter executable (i.e. WinddowsUpdater.exe) into Exe2Aut (Figure 10). You will be immediately presented with a “Run Script” prompt (Figure 11).

Figure 11: Run Script prompt received when you drag-and-drop the AutoIt Interpreter

Here, we select the compiled script (i.e. and click Open.

Almost instantaneously, the decompiled source code is displayed in the application (Figure 12) and the plain-text script is dumped to disk as a .au3 file (Figure 13).

Figure 12: Decompiled AutoIt script shown within Exe2Aut
Figure 13: Decompiled AutoIt script automatically saved to disk

It’s even easier to decompile a standalone executable using Exe2Aut as the compiled script is embedded within it; thus no additional prompt asking you to select the compiled script.

Drag. Drop. Decompile!

Decompiled Script Analysis

More often than not, the decompiled script will be heavily obfuscated. Depending on the complexity, you could attempt to manually deobfuscate the script by replacing variable names, manually concatenating values, etc…

There are also a couple of options for debugging (Link1 / Link2) but they all seem experimental at best.

If the script is overly obfuscated/complex, at a minimum you can use the elements identified in the source code to augment your analysis of the original executable within a debugger (like OllyDbg).

For instance, if we see the following within the decompiled source code…

Local $hdll = DllOpen("kernel32.dll")
Local $aprocesshandle = DllCall($hdll, "int", "OpenProcess", "int", 1024, "int", False, "int", $i_pid)
DllCall($hdll, "int", "CloseHandle", "int", $aprocesshandle[0])

… we know that the compiled binary will be making a CALL to Kernel32.OpenProcess. So, when analyzing the compiled binary within a debugger, we now know to set a breakpoint on this function that we find interesting.



One thought on “AutoIt Malware: From Compiled Binary to Plain-Text Script

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s