It’ll be back: Attackers still abusing Terminator tool and variants
Credit to Author: Matt Wixey| Date: Mon, 04 Mar 2024 11:00:08 +0000
BYOVD (Bring Your Own Vulnerable Driver) is a class of attack in which threat actors drop known vulnerable drivers on a compromised machine and then exploit the bug(s) to gain kernel-level privileges. At this level of access, attackers can accomplish a lot: hide malware, dump credentials, and, crucially, attempt to disable EDR solutions.
Threat actors are spoiled for choice when it comes to choosing vulnerable drivers; as of this writing, there are 364 entries tagged as “vulnerable driver” listed on loldrivers.io, an open-source repository of vulnerable drivers and corresponding signatures and hashes. Perhaps as a result of this, BYOVD attacks – previously the province of highly sophisticated threat actors – have become popular amongst ransomware operators and lower-tier attackers in recent years.
In February 2020, for example, we reported on a RobbinHood ransomware campaign in which the threat actor abused a legitimate driver signed by a motherboard manufacturer, to disable EDR products. Since then, we’ve also reported on a BlackByte ransomware campaign abusing a graphics card driver; a BYOVD campaign in which threat actors leveraged a Windows driver; and multiple incidents involving AuKill, a tool that abuses an outdated Process Explorer driver, and which we’ve observed threat actors use in several ransomware incidents.
Another possible reason for BYOVD becoming popular with lower-tier threat actors is that off-the-shelf kits and tools are now bought and sold on criminal forums. One in particular attracted a significant amount of attention in May 2023, when a threat actor known as spyboy advertised a tool called Terminator on the Russian-language ransomware forum RAMP. The seller claimed that the tool, priced between $300 USD to $3,000 USD, could disable twenty-four security products.
Hasta la driver, baby
A 2023 analysis by CrowdStrike revealed that Terminator appears to be a BYOVD tool, with the vulnerable driver in question being zam64.sys (Zemana Anti-Logger) or zamguard64.sys (Zemana Anti-Malware, or ZAM), published and signed by Zemana. Both drivers share almost the same code base.
Figure 1: Comparing decompiled disassembly code of both Zemana drivers reveals almost the same code base
Both drivers also contain the same vulnerability, an insufficient verification of the processes that can send IOCTL codes to them and request various functionalities. The drivers maintain an ‘allow list’ of legitimate, trustworthy processes. However, by sending an IOCTL code 0x80002010 and passing the process ID of a running process as a parameter, an attacker can add their own process to the allow list and circumvent this security measure. Once added, the attacker can request a number of functionalities from the driver, such as attempting to terminate a targeted process by sending an IOCTL request with code 0x80002048. A comprehensive list of functionalities is provided in this article.
Figure 2: IOCTL code requests needed to be able to abuse the vulnerability
To abuse the driver in this way, however, a threat actor would need administrative privileges and a User Account Control (UAC) bypass (or they would need to convince a user to install the driver via social engineering). So while leveraging vulnerable legitimate drivers could certainly allow a threat actor to terminate AV and EDR processes, it’s not necessarily straightforward, and escalating privileges may trigger other security protections.
Multiple variants
Many of the vendors on spyboy’s list, including Sophos, moved quickly to investigate variants of the drivers and develop protections. Since the initial release of Terminator, we have also tracked multiple variants of the tool – including open-source versions such as Terminator, which reproduces spyboy’s technique; SharpTerminator, a C# port of the previous project; and Ternimator, a version written in Nim . (Like Rust, Nim is a popular language for writing red teaming tools or malware, because as a relatively new language it may be more likely to circumvent static detections or static based heuristic models; it also offers cross-platform support).
Even multiple months after the initial discovery, the drivers are still a popular topic in darknet forums. For instance, we discovered the following November 2023 post on a Russian-language criminal forum:
Figure 3: A threat actor posts on a criminal forum offering a BYOVD tool for sale
After further investigation of the thread, we assess that this likely refers to a different release version of the Zemana driver(s), or a hash that is not, as of this writing, reported on loldrivers.io. When challenged by another user, who said that: “its [sic] ZAM, not worth spending time on (blacklisted & detected)”, the original poster replied: “it is not in the databases…in the databases there is a different version of the driver and not this one.”
Further discussion in the forum revealed that threat actors are aware of the widespread coverage of the vulnerable Zemana drivers. The discussion ended with another threat actor suggesting that developing a malicious driver from scratch and using a valid certificate – be it stolen, leaked, or otherwise acquired – to sign it, is a more viable strategy than using known vulnerable drivers.
While we weren’t able to glean any further useful information from the thread, we decided to do some investigation and analysis, to determine the extent of Zemana driver abuse and to see whether attackers are making further tweaks and changes to the original Terminator tool.
Real-world attacks
We reviewed our behavioral detection telemetry for the past six months and discovered several incidents in which attackers used the Zemana Anti-Logger or Anti-Malware drivers. In some cases, threat actors also ported the open-source projects discussed earlier to different languages or obfuscated them through packers to circumvent detection. We’ve highlighted the incidents below as they’re illustrative of patterns we saw across a wider evidence base.
From Citrix to Ter
On September 13, 2023 and October 10, 2023, Sophos thwarted attacks which both used very similar methodologies. In both cases, initial access was likely obtained via exploiting a vulnerable Citrix application. From there, the attackers injected a payload into the Windows Error Reporting process, wermgr.exe. Next, they tried to disable Sophos by issuing the following commands:
wmic service where "PathName like '%sophos%'" call delete /nointeractive wmic service where "PathName like '%sophos%'" call stopservice /nointeractive
Tamper protection was enabled on the targeted devices, so the attempts to simply disable and remove the Sophos services failed. Finally, the threat actor switched to deploying an EXE file named ter.exe. The binary unpacks itself to a slightly modified version of Terminator. The driver itself was dropped separately before this.
Upon execution, the binary loads the “BINARY” resource. The content is decrypted via AES-256. The key is hardcoded in the binary. Finally, the binary writes the decrypted content into a newly allocated section and executes it. The attempt to load the driver was blocked by one of our behavioral protection rules.
Figure 4: Unpacking routine of ter.exe
After investigating the disassembly of the unpacked ter.exe binary, we found the PDB path string with the original project name “Terminator-master,” suggesting that the threat actor modified code from the Terminator GitHub repository.
Figure 5: Path to PDB file, found in the unpacked ter.exe
Healthcare under attack
On December 15, 2023 we blocked an attack targeting a healthcare organization. Immediately after initial access, the attackers attempted to execute a PowerShell command to download a text file from a C2 server.
The text file itself is a PowerShell script designed to install the XMRig cryptominer on the targeted system. The attempt was blocked by one of our behavioral protection rules.
Later, the threat actors tried to disable the EDR client via running ternimator, the Nim version of Terminator, on one of the infected machines. The attempt to load the driver was also blocked by behavioral protection rules.
Figure 6: Overview of the attack on the healthcare organization
From ZAM to AuKill
In this attack, which occurred on Christmas Day 2023, the threat actor gained access to a single machine, although the initial attack vector is unclear. First, they tried to load the Zemana Anti-Logger driver, masquerading as updatedrv.sys, from different locations:
%sysdir%driversupdatedrv.sys <d>programdatausosharedupdatedrv.sys
After these attempts failed, they switched to using AuKill, another known EDR killer, where the Process Explorer driver was named ped.sys in the temp folder. We reported this to the customer, and did not see any further detections triggered; we are therefore highly confident that the attack was thwarted.
Mitigation and protection
Detecting the abuse of vulnerable drivers is a unique challenge for the security industry. While efforts to compile repositories of known vulnerable drivers, such as loldrivers.io, are certainly useful, it is worth noting that these drivers are legitimate, and may be crucial for the operating system or for mission-critical services and applications. Blocking them wholesale, without careful validation, can be time-consuming, counter-productive, and result in unforeseen problems for organizations. A solely reactive approach is therefore usually not enough to solve this issue, particularly since there are so many known vulnerable drivers – with potentially more containing zero-day vulnerabilities.
However, it’s relatively rare for threat actors to deploy legitimate drivers with zero-day vulnerabilities; most of the time, the drivers and their vulnerabilities are known and documented, as is the case here (albeit they may be packed, obfuscated, or tweaked to avoid static detection). So keeping up-to-date with vulnerable drivers, and blocklisting any that you don’t already have installed, can be worthwhile.
We also recommend taking the following proactive actions:
- Check if your endpoint security product implements tamper protection (see here for advice on how to do it for Sophos products)
- Practice strong Windows security roles hygiene. BYOVD attacks are typically made possible through privilege escalation and UAC bypasses
- Keep both your OS and individual applications and tools updated, and remove older software if it’s no longer used or required
- If you’re not doing so already, consider adding vulnerable drivers to your vulnerability management program; threat actors could seek to exploit vulnerable legitimate drivers that already exist on a compromised system
In addition to static detections of some of the Zemana components mentioned in this article, Sophos behavioral protection rules and Adaptive Attack Protection provide further layers of defense. Moreover, BYOVD events do not happen in isolation, and some of the activities that accompany a BYOVD attack – exploitation of an initial attack vector; lateral movement; establishing persistence; and privilege escalation – offer further opportunities to detect and block an attack in progress.
Conclusion
BYOVD attacks are attractive to threat actors, as they can provide a means by which to disable AV and EDR solutions at the kernel level. The sheer amount of known vulnerable drivers means that attackers have a wealth of options to choose from. Our investigation into the misuse of Zemana drivers illustrates that threat actors will continue to use such components even if they’re publicly known and signatured – because they are known to work, and because they are often bundled into off-the-shelf kits and tools. However, it’s also worth noting our finding on the forum – that some threat actors are instead advocating for purpose-built malicious drivers, signed with stolen or leaked certificates.
Like many others in the security community, we are constantly researching and evaluating the threat landscape to keep track of both vulnerable and custom-built drivers, as per our previous coverage of AuKill and other campaigns. We are also continuing to devise and test new methods to proactively block maliciously used drivers.
IOCs for the attacks described in this article are available on our GitHub repository.
Protections