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.
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:
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).
Second, if you inspect the version information for this file within PEStudio, you will see multiple references to AutoIt (medium fidelity)(Figure 3).
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 shows that the hash for WinddowsUpdater.exe matches the hash of AutoIt3.exe (v18.104.22.168 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 WinddowsUpdater.zip, 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.
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).
All of these shortcuts, when executed, will run the following command:
C:\Windows\system32\cmd.exe /c start ..\WinddowsUpdateCheck\WinddowsUpdater.exe “..\WinddowsUpdateCheck\WinddowsUpdater.zip” & exit
As expected, the malicious code is executed by passing in the compiled AutoIt Script (WinddowsUpdater.zip) 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.
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.
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).
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 v22.214.171.124 – v126.96.36.199.
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).
Here, we select the compiled script (i.e. WinddowsUpdater.zip) 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).
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…
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)
… 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.