CVE-2019-16098
MSI RTCore64, physical memory R/W, MSR access, and I/O port access via IOCTL
Summary
| Field | Value |
|---|---|
| Driver | RTCore64.sys |
| Vendor | MSI (Micro-Star International) |
| Vulnerability Class | Arbitrary R/W / Physical Memory Mapping |
| Abused Version | 4.6.2 (shipped with MSI Afterburner) |
| Status | Blocklisted — included in Microsoft Vulnerable Driver Blocklist |
| Exploited ITW | Yes |
The Story
MSI Afterburner is one of the most popular GPU overclocking and monitoring utilities in the world, installed on millions of gaming PCs. Its kernel-mode driver, RTCore64.sys, provides the hardware access needed for reading GPU temperatures, adjusting fan speeds, and modifying GPU clock settings. To accomplish this, it exposes six IOCTLs covering direct physical memory access, MSR read/write, and I/O port operations, all without any access control.
The driver's device object (\Device\RTCore64) has no restrictive ACLs, and each IOCTL accepts user-controlled address and size parameters without validation. The physical memory IOCTLs call MmMapIoSpace with the user-supplied physical address, perform the copy, and unmap. This effectively turns any MSI Afterburner installation into a potential kernel exploitation toolkit.
Barakat published a PoC on GitHub demonstrating the complete exploitation chain. Swapcontext's blog post "Unwinding RTCore" provides detailed reverse engineering of the IOCTL dispatch logic.
What made this driver particularly notable in the threat landscape was its adoption by ransomware groups. BlackByte ransomware used RTCore64.sys to disable EDR kernel callbacks before deploying their payload, zeroing out the callback registration entries so that security products could no longer receive notifications about process creation, file access, or registry modification. Cuba ransomware also leveraged this driver. The combination of MSI Afterburner's massive install base and the driver's clean exploitation interface made it a favorite among threat actors.
BYOVD Context
- Driver signing: Authenticode-signed by Micro-Star International with valid certificate
- Vulnerable Driver Blocklist: Included in Microsoft's recommended driver block rules
- HVCI behavior: Blocked on HVCI-enabled systems via the blocklist
- KDU integration: Integrated as a KDU provider (one of the earliest)
- LOLDrivers: Listed at loldrivers.io with multiple hash variants
Affected IOCTLs
0x80002048— Read physical memory (MmMapIoSpace)0x8000204C— Write physical memory (MmMapIoSpace)0x80002050— Read MSR (RDMSR)0x80002054— Write MSR (WRMSR)0x80002058— Read I/O port (IN)0x8000205C— Write I/O port (OUT)
From Afterburner to SYSTEM
The exploitation path starts with loading RTCore64.sys and opening \\.\RTCore64. The physical memory read IOCTL scans physical memory for the kernel base or known structures. Page table entries are readable via the same IOCTL, enabling virtual-to-physical address translation. Once the current process's EPROCESS structure is located through physical memory, the SYSTEM process token can be read from the EPROCESS linked list and written over the current process's token.
Alternatively, the MSR write IOCTL can redirect syscalls by writing to IA32_LSTAR, providing direct ring-0 code execution on the next syscall. This approach is more powerful but also more detectable by hypervisor-based mitigations.
The BlackByte pattern is different: rather than pursuing SYSTEM tokens, the operators used the physical memory write IOCTL to locate and zero out kernel notification callback arrays, effectively blinding all EDR products on the system before deploying ransomware.
Detection
YARA Rule
rule CVE_2019_16098_RTCore64 {
meta:
description = "Detects MSI RTCore64.sys vulnerable driver"
cve = "CVE-2019-16098"
author = "KernelSight"
severity = "critical"
strings:
$mz = { 4D 5A }
$driver_name = "RTCore64" wide ascii nocase
$device = "\\Device\\RTCore64" wide ascii
$msi = "Micro-Star" wide ascii
condition:
$mz at 0 and $driver_name and ($device or $msi)
}
ETW Indicators
| Provider | Event / Signal | Relevance |
|---|---|---|
| Microsoft-Windows-Kernel-File | Driver load event | Detects loading of RTCore64.sys from non-standard paths |
| Microsoft-Windows-Security-Auditing | Event 4697 — Service installed | Service creation for RTCore64.sys driver |
| Sysmon | Event ID 6 — Driver loaded | Captures driver hash and signature info |
| Microsoft-Windows-Kernel-Process | Process token modification | Token swap after exploitation |
Behavioral Indicators
- Loading of
RTCore64.sysfrom a path unrelated to MSI Afterburner installation DeviceIoControlcalls with IOCTL codes0x80002048-0x8000205Cfrom non-MSI processes- Rapid physical memory read operations spanning the kernel address range
- Process escalation to SYSTEM following RTCore64 driver load and IOCTL activity
- EDR callback zeroing observed after RTCore64 driver interaction (BlackByte pattern)
Broader Significance
RTCore64.sys is the case that connected BYOVD to ransomware in the public consciousness. When BlackByte demonstrated that a GPU overclocking driver could be used to blind all EDR products on a network, it forced the security industry to reckon with the reality that signed vulnerable drivers are not edge cases but standard ransomware tooling. The driver's popularity, appearing in MSI Afterburner installations worldwide, also highlights the scale problem: millions of copies of the signed binary exist, and blocklist enforcement remains inconsistent across enterprise environments.