Detecting BYOVD chains through kernel callback forensics

BYOVD (Bring-Your-Own-Vulnerable-Driver) is the load-time corollary of the older PatchGuard-bypass research from the late 2000s. Rather than developing a 0-day in a new driver, the operator ships a driver Microsoft has already signed — usually a legitimate vendor utility from MSI, Gigabyte, ASUS, Intel, or Capcom — and exploits a known IOCTL handler vulnerability in that driver to obtain arbitrary kernel read/write.

Once that primitive is established, the typical objective in the cheat ecosystem is to walk the PspCreateProcessNotifyRoutine, PspLoadImageNotifyRoutine, and CmCallback arrays and zero out the entries registered by EDR / live anti-cheat drivers — silencing process creation, image load, and registry telemetry from a position no usermode hook can reach.

Microsoft maintains a vulnerable-driver blocklist enforced by HVCI / Memory Integrity, but adoption is not universal: Memory Integrity remains optional on consumer Windows 11 installs and is silently disabled by every BYOVD chain in our corpus that targeted machines with HVCI off. The drivers themselves remain validly signed; revocation alone does not prevent load on a machine that does not check the blocklist.

For the cheat-ecosystem variant of this attack we assume:

• The operator has administrator rights on the target machine. This is the baseline assumption for any cheat that requires a driver load — UAC is not a security boundary against the user.
• The operator may unload the driver and delete the binary after the session. We have observed automated cleaner stages that unload in DriverUnload, run an NtSetSystemInformation(SystemUnloadGdiDriverInformation) sweep, and delete the on-disk image plus its registry service entry.
• The operator may attempt timestomping on CodeIntegrity-Operational.evtx, System.evtx, and the relevant prefetch entries. Most fail to also clear the matching USN journal records and registry transaction logs.
• We do not assume HVCI is enabled. We assume Driver Signature Enforcement (DSE) is enabled — the BYOVD chain itself depends on this to make the signed-but-vulnerable driver load.

Even after the driver has been unloaded and the on-disk binary deleted, six distinct artifact classes preserve enough information to reconstruct the load. The chain below is the canonical sequence we walk for every BYOVD scan:

Operators who only scrub artifact 01 (the event log) will still leave 02–05 intact. Operators who scrub 01 + 03 + 05 still leave Prefetch and the USN journal — timestomping the prefetch $STANDARD_INFORMATION block does not update the $FILE_NAME attribute, which gives us a second-order detection (covered in our companion note on MFT $SI vs $FN delta detection).

The detection logic below is a simplified form of the rule shipped in the Clubhouse AC scanner. Production rules add fuzzy matching on driver name, BTL (build target list) coverage, and a per-tenant allowlist to suppress legitimate vendor utilities that the server administrator has whitelisted.

rule BYOVD_KnownVulnerableDriver
{
  meta:
    severity     = "critical"
    category     = "kernel"
    confidence   = 0.95
    description  = "Known vulnerable driver loaded in current boot session"

  inputs:
    code_integrity := events("Microsoft-Windows-CodeIntegrity/Operational",
                             event_id == 3023)
    prefetch       := prefetch_entries(kernel_mode = true)
    services       := registry("HKLM\\SYSTEM\\CCS\\Services\\*",
                               include_transaction_logs = true)
    usn            := usn_journal(reason ~ /CREATE|DELETE/i)

  match:
    any code_integrity ci where
      sha256(ci.image) in BYOVD_BLOCKLIST_SHA256 or
      ci.signer in BYOVD_BLOCKLIST_SIGNERS

    or any prefetch p where
      p.is_kernel_driver and
      not exists s in services where s.image_path == p.path
      // orphan kernel driver — service entry was deleted

    or correlate(code_integrity, services, usn) where
      ci.image_basename == s.image_basename and
      s.deleted_at is not null and
      ci.timestamp >= s.created_at and
      ci.timestamp <= s.deleted_at + 5m

  emit:
    artifact_chain {
      driver_name      = ci.image_basename
      driver_sha256    = sha256(ci.image)
      first_seen       = min(ci.timestamp, p.first_run, s.created_at)
      last_seen        = max(ci.timestamp, p.last_run,  s.deleted_at)
      service_state    = s.state               // "deleted" if scrubbed
      anti_forensic    = (s.deleted_at != null)
      cve_chain        = lookup(BYOVD_CVE_MAP, sha256(ci.image))
    }
}

The rule fires under three independent conditions, ranked by confidence. A match on the first clause (signed-but-blocklisted image hash) is treated as deterministic. The third clause — the correlation between a code-integrity event, a deleted service, and matching USN journal records — is the one that survives most cleaners.

We validated the rule against:

The seven families observed in the corpus, in descending frequency: mhyprot2.sys (miHoYo Genshin Impact anti-cheat — arbitrary kernel R/W via IOCTL, weaponised by 58% of the cheats we tracked after its public disclosure in 2022), gdrv.sys (GIGABYTE — CVE-2018-19320), dbutil_2_3.sys (Dell firmware update utility — CVE-2021-21551, five distinct vulnerabilities in one binary), iqvw64e.sys (Intel NIC diagnostic driver — CVE-2015-2291), plus three private drivers signed under stolen or grey-market certificates.

All three false positives were legitimate vendor utilities running on enthusiast rigs (one MSI Afterburner, two ASUS RGB tools). Adding the binary path to the per-tenant allowlist suppressed the alert without disabling the rule globally.

For server administrators evaluating their own population:

• Require HVCI / Memory Integrity where game compatibility allows. Microsoft's vulnerable-driver blocklist is enforced only when HVCI is on. This is the single highest-impact mitigation.
• Block known vulnerable drivers explicitly via Windows Defender Application Control (WDAC) policy. Microsoft publishes the blocklist as a downloadable WDAC policy that can be deployed standalone.
• Preserve the audit trail. Increase CodeIntegrity-Operational.evtx max size to at least 256 MB and forward to a remote collector. The default 1 MB rolls within hours on a busy machine.
• Run forensic scans on a delayed cadence — not just when a player is suspected. Operators who clean immediately after a cheat session may leave the artifacts intact between sessions.

1. Microsoft. Recommended driver block rules. Microsoft Learn, 2024. Maintained blocklist enforced by HVCI / Memory Integrity.
2. Microsoft. Code Integrity event reference. Event IDs 3023, 3024, 3033 in Microsoft-Windows-CodeIntegrity/Operational.
3. H. Carvey. Windows Forensic Analysis Toolkit, 4th ed. Syngress, 2014. Foundational reference for Prefetch, Amcache, and ShimCache structure.
4. A. Schuster. Searching for Processes and Threads in Microsoft Windows Memory Dumps. DFRWS 2006. The pool-tag scanning technique underlying our memory-side callback enumeration.
5. MITRE ATT&CK. T1068 — Exploitation for Privilege Escalation and T1014 — Rootkit. Cross-references for the BYOVD technique and EDR callback removal.