Threat actors are always looking for a way to execute files on a victim machine and stay undetected. One way involves using a scripting language that has no built-in compiler within a victim’s operating system, and which can’t be executed without its compiler or interpreter. Python, AutoIT, and AutoHotkey (AHK) are some examples of such a scripting language. In particular, AHK is an open-source scripting language for Windows that aims to provide easy keyboard shortcuts or hotkeys, fast micro-creation, and software automation. AHK also allows users to create a “compiled” .EXE with their code in it.
In mid-December, we discovered a campaign that distributed a credential stealer. We also learned that the main code components of this campaign is written in AHK. By tracking the campaign components, we found out that its activity has been occurring since early 2020. The malware infection consists of multiple stages that start with a malicious Excel file. In turn, this file contains an AHK script compiler executable, a malicious AHK script file, and a Visual Basic for Applications (VBA) AutoOpen macro. The full attack chain is depicted in Figure 1. Our telemetry tracked the malware’s command-and-control (C&C) servers and determined that these come from the US, the Netherlands, and Sweden. We also learned that the malware has been targeting financial institutions in the US and Canada.
The dropped adb.exe and adb.ahk play critical roles in this infection. The adb.exe is a legitimate portable AHK script compiler, and its job is to compile and execute the AHK script at a given path. By default (with no parameter), this executable executes a script with the same name in the same directory. The dropped AHK script is a downloader client that is responsible for achieving persistence, profiling victims, and downloading and executing the AHK script on a victim system.
For persistence, the downloader client creates an autorun link for adb.exe in the startup folder. This portable compiler is used to compile and execute the AHK script. By default (with no passing parameter), this executable executes an AHK script with the same name in the same directory which is in this case adb.ahk.
The script profiles each user by generating a unique ID for each victim based on the volume serial number of the C drive. The malware then goes through an infinite loop and starts to send an HTTP GET request every five seconds with the generated ID. This ID serves as the request path to its command-and-control (C&C) server to retrieve and execute the AHK script on an infected system.
For command execution, the malware accepts various AHK scripts for different tasks per victim and executes these using the same C&C URL (instead of implementing all modules in one file and accepting the command to execute them). By doing this, the attacker can decide to upload a specific script to achieve customized tasks for each user or group of users. This also prevents the main components from being revealed publicly, specifically to other researchers or to sandboxes. In fact, though we noticed that this attack started as early as the beginning of 2020, still not a single command had been discovered by sandboxes. This suggests that either the attack selects when to actually send the commands to the infected victim machine, or the rapid change of the C&C server has made it difficult to track. So far, we have discovered five C&C servers and only two commands: deletecookies and passwords.
Among the downloaded components by the downloader client, we observed a stealer written in AHK. This script is responsible for harvesting credentials from various browsers and exfiltrating them to the attacker. It is worth noting that a variant of this stealer targets specific websites. Among them are major Canadian banks, as evident in Figure 2.
An interesting aspect is that the AHK delivered scripts containing instructions in Russian on how to use the scripts. This suggests that a “hack-for-hire” group is behind the attack chain’s creation. The following sections will describe the details of the attack chain shown in Figure 1.
Analysis of malicious components
If the user enables the macros to open the Excel file, VBA AutoOpen macro will drop and execute the AHK downloader client script via a portable AHK script compiler.
The dropped portable AHK script compiler, adb.exe, by default executes the AHK script with the same name in the same directory. In this case, adb.exe automatically detects and executes the adb.ahk script.
As aforementioned, adb.ahk is a downloader client that is responsible for persistence, profiling victims, and downloading and executing AHK scripts in a victim system continuously every five seconds. The malware sends an HTTP GET request to its C&C server in order to download and execute the AHK script in an infected machine.
The response from the server saves into the file called adb.exe~ (adb.exe~ is in AHK plain-text script; it is not an executable file). The HTTP GET request path in Figure 5 is a victim’s unique ID that has the following format:
<C Drive volume serial number >-xl2
It is important to note that in some other variants “-xl2” is replaced with “-pro”. Before adb.ahk executes the downloaded AHK script(s), it first checks if the specific character (“~”) exists at the very end of the file. If the character is found, then it proceeds with the execution.
Moreover, the malware creates an autorun link to the adb.exe AHK script compiler called “GraphicsPerfSvc.lnk” in the startup folder. As mentioned previously, the compiler, by default, executes an AHK script with the same name and directory.
One of the scripts downloaded by the downloader client is a browser credential stealer. In the following section, we look into the implementation, features, and network communication of this malicious script.
Upon successful execution, the malware sends a status log (“passwords: load”) to its C&C server via an HTTP POST request:
As with adb.ahk, this script also generates a unique ID for its victims based on the volume serial number of the C drive. The generated unique victim ID is then used to track infections and remains the same at all times for each victim.
The stealer then attempts to download “sqlite3.dll” on a victim machine. The malware uses this DLL to perform SQL queries against the SQLite databases within browsers’ app folders.
From the above snippet, we can observe that the malware retrieves the volume serial number of the C drive again and searches for two hard-coded serial numbers, 605109072 and 605109072. These two serial numbers have been used for debugging purposes and upon exiting, the script displays the SendLog() function argument in the message box. Notably, this debugging technique has also been seen in various functions in this script.
It is worth noting that the malware author uses the following open-source code to handle the SQLite database with AHK.
The main purpose of this malware is to steal credentials from various browsers such as Microsoft Edge, Google Chrome, Opera, Firefox, and Internet Explorer (IE). To achieve this task, the malware uses the following functions:
The following charts demonstrate the preceding functions:
The malware identifies the browsers that are installed in a victim machine and reports its findings to its C&C server via SendLog () function. If the targeted browser is not installed, the malware labels it as “not_found”:
On the other hand, if the targeted browser is in the victim machine, the malware labels it as “_ok”, as seen in the following image:
The following snippet demonstrates how the malware searches for the login data of Chrome, Edge, and Opera.
For the Internet Explorer password stealer, the author borrowed some codes from an open-source IE password information stealer and converted them to AHK.
Finally, the malware sends the collected credentials from installed browsers on the victim machine to the attacker via an HTTP POST request. It is worth noting that for each browser, the malware attempts to decrypt the credentials and sends these to the C&C as plain text.
Another interesting thing about this campaign is that the downloaded components are very well organized at the code level. These downloaded components also have usage instructions in a comment format for the main functions and variables. This behavior, therefore, could indicate that this code is intended for use not only of its author, but also by others as a service or a standalone instance.
Summary of the routine
The malware infection consists of multiple stages that start with a malicious Excel file. If the user enables the macros to open the Excel file, VBA AutoOpen macro will then drop and execute the downloader client script via a legitimate portable AHK script compiler. The downloader client is responsible for achieving persistence, profiling victims, and downloading and executing AHK script in a victim system. Instead of receiving commands from the C&C server, the malware downloads and executes the AHK script for different tasks. The downloaded script is a stealer that targets various browsers such as Google Chrome, Opera, Edge, and more. The stealer collects and decrypts credentials from browsers and exfiltrates the information to the attacker’s server via an HTTP POST request.
Indeed, by using a scripting language that lacks a built-in compiler within a victim’s operating system, loading malicious components to achieve various tasks separately, and changing the C&C server frequently, the attacker has been able to hide their intention from sandboxes.
Indicators of compromise (IOCs)