Security News Why a decade-old EnCase driver still works as an EDR killer

Miravi

Level 9
Thread author
Verified
Well-known
Aug 31, 2024
423
3,013
768
USA
Attackers are leaning on a new EDR killer malware that can shut down 59 widely used endpoint security products by misusing a kernel driver that once shipped with Guidance Software’s EnCase digital forensics tool, Huntress researchers warn.

This particular driver is legitimate but its certificate expired and was revoked more than ten years ago. Even so, Windows still allows it to load.

The attack​

Huntress’ security experts spotted this intrusion earlier this month, and discovered that the attackers:
  • Gained access to the victim organization’s network by successfully authenticating to the SonicWall SSLVPN with previously compromised credentials
  • Performed network reconnaissance
  • Loaded the EDR killer, with the vulnerable kernel driver embedded in it
A custom encoding scheme hides the encoded driver from security solutions.

After decoding the driver, the malware writes it to disk under a path that looks like a legitimate OEM component, hides the file, and copies timestamps from a real system file so it blends in. It then registers the driver as a Windows kernel service to ensure it loads on every reboot.

“Once loaded, the driver exposes an IOCTL interface that allows usermode processes to terminate arbitrary processes directly from kernel mode. This bypasses all usermode protections, including Protected Process Light (PPL) that typically guards critical system processes and EDR agents,” the researchers explained.

Why BYOVD still works on modern Windows systems​

The Bring Your Own Vulnerable Driver (BYOVD) technique is a way for attackers to gain deep system access by abusing trusted but flawed Windows drivers. Instead of writing their own malicious driver, they bring along a legitimate one that was originally created by a hardware vendor or software company.

Once the vulnerable driver is running in the kernel, attackers can use its bugs or exposed functions to, for example, kill security processes, disable protections, or read and write directly to memory.

Defenders have known about BYOVD for years, but stopping it at scale is difficult.

Windows’ Driver Signature Enforcement (DSE) feature is good at spotting unsigned or tampered kernel drivers, but the kernel does not check Certificate Revocation Lists.

“This limitation exists for practical reasons: drivers load early in the boot process before network services are available, and CRL checks would significantly impact boot performance. Even when a CRL is manually imported into local certificate storage, the kernel bypasses this check entirely,” the researchers explained.

Instead, Microsoft has decided that it would create and constantly update the Vulnerable Driver Blocklist, with comes with an obvious drawback: only known-bad drivers are on it, which means that attackers have a window of opportunity until the driver they use ends up on it.

In addition to all this, Microsoft allows for exceptions to maintain backward compatibility.

“Drivers signed with certificates issued before July 29, 2015, that chain to a supported cross-signed certificate authority are still permitted to load,” the researchers noted.

“The EnCase driver’s certificate was issued on December 15, 2006, well before this cutoff.”
 
It is reported "Defenders should also turn on Memory Integrity so Microsoft’s Vulnerable Driver Blocklist is enforced", meanwhile, I have driver blocklist enabled without memory integrity (Virtualization is turned off in BIOS and no option for memory integrity dispalyed)!
 

Attachments

  • Capture.JPG
    Capture.JPG
    50.8 KB · Views: 41
  • Capture2.JPG
    Capture2.JPG
    55.5 KB · Views: 39
It may sound like a corporate problem, but if malware with this trick ever reached a home PC, the impact would be brutal: the antivirus would be shut down and the system left completely defenseless. In that scenario, the average user wouldn’t stand a chance. 🔒💻⚡
 
It may sound like a corporate problem, but if malware with this trick ever reached a home PC, the impact would be brutal: the antivirus would be shut down and the system left completely defenseless. In that scenario, the average user wouldn’t stand a chance. 🔒💻⚡

A remote possibility.
However, a Standard Account would also avoid even the mere possibility.;)
 
Technical Analysis & Remediation

MITRE ATT&CK Mapping

T1562.001 (Impair Defenses)

The malware uses the driver to terminate 59 specific security processes.

T1543.003 (Create or Modify System Process: Windows Service) Registers the driver as a service to ensure persistence.

