back

Dissecting an AutoIT Malware Sample

This post outlines a systematic breakdown of a malware sample developed using AutoIT, highlighting techniques used for unpacking and analysis.

Stage 1: De-obfuscating the Batch Script

The initial stage of the infection chain involves a heavily obfuscated batch script. The de-obfuscation process included:

• Removing non-functional lines that do not contain executable batch commands such as set, cmd, and findstr.
• Replacing randomized variable names with their corresponding values defined by set commands.
• Stripping % characters from substituted variables to normalize the syntax.

Obfuscated Script:

De-obfuscated Script:

Observations:

• The script performs checks for several antivirus products (Avast, AVG, Norton, Sophos). If none are found running, it renames and prepares AutoIT executables and scripts for execution.
• Additionally, if Webroot SecureAnywhere is not detected, the script executes a loop that sends 210 ICMP echo requests (ping) to localhost.
• According to the execution flow diagram, various components are merged to create the payload:
  • The files “Tractor,” “Standard,” “Feb,” “Disclaimer,” “Demonstration,” and “Convertible” are compiled into the main AutoIT executable.
  • “Experiment,” “Dependent,” and “Dramatic” form the obfuscated AutoIT script.

Stage 2: Analyzing the Obfuscated AutoIT Script

Pre-Deobfuscation View:

The script includes multiple calls to a function labeled Spyware

String De-obfuscation Logic:

The function takes an encoded string and splits it using % as a delimiter. Each segment is adjusted based on a key and then converted into corresponding Unicode characters.

Resulting Output:

The decoded strings in this instance appear to be junk or placeholders, suggesting the use of decoy or filler code.

Stage 3: Embedded Binary Extraction

An embedded binary blob is found assigned to a variable (pNseF) within the script:

This blob is passed to a custom function named Nickpot.

Stage 4: Investigating the Nickpot Function

Within Nickpot, another binary blob labeled ConnectionsEquality appears. Its value changes based on whether a 32-bit or 64-bit environment is detected. The focus here is on the 64-bit version:

Decompilation reveals that ConnectionsEquality implements a form of custom encryption or decryption routine:

Tracing Usage:

• The blob is copied into a variable named hiltonfinalsdirectories.
• This is subsequently used in a call to DllCallAddress, with structured parameters being passed:
  • QualifiedRefugeesCattle – An empty 272-byte structure.
  • DETAILWITNESS – The content in strapthumbgeniusroll
  • TreatmentsPicked – The length of strapthumbgeniusroll

To conclude, the function ConnectionsEquality sets the data of QualifiedRefugeesCattle depending on the value of DETAILWITNESS.

Tracking the Usage of QualifiedRefugeesCattle

The decrypted structure, QualifiedRefugeesCattle, is subsequently used as the first argument in another call to DllCallAddress. This time, the function receives two additional arguments:

• DETAILWITNESS2 – Contains the original blob passed to the Nickpot function.
• TreatmentsPicked2 – Represents the length of that blob.

In this step, DETAILWITNESS2 is updated or transformed based on the decrypted data from QualifiedRefugeesCattle. This suggests a two-step decryption or decoding routine, possibly for layered obfuscation or added evasion.

Final Return From Nickpot

The function MarcoCindy is invoked at the end of Nickpot, serving a simple role: it returns the contents of DETAILWITNESS2 as a fully populated data structure.

Final Stage: Decompression via FishVerzeichnisBobby

The returned data (now referred to as SquirtingNcaaTnAj) is passed into the function FishVerzeichnisBobby, which prepares the buffer for decompression.

Within this function:

• The data is inserted into a structure named elegantacknowledge.
• This structure is passed to the Windows native API function RtlDecompressFragment.

According to Microsoft’s MSDN documentation, RtlDecompressFragment decompresses a portion of an input buffer into a destination buffer.

Final Payload Extraction

The result of the decompression is stored in a buffer named transmissionsetpromptlylab. By dumping the contents of this variable, we recover a valid Portable Executable (PE) file:

• SHA-1 Hash: b5c8cf1839ae8454711885fa8116df0c2252dc6f
• Threat Identified: The PE is flagged by Windows Defender as LummaStealer, a well-known credential-stealing malware.

Conclusion

This AutoIT-based malware employs a multi-layered obfuscation and unpacking technique:

1. Obfuscated Batch Loader – Prepares the environment and drops the AutoIT payload.
2. AutoIT Script – Implements custom string decryption, binary merging, and memory-based loading.
3. Custom Decryption Routine (Nickpot) – Decrypts an embedded blob using shellcode-style logic.
4. Final Decompression via Native API – Extracts the final PE using RtlDecompressFragment.

By reversing these layers, we uncover a known infostealer embedded deeply within custom logic to evade traditional detection methods.