News Date: 2026-09-26
A Windows malware platform known as Lunex is using a vulnerable AMD kernel driver to quietly blind security software before stealing browser credentials, authentication cookies and cryptocurrency wallet information. The campaign demonstrates how relatively common information-stealing operations are adopting techniques once associated with more advanced intrusions.
From fake verification to kernel access
The infection chain begins when compromised websites display fraudulent Cloudflare verification or CAPTCHA instructions. Victims are persuaded to run commands that retrieve bogus MSI installers, leading to the deployment of LunexLoader.
The loader bypasses Windows User Account Control through the CMSTPLUA COM object and then employs a bring-your-own-vulnerable-driver technique. It loads PDFWKRNL.sys, an AMD Radeon Software driver affected by CVE-2023-20598, to obtain elevated access and interfere with security-related kernel callbacks.
Instead of visibly terminating endpoint protection processes, Lunex can leave them running while disrupting their ability to monitor activity. This makes the attack less obvious to users and administrators who might assume that a running security process remains fully operational.
Persistence extends into the browser
After weakening defenses, Lunex extracts information from multiple Chromium-based browsers and installs several persistence mechanisms. These include a registry startup entry, a hidden scheduled task and a PowerShell-based Chrome native-messaging host.
The native component can survive deletion of the primary stealer, system restarts and browser relaunches. It supports file browsing, reading and writing data, downloading files and executing programs. Lunex also modifies Chrome preferences to inject an extension with broad access to cookies, history, tabs, proxies and web traffic.
Defensive priorities
- Block known vulnerable drivers through application-control policies.
- Monitor unexpected kernel-driver installation and loading events.
- Hunt for unfamiliar Chrome native-messaging hosts and scheduled tasks.
- Train users never to paste verification commands into PowerShell or Run dialogs.
- Revoke browser sessions and rotate exposed credentials after compromise.
Researchers found that existing virtualization-based protections and the current Microsoft vulnerable-driver blocklist did not prevent the observed driver variant from loading. I believe this is the most important part of the report. Organizations cannot assume that enabling one Windows feature closes the vulnerable-driver problem. Driver control must become an actively maintained security program supported by telemetry, deny policies and rapid credential containment.