Cybereason Blog | Cybersecurity News and Analysis

Fauxpersky: CredStealer malware written in AutoHotKey masquerades as Kaspersky Antivirus, spreading through infecting USB drives

Written by Cybereason Nocturnus | Mar 28, 2018 6:32:00 PM

Research by Amit Serper and Chris Black

Attackers are always looking for new ways to execute files on Windows systems. One trick involves using either AutoIT or AutoHotKey, simple tools that allow users to write small programs for all sorts of GUI and keyboard automation tasks on Windows. For example, AutoHotKey (AHK) allows users to write code (in its own scripting language) that interacts with Windows, reads text from Windows and sends keystrokes to other applications, among other tasks. AHK also allows users to create a ‘compiled’ exe with their code in it.

Check out some live webinars on our research.

Now if you’re an attacker reading this, you probably realize that AHK is great to use for writing simple and highly efficient credential stealers. And what do you know? We found a credstealer written with AHK that masquerades as Kaspersky Antivirus and spreads through infected USB drives. We’ve named it Fauxpersky. Let’s have a look at it.

We found four dropped files in a customer’s environment. Each file had a name that was similar to Windows system files:




Suspicious files in our customer's environment

Explorers.exe: Self propagation and persistence

This AHK keylogger utilizes a fairly straightforward method of self propagation to spread. After the initial execution, the keylogger gathers the listed drives on the machine and begins to replicate itself to them. Let’s examine the process:

Gathering the removable drives:

 Collecting the removable drives

Renaming the removable drives:

Renaming the drive

Copying the files to the removable drive:

Copying files to the external drive

This allows the keylogger to spread from a host machine to any connected external drives. If the keylogger is propagating to an external drive, it will rename the drive to match it's naming scheme.

For example, if a machine executed the keylogger while it had an 8GB USB drive called "Pendrive" mounted, the name would be altered after the files completed replicating to match the naming scheme. The USB drive’s new name would be "Pendrive 8GB (Secured by Kaspersky Internet Security 2017)". This is currently a valuable IOC in the wild.

The malware also creates an autorun.inf file that points to a batch script with the following content:

start /d ".\System Volume Information\Kaspersky Internet Security 2017" taskhosts.exe

Analyzing the persistence methods employed in the Explorers.exe component of the malware

Inside explorers.exe there is a function called CheckRPath(), in which the keylogger creates the files if they are not already present on the drive. As you can see in the image above, the files are created according to the passed paths and then set with the attributes “SH” that indicate “System” and “Hidden” respectively by using the FileSetAttrib() AHK function. The keylogger will also create the required directories as needed utilizing the same method with passed parameters of “RSH”, or “Read-Only”, “System” and “Hidden.”

Now that the files have been prepped for creation, it’s time to iterate through all of the necessary components and provide them to the disk. By breaking down the code block below, we can see how this is done.

When starting the process of creating the component files (HideRFiles()) we begin by starting a loop. This loop allows the keylogger to iterate over the various output files it needs to write to disk in a structured way. We can see that the link (a .lnk shourtcut file), text, and batch files will all be created for each disk to start. Then the value passed to the function gets incremented to allow the created directory to be moved as a whole once the files have been placed there. This is a fairly basic way to ensure that all of the files are going to be present when moving the whole directory to its destination. More information on the “FileMove()” and “FileMoveDir()” commands can be found here.

The four files were in a directory called Kaspersky Internet Security 2017. In addition to the executable files, there were two that weren’t executables. One was a file called Logo.png with this image:

The other one was a “Readme.txt” file with these instructions:

If you are unable to launch files/folders correctly, please disable your antivirus program.

Source: https://www.bleepingcomputer.com/forums/t/114351/how-to-temporarily-disable-your-anti-virus-firewall-and-anti-malware-programs/

The Logo.png file is the splash screen displayed when the infected machine logs into Windows to trick the user into thinking Kaspersky is installed and running.

The instructions in the Readme.txt file were followed by a long, alphabetized list of security products that “are incompatible with Kaspersky Internet Security 2017.” Ironically, the list includes Kaspersky Internet Security.

A close inspection reveals that the files are 64-bit Windows PE files. Using IDA Pro to examine the files shows that they are all almost identical. The similarities can be seen by inspecting the mutex creation routines.


One of the xrefs to CreateMutexW() from explorers.exe


xref to CreateMutexW() from svhost.exe

As we can see, the mutex that is created is called “AHK Keybd”. A Google search reveals that this is the standard AHK compiled exe and the actual AHK-language code resides in the RCDATA resource within the resource section of each PE.