T1036.005 (Masquerading)
Hides the driver as a legitimate OEM component (OemHwUpd.sys) and timestomps it to match system files.

Telemetry & IOCs

Vulnerable Driver Source

Guidance Software EnCase (Signed Dec 15, 2006).

Dropped Payload Path C:\ProgramData\OEM\Firmware\OemHwUpd.sys.
Service Name
OemHwUpd.

Service Display Name
OEM Hardware HAL Service.

Targeting Logic
The malware calculates FNV-1a hashes of running process names and compares them against a blacklist of 59 security products.

Encryption
The payload uses a custom wordlist-based substitution cipher to evade static analysis before dropping the driver.

Vulnerability Profile

Mechanism

Windows allows drivers signed before July 29, 2015, to load even if the certificate is revoked, to maintain backward compatibility.

Driver Status
The EnCase driver's certificate expired in 2010 and was revoked, yet it remains effective for BYOVD attacks because the kernel does not strictly enforce the Certificate Revocation List (CRL) during boot for performance reasons.

Remediation - THE ENTERPRISE TRACK (NIST SP 800-61r3 / CSF 2.0)

GOVERN (GV) – Policy & Risk

Command

Audit all third-party drivers loaded in the environment.

Command
Enforce policy to block drivers not present in the Microsoft Vulnerable Driver Blocklist.

DETECT (DE) – Monitoring

Command

Configure SIEM to alert on the creation of services named OemHwUpd or binaries written to C:\ProgramData\OEM\Firmware\.

Command
Monitor for unexpected termination of EDR agent processes (T1562.001).

RESPOND (RS) – Containment

Command

Isolate hosts showing signs of SonicWall SSLVPN compromise immediately.

Command
Use a distinct tool (e.g., a kernel-level anti-rootkit or specialized removal tool) to unload the malicious service, as the malware actively kills standard EDR agents.

IDENTIFY & PROTECT (ID/PR) – Hardening

Command

Enable Memory Integrity (Hypervisor-protected Code Integrity - HVCI). This is the primary native defense that enforces the Microsoft Vulnerable Driver Blocklist.

Command
Update SonicWall firmware and force a password reset/MFA enrollment for all VPN users.

Remediation - THE HOME USER TRACK (Safety Focus)

Priority 1: Enable Core Isolation

Command

Go to Windows Security > Device Security > Core Isolation and toggle Memory Integrity to "On". This helps block known vulnerable drivers.

Priority 2: Persistence Check

Command

Check your Windows Services (services.msc) for any service named "OEM Hardware HAL Service" or "OemHwUpd". If found, set it to "Disabled" and reboot.

Priority 3: Verification

Command

Run a full offline scan using Microsoft Defender (Windows Security > Virus & threat protection > Scan options > Microsoft Defender Antivirus (Offline scan)).

Hardening & References

Constraint

The attack relies on "backward compatibility" exceptions in Windows Driver Signature Enforcement.

Fact
The malware specifically avoids targeting the Huntress agent, likely an oversight or evasion tactic by the authors.

Source

Huntress

Help Net Security
 
It is reported "Defenders should also turn on Memory Integrity so Microsoft’s Vulnerable Driver Blocklist is enforced", meanwhile, I have driver blocklist enabled without memory integrity (Virtualization is turned off in BIOS and no option for memory integrity dispalyed)!

Microsoft Defender has better vulnerable driver blacklist (via ASR rules) than Core Isolation.
 
Microsoft Defender has better vulnerable driver blacklist (via ASR rules) than Core Isolation.
Do you suggest turning off vulnerable driver blacklist of core isolation section, and to replace it with "Block abuse of exploited vulnerable signed drivers" ASR rule?
 
Microsoft Defender has better vulnerable driver blacklist (via ASR rules) than Core Isolation.
You are partially correct: The ASR Rule ("Block abuse of exploited vulnerable signed drivers") and Core Isolation (Memory Integrity/HVCI) serve different functions in the kill chain. ASR is designed to prevent the writing (dropping) of the file to disk, whereas Core Isolation prevents the loading of the driver into memory. Microsoft explicitly recommends enabling both to cover the gap between "file drop" and "driver load."

