Detecting PoisonX-Style Malicious Signed Kernel Drivers: When the LOLDrivers Blocklist Isn't Enough

The standard playbook for defending against BYOVD (Bring Your Own Vulnerable Driver) attacks centres on two controls: HVCI to prevent loading of non-compliant drivers, and blocklists of known-vulnerable driver hashes from projects like LOLDrivers and Microsoft’s WDAC recommended block rules.

PoisonX breaks the second control. The kernel driver used by the GodDamn ransomware group and distributed through The Gentlemen’s GentleKiller affiliate toolkit was not a repurposed vulnerable driver. It was purpose-built to kill security software, and its author obtained a valid Microsoft Hardware Compatibility Publisher certificate for it before distributing it as a “research tool” on GitHub. There was no prior security history. No blocklist entry. The first time defenders could have detected it from a hash perspective was after Xcitium documented it in April 2026.

By that point, it was already being used in attacks.

This guide covers the behavioural detection signals that catch malicious signed kernel drivers independent of whether they appear on any blocklist.

Why Signature-Only Detection Fails Here

The Windows driver signing model establishes that a kernel-mode driver must be signed by Microsoft or a Microsoft-trusted CA before loading on modern Windows. This is a legitimate trust mechanism — unsigned kernel code cannot load without special boot configuration.

The problem is that signing validates cryptographic integrity, not intent. If an attacker can submit a malicious driver through Microsoft’s hardware compatibility programme and receive a valid signature, that driver loads like any legitimate vendor driver. HVCI adds a further layer by enforcing stricter integrity policy, but HVCI alone does not inspect what the driver actually does.

PoisonX cleared the certification process. Its certificate has since been revoked by Microsoft following the July 2026 disclosure. But the attack surface remains: there is nothing structurally preventing a future attacker from repeating the process with a new driver and a new submission.

Blocklist-based detection must be paired with behavioural detection. The signals below catch kernel driver threats regardless of signature status or blocklist coverage.

Key Detection Points

Sigma Rules

Rule 1 — Kernel Driver Service Created from Non-System Path

title: Kernel Driver Service Created from Suspicious Path
id: a9f3c7e1-2b4d-4f8a-b6c2-d9e7f1a3b5c7
status: experimental
description: Detects creation of a kernel driver service from a path outside standard Windows driver directories. Covers both sc.exe usage and direct service creation.
author: SOC Analyst Hub
date: 2026-07-27
tags:
  - attack.defense_evasion
  - attack.t1562.001
  - attack.t1543.003
logsource:
  category: process_creation
  product: windows
detection:
  selection_sc:
    CommandLine|contains|all:
      - 'type=kernel'
    CommandLine|contains:
      - 'create'
    Image|endswith: '\sc.exe'
  filter_system_paths:
    CommandLine|contains:
      - '\Windows\System32\drivers\'
      - '\Windows\SysWOW64\drivers\'
  condition: selection_sc and not filter_system_paths
falsepositives:
  - Legitimate third-party driver installations that stage drivers to temp paths before moving them
  - Security products that load kernel components from their own install directory
level: high

Rule 2 — Kernel Driver Image Load from User-Writable Path

title: Kernel Driver Loaded from User-Writable or Temp Path
id: b8d2e4f6-3c5a-4b7d-a8e1-f2c3d4e5f6a7
status: experimental
description: Detects kernel driver (.sys) image load events originating from paths commonly used by attackers staging malicious drivers.
author: SOC Analyst Hub
date: 2026-07-27
tags:
  - attack.defense_evasion
  - attack.t1562.001
logsource:
  category: driver_load
  product: windows
detection:
  selection:
    Signed: 'true'
    ImageLoaded|contains:
      - '\Users\'
      - '\AppData\'
      - '\Temp\'
      - '\ProgramData\'
      - '\Downloads\'
      - '\Music\'
      - '\Desktop\'
  condition: selection
falsepositives:
  - Security research tools loaded during testing
  - Some legitimate software that installs drivers to non-standard locations
level: high

Rule 3 — Security Process Unexpected Exit

title: Security Process Terminated Unexpectedly
id: c7e5a9b3-4d6f-4c8b-b9a2-e3f5c7d9e1b4
status: experimental
description: Detects when well-known EDR and AV agent processes exit. A clean shutdown generates a different exit pattern; this rule looks for termination without preceding clean-stop events.
author: SOC Analyst Hub
date: 2026-07-27
tags:
  - attack.defense_evasion
  - attack.t1562.001
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4689
    ProcessName|endswith:
      - '\csagent.exe'
      - '\MsMpEng.exe'
      - '\SentinelAgent.exe'
      - '\CylanceSvc.exe'
      - '\cb.exe'
      - '\SophosSAVService.exe'
      - '\cyserver.exe'
      - '\xagt.exe'
      - '\bdagent.exe'
      - '\ekrn.exe'
      - '\avgnt.exe'
      - '\avguard.exe'
  condition: selection
