Yours Truly, Signed AV Driver: Weaponizing an Antivirus Driver
In 2021, Stroz Friedberg observed novel indicators of compromise (IOCs) and a technique that abused a function in an Avast® Anti Rootkit kernel driver to terminate popular Antivirus (AV) and Endpoint Detection and Response (EDR) processes.
As we head into 2022, ransomware groups continue to plague our digital environment with new and interesting techniques to bypass Antivirus (AV) and Endpoint Detection and Response (EDR) solutions and ensuring the successful execution of their ransomware payloads.
In December 2021, Stroz Friedberg’s Incident Response Services team engaged in a Digital Forensics and Incident Response (DFIR) investigation and environment-wide recovery of a Cuba ransomware incident. We discovered novel indicators of compromise (IOCs) utilizing an interesting technique. Here, as part of the Cuba’s toolset, the threat actor group executed a script that abused a function in an Avast® Anti Rootkit kernel driver to terminate popular AV and EDR processes.
While the use of kernel drivers to target and kill AV and EDR solutions1 prior to encryption has been known and discussed for some time, the abuse of a signed and valid driver from an Antivirus vendor2 was surprisingly effective and ironic.
At the time of writing this article, there are three different versions of the same attack. They are listed below in the order of implementation complexity:
- A self-contained PowerShell script, dropped alongside the Avast driver, that installs and loads the driver and executes a small number of functions to control the driver.
- An executable that unpacks and loads in memory a small executable to control the driver. Within this blog, we refer to this executable as the controller. Additional tools are used to install and load the Avast driver in the infected system.
- A batch script that installs a service to load the Avast kernel driver, then launches a PowerShell script to decode, load and execute the controller in memory.
This article delves into the implementation of the third variant of the attack where the attacker uses a batch script as described in the third bullet point above.
The Staging – Batch Script
The first stage of the hijack starts with the threat actor dropping three files, a batch script, a PowerShell script, and an Avast driver, within the target system’s C:\Windows and C:\Windows\Temp directories.
The threat actor executes the batch script to create and start a new service that utilizes a legitimate Avast Anti Rootkit kernel driver named aswArPot.sys. A short timeout is included to ensure the service is fully started, prior to the execution of the PowerShell script used to unpack and execute the controller.
@ echo off
sc.exe create aswSP_ArPot2 binPath= C:\windows\temp\aswArPot.sys type= kernel
sc.exe start aswSP_ArPot2
Timeout /t 3
C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe -windowstyle hidden -executionpolicy bypass -file c:\windows\temp\SAMPLE.ps1
The Obfuscation – PowerShell Loader Script
The PowerShell script contains multiple layers of obfuscation which, when executed, decodes its contents, and rebuilds the controller. Once the PowerShell script finishes rebuilding the controller, it utilizes Windows Application Programming Interfaces (APIs) to load and execute the controller in memory.
Add-Type -TypeDefinition @'
using System;
using System.Diagnostics;
using System.Runtime.InteropServices;
public static class RANDOMSTRING1 {
[DllImport("kernel32.dll")]
public static extern IntPtr VirtualAlloc(IntPtr RANDOMSTRING2, uint RANDOMSTRING3, uint RANDOMSTRING4, uint RANDOMSTRING5);
[DllImport("PowrProf.dll")]
public static extern IntPtr EnumPwrSchemes(IntPtr RANDOMSTRING6, IntPtr RANDOMSTRING7);
}
'@
Function ouBmwjaLNIuXYiiWYYxZt() {
return (([regex]::Matches('[Redacted_Base64_String…]
The Controller – Malicious Portable Executable (PE)
The small (~5KB in size) PE loaded into memory proved to be simple, yet effective. The executable is designed to collate a list of actively running processes, then compare them to an obfuscated hardcoded list of CRC64 checksum values of AV and EDR processes names. If any process name directly correlates to an entry in the hardcoded list, an I/O Control (IOCTL) code is sent to the Avast driver, resulting in the termination of the process.
Disassembling the sample on Ghidra provides insight into the hashing and comparison functions of the controller:
1. The initial function creates a handle to reference the recently installed Avast driver via the CreateFileW API. If the driver handle returns as valid, the executable calls a function to find and terminate processes.
.jpg?width=857&height=536&name=aon-cyber-labs-blog-weaponizing-av-driver-1%20(1).jpg)
2. Once inside this function, a snapshot of actively running processes is taken. The function then iterates through the lowercase Unicode representation of processes names and calculates a CRC64 checksum on each of them using the CRC64_ECMA_182 algorithm.
3. The executable then cycles through the hardcoded list of CRC64 checksum values (QWORD_009c2030), each of which represents the name of known AV or EDR processes. In the sample discussed in this article, the hardcoded list contained 119 (0x77) CRC64 checksum values.
4. If the sample finds a match, it calls the Avast process termination function passing the handle of the Avast driver, and the matching process ID.
5. The DeviceIoControl API is called, which sends the 0x9988c094 IOCTL code to the Avast driver, along with the process ID. This results in the Avast driver terminating the process at Kernel level, bypassing tamper protection implemented in most AV and EDR products.
The Kill – Avast IOCTL Code
The aswArPot.sys Avast driver interprets the 0x9988c094 IOCTL code as a signal to terminate a given process. Below are the pieces of the Avast driver disassembled and decompiled for research purposes, which show the method to terminate a process from kernel mode, using KeAttachProcess and ZwTerminateProcess functions:
Figure 1. IOCTL code comparison within Avast driver’s code, which calls its process terminating function.
Figure 2. Avast driver’s process terminating function.
This IOCTL code and function can be found on multiple versions of the aswArPot.sys Avast driver, including the version distributed on Avast products as of December 2021. However, it was confirmed, through behavioral analysis, that the latest distributed versions of the Avast driver are not susceptible to this abuse. Upon contacting the Avast Bug Bounty team, we have received confirmation that the issue was known and had been resolved by Avast on a February 2021 update of the driver. Furthermore, we have received confirmation that Avast has been in contact with Microsoft to have them invalidate the signature of older versions of the driver. Avast has been informed by Microsoft that a security update on March 2022 would contain the signature update.
The specific aswArPot.sys driver utilized by the threat actors in this instance (SHA256: 4b5229b3250c8c08b98cb710d6c056144271de099a57ae09f5d2097fc41bd4f1) has the following file version information:
The Targets
Different implementations of this driver’s abuse, found either on VirusTotal or on the engagements, contain different lists of targeted processes.
- The smallest PowerShell script implementation targets only one specific process.
- Three "early" versions of the PE found on VirusTotal contained clear-text strings of the targeted processes, along with the transparently named PDB path F:\\Source\\WorkNew19\\KillAV\\Release\\KillAV.pdb. These versions contained 53, 72 and 88 targeted processes with the PE compilation timestamps of October 28th, November 2nd and November 3rd, 2021, respectively.
- The PE with the longest target list of all, found during the Cuba ransomware incident, contained 110 unique targeted processes (after removing duplicates) represented as CRC64 checksum values. It also contained the newest PE compilation timestamp of all.
Utilizing the HashDB API service from OpenAnalysis,3 we were able to recover the clear-text strings corresponding to the hardcoded CRC64 checksums of the latter sample mentioned above. The list contains process names from well-known AV and EDR vendors, which include, amongst others, processes names from SentinelOne®, Cylance®, Avast®, Carbon Black®, Sophos®, McAfee®, and Malwarebytes®.
Below is the list of 110 targeted processes found in the latest PE:
Future Functionality?
The PE found during the Cuba ransomware incident also contains a second smaller chunk of CRC64 checksums, which correspond to the names of three specific ransomware executables utilized by Cuba Ransomware: "a.exe", "anet.exe" and "aus.exe". These checksums sit next to unutilized strings "/c del", ">> NUL" and "\\system32\\cmd.exe". These strings are never referenced. Along with the recent iterations and enhancements on observed versions of this PE, these strings indicate that a potential future version of this executable could include a function to automatically delete the ransomware executables from disk.
Closing Remarks
The capabilities brought to the table by exploiting functionalities of a signed and widely distributed Antivirus piece of software, running under the highest privileges on a system, demonstrates the power of this technique. The sophistication and resources being applied by ransomware groups into new innovative ways to bypass security controls continues to increase.
IOCs
Below is a list of publicly found samples:
| File Name | SHA256 Hash |
|---|---|
| eset.ps1 | 8fcfa67e1fde51f7d99c3714f80b7672a0bb0d31c6cafdb5e7670b845d4dee98 |
| A82.exe | 4306c5d152cdd86f3506f91633ef3ae7d8cf0dd25f3e37bec43423c4742f4c42 |
| KillAV.exe | aeb044d310801d546d10b247164c78afde638a90b6ef2f04e1f40170e54dec03 |
| c5e3b725080712c175840c59a37a5daa.virus |
f68cea99e6887739cd82865f9b973664117af14c1a25d4917eec25ce4b26a381
|
ATT&CK® Mapping
Execution
- T1059.001 – Command and Scripting Interpreter – PowerShell
- T1106 – Native API
- T1569.002 – System Services – Service Execution
- T1204.002 – User Execution – Malicious File
Defense Evasion
- T1458.002 – Abuse Elevation Control Mechanism – Bypass User Access Control
- T1140 – Deobfuscate/Decode Files or Information
- T1211 – Exploitation for Defense Evasion
- T1574.010 – Hijack Execution Flow – Service File Permissions Weakness
- T1562.001 – Impair Defense – Disable or Modify Tools
- T1036.005 – Masquerading – Match Legitimate Name or Location
- T1027.001 – Obfuscated Files or Information – Binary Padding
- T1027.002 – Software Packing
- T1055.002 – Process Injection – Portable Execution Injection
- T1218 – Signed Binary Proxy Execution
Discovery
- T1057 – Process Discovery
Acknowledgements: Special thanks to Aon’s Cyber Solutions team member, Nhan Huynh, for assistance with revising content and ensuring accuracy.
1 How DoppelPaymer Hunts and Kills Windows Processes, https://www.crowdstrike.com/en-us/blog/how-doppelpaymer-hunts-and-kills-windows-processes/
2 Signed Binary Proxy Execution – T1218, https://attack.mitre.org/techniques/T1218/