ASR is good for stopping the drop, but if the hacker finds any other way to put the file on the disk (or if it was already there), Core Isolation is the only thing that stops the execution. That is why it is the "Standard" recommendation.
 
ASR is designed to prevent the writing (dropping) of the file to disk, whereas Core Isolation prevents the loading of the driver into memory.

Yes, but it is still true what I posted: "Microsoft Defender has a better vulnerable driver blacklist (via ASR rules) than Core Isolation."(y)
@Parkinsond posted that he uses black list included in the Core Isolation. However, using only Core Isolation can be insufficient.
 
Last edited:
Do you suggest turning off vulnerable driver blacklist of core isolation section, and to replace it with "Block abuse of exploited vulnerable signed drivers" ASR rule?

No. I recommend keeping the first and enabling the second.
 
Yes, but it is still true what I posted: "Microsoft Defender has a better vulnerable driver blacklist (via ASR rules) than Core Isolation."(y)
@Parkinsond posted that he uses black list included in the Core Isolation. However, using only Core Isolation can be insufficient.
You are absolutely right about the lists, ASR queries the cloud and is often more up-to-date than the local DriverSiPolicy.p7b file that Memory Integrity relies on. I agree that relying only on Core Isolation leaves a gap if the local list is stale.

However, my main concern is the 'Existing Threat' scenario mentioned in the Help Net Security report. Since ASR only blocks the write/drop to disk, if the EnCase driver was already planted (or brought in via a method that bypassed the write-filter), ASR won't stop it from starting. Core Isolation is the only layer that acts as the final gatekeeper for the Kernel itself.

We definitely need both. ASR for the 'Drop,' Core Isolation for the 'Load.' But for a generic recommendation to users who might already be infected, I prioritize Core Isolation to stop the active kill-switch.
 
We definitely need both. ASR for the 'Drop,' Core Isolation for the 'Load.' But for a generic recommendation to users who might already be infected, I prioritize Core Isolation to stop the active kill-switch.

I would not prioritize one over another. The Core Isolation list is usually outdated (mine is from April 2025). Attackers can often use drivers not on that list.
 
I would not prioritize one over another. The Core Isolation list is usually outdated (mine is from April 2025). Attackers can often use drivers not on that list.
Andy, I agree with you that the local blocklist can be stale (April 2025). However, we prioritize Core Isolation in the report for Architectural Reasons, not just for the list quality.

ASR only prevents the file from being written to disk. If the attacker used a method that bypassed ASR (like an archive extraction) or if the driver was dropped before we turned ASR on, ASR does nothing.

Core Isolation is the only control that sits between a file on the disk and the Kernel.

If Core Isolation is ON but the list is old, we can simply push a Windows Update to refresh the list and block the attack. If Core Isolation is OFF, the driver loads immediately, kills our EDR, and we lose the machine.

We prioritize Core Isolation because it protects against the Failure of ASR. It is safer to have a 'Stale Lock' that we can update than to have 'No Lock' at all.
 
Last edited:
If Core Isolation is On (even with an old list), we still have a chance to block it.

I do not prioritize any of them because there is no data/evidence on which one is more frequently bypassed by the attackers.
Also, there is no need to prioritize one over another when we agreed that both should be used. :)
 
I do not prioritize any of them because there is no data/evidence on which one is more frequently bypassed by the attackers.
Also, there is no need to prioritize one over another when we agreed that both should be used. :)
That is why my report prioritizes Core Isolation.
It is the Maximum Executable Security for a home user. ASR is technically superior for fresh threats, but operationally impossible for 99% of that audience without direct IT support.
 
Last edited:
Industry standards exist to replace Subjective Opinions with Objective Best Practices.
.
No one tested those standards against vulnerable drivers. The result can highly depend on the attackers, especially when they know those standards.
For me, in this case, the industry standards are an insufficient criterion. However, I can easily accept that you might not agree. (y)