To extract the AHK code inside the exe file, Amit wrote a small tool called ahk-dumper that simply iterates over the RCDATA resource inside the PE and prints the content to stdout.

Now that we have a clear way to extract the code from each PE file, we can clearly map which PE file does what:

File name

Purpose

explorers.exe

USB drive propagation

svhost.exe

Keylogging, writing keylogged data to a file (Log.txt)

taskhost.exe

Persistence(?)

spoolsvc.exe

Data exfiltration

 

Analyzing key parts of the AHK code

Svhost.exe - keylogging:

The code in that file is fairly simple. Svhost.exe monitors the focused (currently active) window that a person is in by using the AHK function WinGetActiveTitle() and then calls the AHK input() function, which monitors any user input (in the form of keystrokes) to the window. Each keystroke is then appended to a file called “Log.txt” that will be created and saved inside the “%APPDATA%\Kaspersky Internet Security 2017

The keylogged data will look like this:

Taskhost.exe: Persistence

This part of the code handles persistence. The first step would be to change the CWD of the malware  to %APPDATA% and create a directory called “Kaspersky Internet Security 2017” that’s hard coded.

That file also has another routine (CheckLCore that checks if the files were already created in %APPDATA%:

In case the files were not copied, the malware will copy the files to that location using the FileCopy() function that will be followed by setting the file attributes using the FileSetAttrib() function. As you can see, the first parameter that is passed to this function is “+RSH”, which means Readonly, System and Hidden.

Spoolsvc.exe: Data exfiltration, watchdog and some more persistence

Spoolsvc has several routines inside of it.

Changing the values of registry keys to enable/disable the display of Hidden and SuperHidden files:


As we can see in this screenshot of the code, the malware will edit two keys inside the HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced registry path. The keys that are being changed are:

  • Hidden - value is being changed to “2” which makes the system not to display hidden files.
  • SuperHidden - value is being changed to “0” which makes the system hide system files (which correlates to the “system” attribution that the files received when they were created by the malware)

After the registry value is modified, the malware will check if explorers.exe is already running. If it’s not running, it will be executed. This is a watchdog that was meant to guarantee persistent execution of the malware.

CheckLProcess() will be responsible for checking if all the components of the malware are already running. If they’re not, they will be executed by calling the Run() AHK function and using the Loop/Parse call.

In order to achieve persistence the malware creates shortcuts to itself in the start menu startup directory:

Another very important part of this file (perhaps the most crucial) is the exfiltration of the keylogged data from the Log.txt file to a Google form.

The following diagram illustrates the attack flow:

Exfiltrating data to a Google form is a very simple and clever way to overcome a lot of the “logistics” involved in data exfiltration. Using this technique means there’s no need to maintain an anonymized command and control server plus data transmissions to docs.google.com is encrypted and doesn’t look suspicious in various traffic monitoring solutions.

Google Forms is used for data exfiltration

 

The data is submitted to this form by the following codeblock inside the file. The file will be read into a buffer and deleted from the disk. The buffer will then be sent to the Google form.

Conclusion

This malware is by no means advanced or even very stealthy. Its authors didn’t put any effort into changing even the most trivial things, such as the AHK icon that’s attached to the file. However, this malware is highly efficient at infecting USB drives and collecting data from the keylogger, exfiltrating it through Google Forms and depositing it in the attacker’s inbox. The number of infected machines is unknown, but we’ll update this post if more information becomes available.

Mitigation

We contacted Google and reported the malicious form. Google’s security team took down the form in less than one hour after we reached out to them. If you are infected with the malware, navigate to %appdata%\Roaming\ and remove the Kaspersky Internet Security 2017\ directory, related files should be also removed from the startup directory inside the start menu.

 

Looking .to understand the future of cybersecurity?

Known Hashes

5b983981d565e0606c12b2e94231ac4226fd3b36dcd0ed40dee69d85d2c43b03

6fa2437f224d22127efc81da99f178c6c83408bc6316acae892d76f64879bbb1

3b88c248c18f6180a707cd4b8b5ad33a3482f1cc0405f9d2ff7b976de90c9889

d0dd1ac2b543f408382c138fe27e6192f2f5265426fb3260b16e2273c7fe0dbd

b93bb18f600a637d4d7ffe493e693335065418ea5b07f21dfe4faa78d1bbb418

3872d58bf4aa14680b9f58bfd1efae14fc31fa6605a9ae5ef85a3755309a4173

2acb8d091c2b362bab4f8167378b32c8e05db9b6ba0198fa7fe9abf31d2be16a