Threat Overview

In early February 2026 Huntress documented a sophisticated intrusion that began with compromised SonicWall SSLVPN credentials. An attacker used these credentials to gain initial access to a target network, then deployed a custom EDR killer that leveraged a revoked Guidance Software EnCase forensic driver. The goal was to terminate security processes from kernel mode, a technique known as Bring Your Own Vulnerable Driver (BYOVD). The attack was stopped before ransomware deployment, but it highlighted a growing trend of weaponizing signed, legitimate drivers to blind endpoint security.

Technical Analysis

SIEM and VPN Telemetry

Huntress’s managed SIEM ingested SonicWall telemetry, which proved critical for reconstructing the timeline. VPN authentication logs revealed successful logins to the SSLVPN from a malicious IP address 69.10.60.250. A denied portal login from 193.160.216.221 appeared one minute earlier, indicating the attacker was probing the network. SIEM correlation with endpoint visibility allowed rapid identification of the intrusion, quarantine of affected systems, and delivery of remediation guidance.

Reconnaissance

Once authenticated, the actor performed aggressive network reconnaissance. SonicWall IPS alerts captured ICMP ping sweeps, NetBIOS name requests, and SMB-targeted activity, including a SYN flood at rates exceeding 370 SYNs per second. This activity signaled the actor’s intent to map the internal landscape before executing the kill chain.

Execution: EDR Killer

The binary is a 64‑bit Windows executable that deploys a kernel driver to terminate security software processes. It masquerades as a legitimate firmware update utility. Embedded within the binary is a custom wordlist‑based encoding scheme that converts each byte of the driver into an English word, rendering the payload invisible to static analysis tools and reducing entropy to 4 bits per byte.

Wordlist Encoding

The encoding scheme uses a 256‑word dictionary embedded in the binary. Each word corresponds to a specific byte value; for example, “about” maps to 0x00 and “block” maps to 0x4D. The driver payload is stored as a 384,528‑byte string of space‑separated words. A lookup routine tokenizes the string and performs a linear search against the dictionary to rebuild the original driver. The first words “block both choice about” decode to the DOS MZ signature, confirming that the payload is a valid Windows PE file. The decoded driver is written to C:\ProgramData\OEM\Firmware\OemHwUpd.sys, then hidden, stamped with timestamps from ntdll.dll, and marked as a system file to blend in with legitimate software.

Target Identification

The binary maintains a list of 59 target process names hashed with FNV‑1a. During execution it enumerates all running processes, compares their hashed names to the pre‑computed list, and kills any match. The victim’s kill list includes major endpoint security vendors such as Microsoft Defender, CrowdStrike, SentinelOne, Carbon Black, Palo Alto Cortex, Elastic Security, Cybereason, Cylance, Symantec, McAfee, Trend Micro, Sophos, Kaspersky, ESET, Bitdefender, Fortinet, Malwarebytes, Avast, FireEye, Tanium, Qualys, Rapid7, and Splunk. Huntress was not targeted. The kill loop runs continuously with a one‑second sleep, ensuring any restarted security process is immediately terminated.

Persistence & Driver Signature

After decoding and dropping the driver, the binary registers it as a Windows kernel service named OemHwUpd, with a display name OEM Hardware HAL Service. The service is set to demand start and runs as a kernel driver, ensuring the malicious code survives reboots. Because the EnCase driver’s certificate expired in 2010 and was revoked, Windows still accepts the driver due to a gap in Driver Signature Enforcement: the kernel does not check certificate revocation lists. The driver is timestamped by Thawte timestamping, and the signature chain passes through a trusted Microsoft root, allowing the driver to load despite its revoked status.

Microsoft Blocklist and HVCI

Microsoft introduced a Vulnerable Driver Blocklist, a hash‑based deny list that blocks known bad drivers. When HVCI or Memory Integrity is enabled, the blocklist is enforced by default. However, the approach is reactive; a driver must first be identified as vulnerable to be added to the list. The EnCase driver was able to load because its certificate predates the 2015 signing cut‑off and because the driver was signed and timestamped while the certificate was still valid.

Conclusion

This intrusion demonstrates how BYOVD attacks have become a staple of modern ransomware playbooks. By repurposing a legitimate forensic driver signed over 15 years ago, threat actors bypass Driver Signature Enforcement and gain kernel‑level control to terminate any security process on the system. The attack chain—compromised VPN credentials, EDR killer deployment, kernel driver persistence, and driver signature exploitation—follows a well‑established pattern seen in ransomware precursor activity.

Recommendations

• Enable MFA on all remote access services to prevent credential‑only compromises.
• Review VPN authentication logs for anomalous patterns and denied attempts before successful logins.
• Enable HVCI or Memory Integrity to activate Microsoft’s Vulnerable Driver Blocklist.
• Monitor for services with OEM‑style names created outside normal deployment processes.
• Deploy WDAC driver block rules to deny known vulnerable drivers.
• Enable the ASR rule “Block abuse of exploited vulnerable signed drivers” to stop applications from writing such drivers to disk.

Indicators of Compromise

Item	Description
Driver Path	C:\ProgramData\OEM\Firmware\OemHwUpd.sys
Service Name	OEM Hardware HAL Service
Service Display Name	OEM Hardware HAL Service
Threat actor IP	69.10.60.250
Probe IP	193.160.216.221
EnCase Driver Hash	3111f4d7d4fac55103453c4c8adb742def007b96b7c8ed265347df97137fbee0
EDR Killer Hash	6a6aaeed4a6bbe82a08d197f5d40c2592a461175f181e0440e0ff45d5fb60939