Site icon Secplicity – Security Simplified

AutoIt Malware: To obfuscate, or not to obfuscate

Abdul Samee

What is malware? Its goal is to bypass computer defenses, infect a target, and often remain on the system if possible. A variety of evasion techniques depend on a mix between the skill of the author and the defenses of the intended victim. One of the most widely used tactics in malware is obfuscation. Obfuscation comes in the form of packers, crypters, and string manipulation, and when used effectively, it can greatly increase the time and resources needed to analyze a sample and identify the threat.

Typically,  many malware threats are written in scripting languages and compiled with the runtime into an executable. While PowerShell and Python malware continues to make their rounds, another popular malware development language is AutoIt. AutoIt is a scripting language that is legitimately used for automating the Windows Graphical User Interface (GUI) and basic tasks. But threat actors are also using the AutoIt framework to bypass antivirus detection with obfuscated threats. 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.

Here is an analysis of an AutoIT script we recently detected. This file drops a BitPaymer ransomware variant. As will be seen in the analysis, it is heavily obfuscated using gibberish variables and function names, garbage code, predefined switch-case operations, and obfuscating much of the code in a Unicode array obfuscated by a trivial algorithm. After de-obfuscating the code in Notepad++, which minimizes code blocks, this builds the malware from scratch and drops the malware on unsuspecting victims. Albeit, not before it performs a few checks not to infect the malware authors.

Analyzing the AutoIt Script: From Compiled Binary to Plain-Text Script

Recently I came across some sample files for malware detection and reverse engineering.  Since these files are malicious, it is best to open it in an isolated infection network. Here is an example of how WatchGuard Panda AD360 detects one AutoIt script I analyzed.

This confirmed the file was suspicious! Subsequently, I used an isolated network for further analysis.

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.

Decompiling

Using AutoIt decompile, we can now start to extract and analyze the .au3 file.

Open the file, and we can see, the malicious script is obfuscated.

During our analysis, we found some interesting data inside of the malicious AutoIt script that we scrutinized to understand how it works.

The hexadecimal characters are not in the proper position; that’s why if you try to convert it to ASCII the result is improper. One thing to note,  one of the functions creates another file from scratch using raw hex values. It creates a different file if the AutoIT script is in a 64-bit environment or a 32-bit environment.

What better way to circumvent their attempts to make analysis difficult than by writing our own script to DE obfuscate the code into something more readable.
The answer was this regex:  (r’PIkUFK\(\”([0-9.]*)\”,([0-9])\)’)

Using search and replace, we used the following regular expression to remove bits of code.

Finally had to remove all LF/CR.

Below we can see a differentiation – the first image is fully obfuscated, and the second image shows clear text after deobfuscated function running through PIkUFK function.

AutoIt scripts use tricks and check files and computer names in the system to avoid detection from antimalware engines. It also checks API GetTickCount to detect the sandbox emulation. Further, the script checks the domain “OJtmGmql.OJtmGmql” and exits if the domain is alive. If these random passes, it injects the shellcode.

Additionally, the code injects the shellcode into the memory and creates a mutex first with the name of ‘JFTZRATSJPATTZLFCUTTH,’ it gets the decrypted PE file, injects it, and executes it. Finally, the payload is decrypted and run in the memory not to get captured by the antivirus.

Conclusion

The outcome was to come up with the final flow of what the obfuscated code does. The set of code after this function isn’t a function at all, which means it’s likely the de-facto “main” function. So, the behavior will be described line-by-line:

  1. Check if the computer name is “DESKTOP-Qo5QU33”, “NfZtFbPfH”, “tz”, or “ELICZ”. If it is, then the script terminates. These names are used by AV emulators.
  1. Checks if a file named “C:\aaa_TouchMeNot_.txt” exists and if it does, terminate.
    • The first 5 lines are essentially killing switches. The authors likely used these to test the script and not infect themselves. If you have those computer names or that file, you are basically immune from this specific
  2. Copies the original filename to another filename.
  3. Makes a DLLCall to Kernel32.dll and sets the Error Mode to 8006, which equals:
  1. It also performs the ping operation and terminates the script after a successful run
  2. It ends by running the script and calling the timing function again.

Obfuscated malware like these AutoIt scripts show why advanced endpoint protection services are so important. It’s easier than ever for threat actors to create evasive payloads that get past traditional signature-based tools and launch fileless attacks by injecting code into the memory of other processes.

Exit mobile version