UAT-10147 and SPECTRE: When EDRs go blind at the kernel level
Last week, Cisco Talos published research on UAT-10147, a Chinese-speaking financially motivated threat actor operating at a scale most defenders are not prepared for. The story has two parts that individually would be significant. Together, they represent a meaningful shift in the threat landscape.
What SPECTRE actually does
SPECTRE is a cross-platform backdoor that pairs a Bring Your Own Vulnerable Driver (BYOVD) technique with a Linux rootkit component. The Windows-side technique is the one worth understanding in detail.
SPECTRE loads two well-documented vulnerable drivers: MSI's RTCore64.sys (CVE-2019-16098) and Dell's DBUtil_2_3.sys (CVE-2021-21551). These are old vulnerabilities. Both are on the Windows driver blocklist. Both appear repeatedly in BYOVD attack reports going back years.
What SPECTRE does with them is surgical. It writes directly to three Windows kernel internal callback arrays: PspCreateProcessNotifyRoutine, PspCreateThreadNotifyRoutine, and PspLoadImageNotifyRoutine. These arrays are how endpoint security products receive notifications about new processes, new threads, and new image loads. By unlinking the security product's callbacks from those arrays, SPECTRE causes the EDR to stop receiving system events for the remainder of the session.
The EDR process keeps running. Its service keeps reporting healthy. Its management dashboard shows clean. It just receives no telemetry about anything happening on the endpoint.
This is not a new class of attack. BYOVD techniques have been documented for years. What makes this notable is the precision: SPECTRE does not crash the product, does not trigger an alert about its own removal, and does not require elevated privileges beyond what the vulnerable driver grants. From the security console's perspective, the endpoint is protected. It is not.
CrowdStrike Falcon, SentinelOne Singularity, and Microsoft Defender are all affected. Talos confirmed customer incidents.
Detection if your EDR is blind
The uncomfortable implication is that post-exploitation detection becomes much harder when your primary telemetry source has been silenced. A few approaches that do not rely on EDR callback coverage:
Driver blocklist enforcement verification. Both RTCore64.sys and DBUtil_2_3.sys should be blocked by Microsoft's vulnerable driver blocklist. The question is whether blocklist enforcement is actually active and updated on your endpoints. Many organizations have the blocklist policy configured but do not verify it is functioning correctly. The Windows Security event log and Sysmon (Event ID 6, driver load) can catch driver loads that EDR misses, because Sysmon uses a different instrumentation path.
Kernel integrity monitoring. Tools that independently monitor the kernel callback arrays, rather than relying on EDR to report on its own status, will surface the anomaly. This is a more advanced detection approach, but Talos's IOC release includes the driver hashes and memory write patterns that detection engineers can work with.
Network indicators. UAT-10147's opsec failure was a staging server exposure that revealed approximately 170,000 target URLs. Network-level blocking of SPECTRE C2 infrastructure remains an option. Talos has published network indicators in the accompanying report.
The AI component
UAT-10147 is using AI-assisted workflows to scale post-compromise operations across its target list. The Talos research describes AI-assisted reconnaissance and lateral movement at a scale that would require significant human operator capacity to replicate manually.
This is the second thread worth taking seriously. Agentic AI in intrusion operations has been discussed as a theoretical near-term risk for a couple of years. UAT-10147 is the first documented case of a financially motivated, non-state actor using it as a routine operational component, not as a one-off experiment.
The target list of 170,000 URLs spanning government, universities, media, technology, and gaming organizations in five countries gives a sense of the operational ambition. AI-assisted scaling is what makes that ambition executable for a non-nation-state actor.
What to do this week
For immediate action: verify that the Windows vulnerable driver blocklist is enforced and updated on all endpoints. Confirm that Sysmon or equivalent kernel telemetry is running independently of your EDR on critical systems. Pull the Talos IOC package and run retrospective hunts for RTCore64.sys and DBUtil_2_3.sys driver loads in the last 90 days.
For the medium term: treat kernel-level BYOVD bypass capability as an assumed adversary technique when designing detection coverage. Do not assume EDR health status equals actual coverage.
Gigia Tsiklauri is a Security Architect and founder of Infosec.ge. Get in touch your team needs help evaluating kernel-level detection gaps.