AuKill EDR killer malware abuses Process Explorer driver

Threat actors increasingly have been relying on abusable drivers to disable security tools.
Drivers are low-level system components that can access critical security structures in kernel memory.
As a security mechanism, Windows by default employs a feature called Driver Signature Enforcement that ensures kernel-mode drivers have been signed by a valid code signing authority before Windows will permit them to run.
This signature serves as a sign of trust to verify the identity of the software and to protect a user’s system.

To get around this security measure, adversaries need to either contrive a way to get a malicious driver signed by a trusted certificate.

In this case, the attackers took advantage of a driver both created by and signed by Microsoft.
The Process Explorer driver, part of their suite of administration tools produced by the Sysinternals team, implements a variety of features to interact with running processes.

AuKill drops a driver named PROCEXP.SYS (from the release version 16.32 of process Explorer) into the C:WindowsSystem32drivers path.
The legitimate Process Explorer driver is named PROCEXP152.sys, and normally is found in the same location.
Both drivers can be present on a machine that has a copy of Process Explorer running.
The AuKill installer also drops an executable copy of itself to either the System32 or the TEMP directory, which it runs as a service.

For example, the driver can receive the IO control code IOCTL_CLOSE_HANDLE from user-mode applications, which commands the driver to close a protected process handle, resulting in terminating a process.

Abusing this process requires the attacker to use administrative privileges on the system.
Normally, when an attacker obtains administrative privileges, it means that they have full control over the machine.

However, critical processes on Windows, such as endpoint clients, are under additional protection features to prevent attackers from disabling them once they escalate privileges.
An example of an additional protection feature is the Protected Antimalware Services concept introduced in Windows 8.1.

To circumvent such features, attackers need to go one level deeper – to run a driver in kernel-mode.
In this case, AuKill abuses the legitimate driver behind Process Explorer to overcome these features.

The AuKill tool requires administrative privileges to work, but it cannot give the attacker those privileges.
The threat actors using AuKill took advantage of existing privileges during the attacks, when they gained them through other means.

When executed, the malware first checks if it has administrator privileges.
It also requires that the attacker runs the file with a keyword (or password) as the first argument on the command line.
The execution aborts if either of these requirements are not fulfilled.
(The attacker needs to acquire administrative rights before they can run the tool.)

For both samples covered in this analysis section (and all six samples listed in the IOCs), attackers need to pass the string startkey as the first command line argument.

The malware validates the password/keyword using a simple arithmetic sum calculation.
It iterates a process where it derives the decimal value of the ASCII code for each character, doubles the value, then adds it to the next character’s decimal value, which is then doubled, and so on.

After the calculation is finished, the sum result is returned and compared against a hardcoded expected value, in this case 57502 (represented as the hexadecimal value 0xE09E).

If the sample does not run with SYSTEM privileges, it continues by attempting to elevate its rights by impersonating the security context of TrustedInstaller.exe.

First, AuKill starts the Trusted Installer service.
Then it duplicates the token of TrustedInstaller.exe using the DuplicateTokenW WINAPI function, and passes the token to CreateProcessWithTokenW to elevate itself to SYSTEM once the process restarts.

Finally, it copies itself to C:Windowssystem32, installs itself as a service, and starts the service.

Once the malware establishes persistence by creating the service entry, it drops procexp.sys onto disk.
The driver is embedded in AuKill as a resource.
Both versions covered in this analysis drop procexp.sys into C:WindowsSystem32drivers.
Notably, the debug version also tries to connect to a driver named WindowsKernelExplorer.sys as a fallback, in case it fails to drop and load procexp.sys.
However, the fallback driver is not embedded in the resources like procexp.sys.
It expects that this driver, part of, already exists in the System32drivers folder.

An EDR client usually consists of multiple components that work in conjunction.
A component could be (for example) an installed service or running process, each with its own functionality.
Therefore, if one crashes or terminates, it usually restarts as soon as possible.

To prevent these components from restarting, AuKill starts several threads to ensure that these EDR processes and services stay disabled.
Each thread targets a different component and continuously probes if the targeted processes or services are running.
If any of them are, AuKill disables or terminates it.