falsepositives:
  - Planned EDR upgrades and maintenance shutdowns
  - Legitimate uninstall operations
level: critical

Rule 4 — AnyDesk Stored in Non-Standard Path

The GodDamn/Hyadina case used AnyDesk hidden in a folder named ‘Music’. This is a specific operational signature worth catching.

title: AnyDesk Executed from Non-Standard Directory
id: d6f8b2c4-5e7a-4d9c-c1b3-f4e6d8f2b1c5
status: experimental
description: Detects AnyDesk running from a non-standard installation path, which may indicate it was dropped as a persistence or remote access mechanism rather than installed legitimately.
author: SOC Analyst Hub
date: 2026-07-27
tags:
  - attack.command_and_control
  - attack.t1219
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith: '\AnyDesk.exe'
  filter_standard:
    Image|contains:
      - '\Program Files\AnyDesk\'
      - '\Program Files (x86)\AnyDesk\'
      - '\AppData\Local\AnyDesk\'
  condition: selection and not filter_standard
falsepositives:
  - Users who have downloaded AnyDesk to a non-standard location
level: medium

KQL Rules (Microsoft Sentinel / Defender for Endpoint)

Kernel Driver Created as Service from Suspicious Path

DeviceProcessEvents
| where Timestamp > ago(24h)
| where ProcessCommandLine has "type=kernel" and ProcessCommandLine has "create"
| where FileName =~ "sc.exe"
| where ProcessCommandLine !has "\\Windows\\System32\\drivers\\"
    and ProcessCommandLine !has "\\Windows\\SysWOW64\\drivers\\"
| project Timestamp, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessFileName
| order by Timestamp desc

Security Processes Terminated (High-Priority)

DeviceProcessEvents
| where Timestamp > ago(1h)
| where FileName in~ (
    "csagent.exe",
    "MsMpEng.exe",
    "SentinelAgent.exe",
    "CylanceSvc.exe",
    "bdagent.exe",
    "ekrn.exe"
    )
| where InitiatingProcessFileName !in~ (
    "services.exe",
    "svchost.exe",
    "msiexec.exe"
    )
| project Timestamp, DeviceName, FileName, InitiatingProcessFileName, InitiatingProcessCommandLine

Driver Image Load from User-Writable Path

DeviceImageLoadEvents
| where Timestamp > ago(24h)
| where FileName endswith ".sys"
| where FolderPath !startswith "C:\\Windows\\System32\\drivers"
    and FolderPath !startswith "C:\\Windows\\SysWOW64\\drivers"
    and FolderPath !startswith "C:\\Program Files"
    and FolderPath !startswith "C:\\Program Files (x86)"
| where IsSigned == true
| project Timestamp, DeviceName, FileName, FolderPath, CertificateSigner
| order by Timestamp desc

HVCI: The Structural Fix

Behavioural detection catches most cases, but HVCI is the architectural defence that prevents this class of attack from working at all on protected systems.

Hypervisor-Protected Code Integrity requires that all kernel-mode code meet integrity requirements enforced by the hypervisor, not just the Windows kernel. On HVCI-enabled systems, the impact of PoisonX and similar drivers is significantly curtailed even if they carry valid signatures.

Windows 11 enables HVCI by default on compatible hardware. Windows 10 systems should be assessed for HVCI compatibility — most modern hardware supports it, and the performance impact on current-generation processors is minimal.

To verify HVCI status:

# Check HVCI enrollment
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard | 
  Select-Object VirtualizationBasedSecurityStatus, CodeIntegrityPolicyEnforcementStatus

Values:

• VirtualizationBasedSecurityStatus: 2 — VBS running
• CodeIntegrityPolicyEnforcementStatus: 2 — HVCI enforced

Organisations that cannot immediately deploy HVCI enterprise-wide should prioritise it on the highest-value endpoints: domain controllers, backup infrastructure, and any system running sensitive workloads.

Detection Priority Summary

1. Kernel driver service creation from non-Windows paths — high confidence, low false positives, catches the loading stage before the driver executes.
2. Security process unexpected termination — critical severity, but requires tuning for maintenance windows to avoid alert fatigue.
3. Driver image load from user-writable paths — useful for identifying where drivers were staged.
4. AnyDesk/RMM tool in non-standard paths — indicator of initial access persistence, not specific to PoisonX but common in affiliated attacks.

The PoisonX case establishes that the assumption “if the driver is legitimately signed, it is safe to load” is not a valid security property. Detection logic must include behavioural signals that fire regardless of signature status.