Compromised VPN Access and EDR Killer Deployment
Recently, it has been determined that the attackers used the compromised SonicWall SSL VPN account credentials to initially gain access. The VPN account did not have multi-factor authentication (MFA) enabled.
Once the attackers were in the environment, they engaged in aggressive internal reconnaissance activities, including ICMP ping sweeps, SMB scans, etc. The attackers then executed a malicious executable that posed as a firmware updater. The malware executed an encoded driver onto the target disk. Immediately upon execution, the malware started killing security products. The attack steps involved the following activities:
- Stolen VPN access: The attackers used valid SonicWall SSL VPN account credentials that did not contain multi-factor authentication.
- Internal scanning: The attacker conducted broad network scans (pings, NetBIOS/SMB probes) to discover targets.
- Malicious dropper execution: Executed a 64-bit binary that posed as a firmware updater. The malware executed an encoded driver onto the target disk.
- EDR killer activation: The malware decoded the embedded driver, registered it as a Windows service (
OemHwUpd), and began killing security processes in kernel mode.
BYOVD Attack: Repurposing an Old Driver
This incident is a textbook example of a Bring-Your-Own Vulnerable Driver (BYOVD) attack. In a BYOVD scenario, adversaries take a legitimate, signed device driver that has security flaws or obsolete trust, and load it to run malicious code at the kernel level. By design, Windows treats signed drivers as trustworthy.
Here, the attackers used an outdated forensic driver from EnCase (Guidance Software) as their “vulnerable” driver. Because the driver was still digitally signed, the operating system allowed it to load. Once in kernel mode, the driver’s exposed functions (IOCTL interfaces) let the malware terminate almost any running process including EDR and antivirus software with full system privileges. In short, the signed driver gave the malware ring-0 access to blind endpoint defenses.
Exploiting the EnCase Forensic Driver
Specifically, the malware carried a copy of the EnCase Windows driver (often known as EnPortv.sys). This driver had been signed by its vendor back in 2006, and its certificate was revoked in 2010. Despite that, Windows still loaded it under built-in legacy rules.
The dropper hid the driver in C:ProgramDataOEMFirmwareOemHwUpd.sys and registered it as a service named OemHwUpd (displaying as “OEM Hardware HAL Service”). Once loaded, the driver’s IOCTL interface allowed the user-mode malware to tell it which processes to terminate.
Notably, this kill command operates in kernel space, bypassing all user-mode protections. It even defeats Protected Process Light (PPL), which normally shields security software from tampering. In effect, the EnCase driver’s legacy code became a powerful weapon: it could be commanded to kill any protected security service on the machine.
Windows Driver Signing Weakness
This type of exploit is possible due to certain Windows driver signing policy issues. By default, Windows requires kernel drivers to be signed by a trusted Certificate Authority. However, the kernel does not verify the Certificate Revocation Lists (CRLs) for drivers.
Microsoft allows drivers signed before July 29, 2015, with a supported CA chain, to be loaded even if the signing certificates have been invalid for years. In this case, the EnCase driver had been timestamped when the cert was valid. This means it would be accepted by Windows indefinitely.
As this type of exploit has been analyzed, it has been found that this backward compatibility allows pre-2015 drivers to bypass current signing checks. This creates a blind spot that can be exploited at any time.
Attacker Impact: Disabling 59 Security Tools
Once the EDR killer was in place, the attack unfolded quickly. The malware’s user-mode component built a “kill list” of security products by hashing their process names. Analysts identified 59 different endpoint protection tools on that list.
Running in a tight loop (with only a one-second pause each time), it continuously polled for these processes. When any appeared or tried to restart, the malware called the driver’s IOCTL to terminate it immediately. In effect, hundreds of individual processes from antivirus engines to EDR agents could be killed or neutralized. This sweeping action earned such payloads the nickname “EDR killers.” Thankfully, responders halted this operation before ransomware could be dropped, but the incident underscores how a single vulnerable driver can cripple a modern security stack.
Case Study: Xcitium vs. Encase EDR Killer
This demonstration showcases how Xcitium protects endpoints against Bring-Your-Own Vulnerable Driver (BYOVD) attacks a technique used by adversaries to gain kernel-level access by loading legitimately signed but vulnerable drivers.
In this test scenario, an attacker attempts to load the vulnerable OemHwUpd.sys driver to obtain ring-0 privileges and disable security controls. Because the driver is digitally signed, the operating system would normally allow it to load, potentially enabling defense evasion at the kernel level.
However, Xcitium EDR detects the malicious driver-loading attempt at launch and blocks it before it can initialize in kernel mode.
As a result, no kernel-level access is granted, no security processes are terminated, and no privilege escalation occurs.
This video demonstrates how Xcitium prevents modern BYOVD-based defense evasion techniques in real time stopping the attack before it can compromise the system.
Indicators of Compromise (IoCs)
- Driver File Path:
C:ProgramDataOEMFirmwareOemHwUpd.sys(malicious kernel driver). - Service Name:
OemHwUpd(displayed as “OEM Hardware HAL Service”). - Attacker IPs:
69.10.60[.]250and193.160.216[.]221. - Driver SHA-256:
3111f4d7d4fac55103453c4c8adb742def007b96b7c8ed265347df97137fbee0(the EnCase/OEM driver). - EDR Killer SHA-256:
6a6aaeed4a6bbe82a08d197f5d40c2592a461175f181e0440e0ff45d5fb60939(the malicioussvchost.exeloader).
Conclusion: When a Signed Driver Becomes a Weapon
The EnCase BYOVD incident shows why endpoint security is increasingly a kernel battle. Attackers did not need a new exploit, they brought an old, signed forensic driver and used it to gain ring 0 power, then terminate defenses at scale. In this case, stolen SonicWall VPN credentials without MFA opened the door, and an “EDR killer” followed within minutes.
Why This Threat Changes the Rules
BYOVD succeeds because it abuses trust Windows still extends to legacy signed drivers.
- The malicious dropper plants OemHwUpd.sys and registers it as a service, then terminates security tools from kernel space
- Windows driver signing policy allows older drivers to load indefinitely under legacy rules, even when certificates have long been revoked
- The kill list in this campaign targeted 59 security products, and the payload kept looping to prevent recovery
Once kernel level termination begins, the environment becomes blind and ransomware becomes optional.
Where Xcitium Changes the Outcome
If you have Xcitium, this attack would NOT succeed.
Xcitium Advanced EDR blocks the malicious driver loading attempt at launch, before it initializes in kernel mode. No ring 0 access is granted, security processes are not terminated, and privilege escalation does not occur.
Stop the EDR Killer Before It Starts
BYOVD is built to remove your ability to respond. Reduce initial access with MFA on VPN accounts, apply driver blocklists, and enforce controls that prevent malicious driver loading before your defenses go dark.
