The introduction

Welcome back!.. hope you’re having a nice time :)

“We often trust our security software to stand as an unbreakable wall against malware and attacks, but what happens when that very wall is weaponized against us?”

In this blog, we’ll analyse a malware and learn along the way, which was found in a recent discovery by Trellix Advanced Research Center ¹² that reveals a malware campaign that weaponizes a legitimate Avast Anti-Rootkit driver(aswArPot.sys) to bypass security measures.

The malware exploits or manipulates the driver’s kernel level access to disable and terminate security processes, and take control of the infected system. This campaign is good enough example of often used BYOVD(Bring Your Own Vulnerable Driver) attack which focuses on exploiting legitimate but vulnerable drivers to gain kernel-level access to bypass the antivirus and EDR solution.

“What a good way to bypass the security vendors is to terminate them right away”

Such behavior is lethal and sinister as it straight up terminates the security vendors process. Let’s get into the technicals of this malware.

The infection chain

The infection chain starts with malware kill-floor.exe that is a PE64 console application that drops an embedded legitimate and trusted Avast Anti-Rootkit Kernel Driver (aswArPot.sys).

Once dropped, the malware creates a service that points to this driver and deploys right away using windows utility Service Control (sc.exe), then enters an endless loop of fetching the security vendor processes running on infected system and instructing the kernel driver to eliminate them using an IOCTL code specific to this driver, all happening silently under the trust of this legitimate driver raising no alarms.

Laying the foundation

The malware starts off by defining following 142 hardcoded process names of well-known antivirus and EDR solutions to compare against running processes of infected system down the line:

then initiates the plot by dropping the legitimate Avast Anti-Rootkit kernel driver disguised as ntfs.bin in the C:\Users\Default\AppData\Local\Microsoft\Windows directory, that is stored at offset 0x2B880 of this file, using file manipulation function like fwrite(), fopen_s() and fclose(): which is captured in Process Monitor from Sysinternals Suite aka procmon:

and taking a look at destination folder confirms the drop and digital signature verify the legitimacy of innocent driver:

I’ve written a quick python automation script to extract the driver from the initial malware:

# filename : extract-driver.py
# author : theabsnt :)

def main():
   with open('sample-kill-floor.exe', 'rb') as f:
        # offset to embedded driver in this file is 0x2B880
        # the driver size is 0x32C98
        content = f.read()[0x2B880 : 0x2B880+0x32C98]
        
        with open('vuln-driver-aswArPot.sys', 'wb') as f:
            f.write(content)

if __name__ == "__main__":
    main()

The persistence

Once the legitimate kernel driver is dropped, it establishes persistence by creating a service name aswArPot.sys using sc.exe(modifies services entries in Service Control Manager database of windows) with parameter binpath set to the path where driver was dropped:

also the procmon capture reflects the same, as we can see, cmd.exe child processes are spawned to run the supplied command to create and start the service right away:

which can further be cross verified by AutoRun entry and checking the service properties:

On success, malware gains kernel-level access to the system, providing it with the ability to terminate security processes.

Looking for the prey

Next, it starts an infinite loop to iterate through all the process running on the system using a combination of three winAPI functions :

• CreateToolhelp32Snapshot with args 0x2(TH32CS_SNAPPROCESS) and 0 (indicating current process)
• along with Process32FirstW and Process32NextW, then compares each process name against list of 142 hard coded security vendors process names initially defined.

The termination

On process name match, the malware grabs the driver handle using CreateFileW function, if the handle to the driver is created, it calls DeviceIoControl function with arguments being IOCTL code of 0x9988c094 along with the target process ID.

Since kernel mode drivers can override the user-mode processes, the Avast driver ends up terminating the asked processes, bypassing various tamper protection mechanism from antivirus, sounds brutal innit?

Upon running the malware in my sandbox, it terminates the MsMpEng.exe ie. Microsoft Malware Protection Engine process and the console runs endlessly to kill process whenever a new one spawns:

The trigger

The Avast driver interprets the IOCTL code (0x9988c094) as a command to terminate the specified security process that is passed by the malware alongside the code.

Looking at the disassembly of the driver we see a reference mentioning the IOCTL code is being compared(cmp instruction) below:

that later invokes the subroutine sub_14001DC80 which shows driver using Windows kernel functions KeAttachProcess, ZwOpenProcess and ZwTerminateProcess to terminate security processes on behalf of the malware.

Conclusion

Such behavior or loopholes raises question on the faith or trust we show on security vendors or antivirus.

Bundling and exploiting a legitimate binaries to carry out malicious intent is an often seen trend among malware campaigns. Likewise, in my previous blog we’ve discussed something along the line.

Seems like this particular malware we’ve gone through is one of many component of this malware campaign, as the only job this malware does is to trick the Avast driver to kill specified process.

Anyways, it was fun exploring this malware, learned a lot and i hope you got some values off of it.

I’ll see you around, till then have a nice time :)

Indicator of compromise(IOC)

MITRE ATT&CK Techniques