This week a captured AutoIT malware got our attention. It happened that we had some experience with AutoIT scripts, thanks to Fireeye Flare-On 7 (2020) challenge #6 (CodeIT), but never had the chance to analyze a real scenario.
In this small post, the process followed during the analysis, will be presented.
What is AutoIT?
Quoting AutoIT web site
AutoIt v3 is a freeware BASIC-like scripting language designed for automating the Windows GUI and general scripting. It uses a combination of simulated keystrokes, mouse movement and window/control manipulation in order to automate tasks in a way not possible or reliable with other languages (e.g. VBScript and SendKeys). AutoIt is also very small, self-contained and will run on all versions of Windows out-of-the-box with no annoying “runtimes” required!
The analyzed sample is the SKBMT 27 JAN 2020 at 1.60_PP3343_PDF.exe with hash 395d07278754f8b029b2ef74c7b65da1860de898014babbfb574b45f7ac1b8d6. The sample has a very high detection rate in VirusTotal. The goal was to identify the type of malware given that VirusTotal provided a very vague description.
Initially, using Detect It Easy, it was identified that the sample is a self extracting executable consisting of three files:
- auokpnflym.exe the embedded AutoIT interpreter
- kypipza.lv the AutoIT script passed as parameter to the interpreter
- nsiowtaau.aq a binary file containing random data (more later on)
Deobfuscating the AutoIT script
As expected, the AutoIT script is obfuscated. The one and only obfuscation method used, is an integer-to-char conversion based on subtraction of values.
In order to clean things up a small python script was written, replacing the $Mchr operations with the actual characters
The cleaned up version of the script is the following:
The most interesting element of the script is the variable $V35jildc. The first byte of the script (0xE9) could refer to JMP opcode, therefore this byte array could be some kind of shellcode (which apparently is).
The script allocates the necessary space for the shellcode. Then creates a struct via DllStructCreate with parameter the pointer of the allocated space. The actual shellcode is copied to the newly allocated address by the DllStructSetData. Finally, the DllCallAddress calls the shellcode and passes as a parameter the path of the nsiowtaau.aq file. Our guess is that this file is the actual malware and the shellcode is responsible for the decryption
The shellcode is pretty straight forward to be analyzed. It uses regular dynamic API resolution as well as dynamic PE loading. However, the most important functionality is the decryption of the nsiowtaau.aq. The shellcode tries to open and read the file (passed as an argument) which in our case is nsiowtaau.aq.
The buffer with the read data is then passed to the decryption function. The function is very similar to RC4 (but it is not RC4; if anyone knows what algorithm is please let us know) and uses as a password a static string
In order to decrypt the malware and being lazy enough to reimplement the decryption algorithm, the dynamic analysis approach was chosen. The shellcode was converted to PE with the use of Yasm (more info here). Having a runnable executable, the shellcode could dynamically be debugged. With a few tricks in order to specify the path of nsiowtaau.aq the file was decrypted and we got a new PE executable.
Remember, the shellcode is being called with an argument, specifying the path of the file to be decrypted. By simply converting the shellcode to PE, resulted the argument to have an arbitrary — unspecified value. Therefore, we found a suitable memory address, wrote the file path and then changed the stack value pointing to our path instead of a random value.
Back to the new binary. IDA shows that the binary tries to load a resource.
By observing the resources of the binary we identified that there is another executable.