CVE-2025-3464
AsIO3.sys — authorization bypass via hardlink attack enables decrement-by-one primitive and SYSTEM escalation
Summary
| Field | Value |
|---|---|
| Driver | AsIO3.sys |
| Vendor | ASUS |
| Vulnerability Class | Authorization Bypass / Arbitrary Decrement |
| TALOS ID | TALOS-2025-2150 |
| Exploited ITW | No |
| Status | Blocklisted |
Affected Functions
ImageHashCheck(called fromIRP_MJ_CREATEhandler)ObfDereferenceObject(abused via IOCTL0xa0402450)ZwQueryInformationProcess(used in authorization)
Root Cause
The driver restricts device access to authorized processes by verifying the SHA256 hash of the requesting executable. In IRP_MJ_CREATE, the handler calls ZwQueryInformationProcess to obtain the process image path, then ImageHashCheck computes the SHA256 hash of the file at that path and compares it against a hardcoded hash (c5c176fc...), corresponding to AsusCertService.exe.
The flaw is that EPROCESS.ImageFileName records the path used at process creation, but the file at that path can be replaced after the process starts. An attacker exploits this with a hardlink attack:
- Create a hardlink pointing to the attacker's executable
- Launch the process via the hardlink (EPROCESS records the hardlink path)
- While running, delete the hardlink and recreate it pointing to
AsusCertService.exe - Open the device — the driver hashes the file at the recorded path, which is now
AsusCertService.exe - Hash matches; device access is granted to the attacker's process
Vulnerable Code Path
IRP_MJ_CREATE
→ ZwQueryInformationProcess (gets image path from EPROCESS)
→ ImageHashCheck (reads and hashes the file at that path)
→ SHA256 comparison against hardcoded AsusCertService.exe hash
→ PASS (file was swapped via hardlink after process creation)
Exploitation
With the authorization bypass granting device access, the attacker can invoke any of the driver's IOCTLs. Marcin Noga at Cisco Talos developed the full exploitation chain, which proceeds as follows:
Step 1: KTHREAD Address Leak
Use NtQuerySystemInformation with handle enumeration to locate the current thread's KTHREAD address in kernel memory. This works on Windows builds before 24H2 (build 26100.3476), which added restrictions preventing regular users from leaking kernel module addresses through this API.
Step 2: PreviousMode Decrement via ObfDereferenceObject
IOCTL 0xa0402450 calls ObfDereferenceObject on an attacker-supplied address. ObfDereferenceObject decrements the value at (object - 0x30) by 1 — this is the reference count field in the _OBJECT_HEADER preceding the object body.
The PreviousMode field sits at offset 0x232 in KTHREAD. Its default value is 1 (UserMode). By passing KTHREAD + 0x232 + 0x30 as the object address, ObfDereferenceObject decrements the byte at KTHREAD + 0x232 from 1 to 0 (KernelMode).
With PreviousMode set to 0, all subsequent ProbeForRead and ProbeForWrite calls become no-ops. The thread now has kernel-level access to Nt* system calls, enabling full address space reads and writes.
Step 3: Locate SYSTEM Token via ActiveProcessLinks
With kernel read access:
- Read
KTHREAD.ApcState.Processto get the currentEPROCESSaddress - Walk the
ActiveProcessLinksdoubly-linked list - Find the SYSTEM process (PID 4)
- Read the SYSTEM process's
_TOKENpointer
Step 4: Token Swap
Replace the current process's token pointer with the SYSTEM token. Increment the SYSTEM token's reference count to prevent a BSOD during process teardown. Launch cmd.exe as NT AUTHORITY\SYSTEM.
Exploitation Primitive
Hardlink auth bypass (CVE-2025-3464)
→ Device handle to AsIO3.sys
→ IOCTL 0xa0402450 (ObfDereferenceObject)
→ Decrement-by-one at arbitrary kernel address
→ PreviousMode 1→0 (UserMode → KernelMode)
→ Full kernel R/W via Nt* syscalls
→ ActiveProcessLinks traversal → SYSTEM token
→ Token swap → NT AUTHORITY\SYSTEM
Other Driver Capabilities
The driver exposes additional primitives that were considered but not used in the final chain:
| IOCTL | Capability | Limitation |
|---|---|---|
0xA040200C |
Physical memory mapping (MmMapIoSpace) | checkPhyMemoryRange restricts to predefined g_goodRanges; blocks Low Stub and arbitrary phys-to-virt translation |
0xA040A45C |
MSR register read/write | Allowlist filtering excludes critical registers (IA32_LSTAR at 0xC0000082, IA32_SYSENTER_EIP at 0x176) |
0xa0402450 |
ObfDereferenceObject on controlled address |
Used in the exploit — provides decrement-by-one primitive |
The physical memory IOCTL has range filtering (g_goodRanges), and the MSR IOCTL has an allowlist. The researchers note that allowlist-based filtering (rather than blocklist) is the stronger approach, but even the allowlist here did not prevent exploitation via the ObfDereferenceObject path.
Windows Mitigations Encountered
The initial exploit was developed on build 22621.4890. The Windows 11 24H2 update (build 26100.3476) added a mitigation that prevents regular users from leaking kernel module and thread addresses via NtQuerySystemInformation, closing the KTHREAD address leak used in Step 1. This broke the exploit on updated systems.
Patch Analysis
Fix the authorization mechanism to use multiple verification layers rather than relying solely on file hash comparison. The hardlink attack works because the driver trusts the file system path recorded in EPROCESS without verifying the process image integrity at the time of access.
Stronger approaches include:
- Verify the in-memory image hash (not the on-disk file)
- Use code integrity APIs (
CI.dll) to validate the caller - Restrict device access to specific privileged users or groups
- Remove or restrict the
ObfDereferenceObjectIOCTL entirely
Detection
YARA Rule
rule CVE_2025_3464_AsIO3 {
meta:
description = "Detects AsIO3.sys versions vulnerable to authorization bypass"
cve = "CVE-2025-3464"
author = "KernelSight"
severity = "critical"
strings:
$mz = { 4D 5A }
$driver_name = "AsIO3" wide ascii nocase
$hash_func = "ImageHashCheck" ascii
$cert_svc = "AsusCertService" wide ascii
$sha256_hash = { c5 c1 76 fc 0c bf 4c c4 e3 7c 84 b6 23 73 92 b8 }
condition:
$mz at 0 and $driver_name and ($hash_func or $cert_svc or $sha256_hash)
}
ETW Indicators
| Provider | Event / Signal | Relevance |
|---|---|---|
| Microsoft-Windows-Kernel-File | Hardlink creation / deletion | Rapid hardlink create-delete-recreate cycle targeting a signed executable |
| Sysmon | Event ID 11 — File created | Hardlink creation to AsusCertService.exe |
| Microsoft-Windows-Kernel-Process | Process token modification | Token pointer swap after PreviousMode flip |
| Microsoft-Windows-Security-Auditing | Event 4672 — Special Privileges | SYSTEM privileges appearing in a non-elevated process |
Behavioral Indicators
- Hardlink creation targeting
AsusCertService.exefollowed by device open to\\.\AsIO3 - Rapid hardlink delete and recreate from a non-ASUS process
NtQuerySystemInformation(SystemHandleInformation)calls preceding IOCTL activity to AsIO3- Process token changing to SYSTEM token without UAC elevation
- Non-ASUS process sending IOCTL
0xa0402450to the AsIO3 device
Techniques Used
| Technique | KernelSight Page |
|---|---|
| Arbitrary Decrement (ObfDereferenceObject) | Arb Increment/Decrement |
| PreviousMode Manipulation | PreviousMode Manipulation |
| Token Swapping | Token Swapping |
| KASLR Bypass (NtQuerySystemInformation) | KASLR Bypasses |
Timeline
| Date | Event |
|---|---|
| 2025-06-26 | Talos publishes full analysis and exploit chain |