AutoHotKey – hot to go, it’s ready
Malware is always on the move to avoid detection. While the specifics vary, the basic objective is to find an attack surface that isn’t closely controlled by security companies. A recent trend from the bad guys is to use scripting languages such as AutoHotKey.
Welcome to AutoHotKey
AHK is a free, open-source scripting language for Windows that allows users to create scripts for all kinds of tasks such as form fillers, auto-clicking, and now malware packages. AHK is being used to create these malware types:
- Simple-downloaders –Trojans for downloading and starting the execution of malware.
- Tricky-downloaders – (Fingerprinting): Fingerprints the system before downloading and executing the malware.
- Stealer – Keystroke stealer with worm-like spreading ability
- Fileless malware –Executes malware payloads in memory without them being saved to disk.
As with many scripting languages, AHK script can also be converted into standalone executables. Usually scripts are stored in the resource section with resource names like “>AUTOHOTKEY SCRIPT<” or “>AHK WITH ICON<”. To compile into standalone executable, there are official tools available at page from AutoHotKey. As the below chart shows, it is becoming more popular.
Here is a more detailed list of the various types of malware which are being created with AHK and some of the technical details:
We observed that in the early usage of AHK by malware authors, it was for developing simple Trojan downloaders. Then the objective was also simple – to download and execute malware. Usually to achieve this, the malware used a certain set of AHK commands. We’ve only listed the commands here which have been used by malware, and give a short explanation here of what these commands do in more detail.
UrlDownloadToFile – This is a straightforward AHK command, which downloads files from the internet and stores them on disk.
Run – This command is clubbed together UrlDownloadtoFile, its purpose is to simply start a Windows executable.
The objective of Tricky-Downloaders is similar to that of a Simple-Downloader, but we have observed that this kind of malware does a fingerprint of the system before downloading and executing the malware. To download the malware, it may use the already mentioned commands in a simple downloader, but it can also use the below command,
Command ComObjError(False), will disable notifications from COM errors, to avoid alerting the user in case of malfunctions. A_Is64bitOS is a prepopulated value by AHK which indicates details about the system architecture .
Malware authors have started leveraging more power of AHK in developing stealers with spreading capabilities. Usually AHK can be used to monitor keystrokes for triggering events, this ability has become helpful for malware authors in developing keylogging stealers. One example of this is the AHK command input, whose legit purpose is to store the user input into a variable and later compare these strings for trigger functions.
The stealer actively monitors the window name by using WinGetActiveTitle and comparing it to popular social media sites and payment pages.
Here we need to notice that arguments are passed to input AHK command , especially the third one “V” , which normally means the user’s input is blocked (hidden from the system). This option is used to have the user’s keystrokes sent to the active window.
This stealer was also designed to spread itself like a worm, both in local drives and on networks
Here malware authors have used the AHK command DriveGet, the function checks if it is already copied to disk and if not, it copies itself every few seconds. This function is called so that it can get copied to external thumb drives too.
Here the stealer tries to list all network shares from the same domain as the victim machine and tries to copy this to the startup folder. For example, constructing the remote startup folder path AHK prepopulated with variable A_Startup and RegExReplace comes in handy here.
Stealer’s upload function is similar to the one we discussed earlier in Tricky Downloader which is based on COM object WinHttp.WinHttpRequest.5.1.
Malware authors are extending their run in creating AHK malware, but this time with fileless capabilities. They are not trying any new fileless techniques, but are rather implementing an existing one using AHK. The one we observed was the CallWindowProc version of fileless technique.
A similar method was observed earlier in other developing platforms.
Figure 7: Fileless technique where payload is hardcoded in file
Figure 8: Fileless technique with payload is stored on the web
Here the payload is stored as a base64 string in a url pointing to a picture, which the AHK malware downloads into memory, decodes it using a custom Base64Decode function, and executes it in memory.
To achieve this, malware authors have leveraged the AHK command DllCall. We expect this command’s exploitation by malware to increase in frequency as it can call Windows API functions directly without importing them earlier.
From the source code it is clear malware has abused the CallWindowProcW API internally. The CallWindowProcW method calls the first parameter passed to it, which in this case is a pointer to decoded shellcode.
From just the parameters itself, it is suspicious, especially the second parameter. As per the documentation, there should be a handle, but here they are passing a String, which is actually the path to the file which will be hollowed later. The Shellcode, which is passed as the first parameter, is responsible for hollowing the process.
API’s which are resolved by the shellcode are well known API’s used for process hollowing. Below is a list of the APIs that get resolved:
Makes life harder:
String obfuscation is a well-known technique in script-based malware and AHK malware authors are not shying away from doing it. We mainly observe two types of string obfuscations used by AHK malware.
Breaking the important strings like API names and concatenating them in runtime is one type. The primary objective here is to break string-based detections
The second one is using an opensource AHK Obfuscator designed for protecting source code. It offers several functionalities to make the source code unreadable to anyone.
The range of how AHK can be misused is rather wide. And, as the graph shows, the use of AHK is low – but growing steadily. Our analysis shows that these techniques can and will be used in a variety of ways by the bad guys. Security companies need to be aware of them and keep an eye open for variations.