Skip to content

CVE-2025-0289

BioNTdrv.sys -- Paragon Partition Manager driver exploited by ransomware gangs for SYSTEM escalation

Exploited in the Wild

Microsoft observed ransomware gangs exploiting this vulnerability for SYSTEM privilege escalation via BYOVD.

Summary

Field Value
Driver BioNTdrv.sys (Paragon Hard Disk Manager / Partition Manager)
Vendor Paragon Software
Vulnerability Class Insecure Kernel Resource Access
Exploited ITW Yes (ransomware)
Status Blocklisted by Microsoft; fixed in BioNTdrv.sys v2.0.0

BYOVD Context

  • Driver signing: Microsoft co-signed; loads even if Paragon software is not installed
  • Vulnerable Driver Blocklist: Added to Microsoft's blocklist
  • Related CVEs: CVE-2025-0285 (arb kernel write), CVE-2025-0286 (arb kernel write via unchecked memmove), CVE-2025-0287 (null pointer deref), CVE-2025-0288 (arb kernel write via user-supplied length)

Root Cause

In early 2025, Microsoft identified ransomware operators using a signed Paragon Partition Manager driver as a Bring Your Own Vulnerable Driver weapon. The driver, BioNTdrv.sys versions 1.3.0 and 1.5.1, carried a Microsoft co-signature, meaning it would load on any Windows machine regardless of whether Paragon software was actually installed. That co-signature turned it into a universal privilege escalation tool.

CVE-2025-0289 specifically targets the driver's handling of the MappedSystemVa pointer. When processing certain IOCTLs, the driver passes this pointer to HalReturnToFirmware without first validating whether the mapping is legitimate. An attacker can supply a crafted value that causes the driver to operate on arbitrary kernel resources.

But CVE-2025-0289 was not the only door into this driver. Its siblings, CVE-2025-0285, CVE-2025-0286, and CVE-2025-0288, all provide arbitrary kernel memory writes through unchecked memmove operations with user-controlled lengths. CVE-2025-0287 adds a null pointer dereference for denial of service. Together, the five vulnerabilities paint a picture of a driver that was built as transparent plumbing between user mode and kernel operations, with no adversarial input model whatsoever.

Exploitation

The ransomware playbook followed a well-established pattern. Operators dropped the signed BioNTdrv.sys binary onto target systems and loaded it through standard driver installation APIs. Because the Microsoft co-signature satisfied driver signature enforcement, no test-signing or boot configuration changes were needed.

Once loaded, the attackers had their pick of primitives. The unchecked memmove IOCTLs (CVE-2025-0286 and CVE-2025-0288) gave direct arbitrary kernel writes, the most straightforward path to token manipulation. The MappedSystemVa bug in CVE-2025-0289 provided an alternative route through insecure kernel resource access. Either path led to SYSTEM privileges.

With SYSTEM achieved, the operators deployed their encryption payloads. The entire chain, from driver load to ransomware execution, required no exploitation of memory corruption in the traditional sense. The driver simply did what the attacker told it to do because it never distinguished between legitimate and malicious callers.

Exploitation Primitive

Drop co-signed BioNTdrv.sys onto target
  --> Load via standard driver installation (co-signature satisfies enforcement)
  --> IOCTL with unchecked memmove (CVE-2025-0286/0288) --> arbitrary kernel write
  --> or: IOCTL with unvalidated MappedSystemVa (CVE-2025-0289) --> kernel resource access
  --> Token manipulation --> SYSTEM
  --> Ransomware deployment

Broader Significance

The BioNTdrv.sys cluster represents one of the clearest BYOVD case studies from 2025. A single third-party partition manager, carrying a Microsoft co-signature, shipped five vulnerabilities that collectively gave attackers null derefs, arbitrary kernel writes, and insecure resource access. The response, adding the driver to the Vulnerable Driver Blocklist, is reactive by nature. The deeper question is how many other co-signed utility drivers carry similar primitives and have not yet been weaponized. For defenders, the takeaway is that driver blocklist updates should be treated as critical patching events, not optional hardening.

References