Attackers altered legitimate Ukrainian business websites so that visitors saw a fake Cloudflare check. Anyone who followed its instructions pasted a Windows Installer command into the Run dialog and installed a loader. That loader took over a signed AMD driver and wiped the kernel callbacks of up to 20 security drivers. Endpoint protection kept running. It simply stopped receiving events.
Only then did the final payload arrive. Lunex Stealer, also tracked as Psychedelic Stealer, takes saved passwords, cookies and card data from seven browsers. It also copies data from nine cryptocurrency wallets. In addition, it plants a backdoor inside the browser that survives deletion of the stealer itself. The platform behind it has grown to 28 control panels in 13 countries.
What is Lunex Stealer? Lunex Stealer is an information stealer sold through Lunex, a malware-as-a-service platform run by Russian-speaking developers. In the campaign analyzed this September, it arrived after a bring-your-own-vulnerable-driver (BYOVD) chain had silenced endpoint security. It doubles as a remote access agent.
Hacked Business Sites and a Fake Cloudflare Check
Ordinary businesses owned the compromised sites. Among them were a hair-treatment clinic, a scale-model manufacturer, a specialist bookseller, a psychological facility, a tool retailer and an automotive retailer. Each carried an injected iframe that loaded the lure. Visitors saw a page written in Ukrainian, while its HTML declared Russian as the document language.
Clicking the fake CAPTCHA silently copied an msiexec command to the clipboard. On-screen instructions then told the visitor to press Windows+R, paste and hit Enter. The “Done” button stayed disabled for about 35 seconds, which served no technical purpose. It only bought time for the victim to comply.
The chain never calls PowerShell, so it sidesteps security rules tuned to catch malicious PowerShell one-liners.
An exposed management panel branded Rublevka TDS tracked the funnel. It logged 557 views, 426 clicks and 79 “complete” events across 32 countries, with Ukraine accounting for 446 views. A complete event only means someone pressed Done, so it is not a confirmed infection count. The operators registered the delivery domain uasputnik[.]com on September 9, 2026. Lure URLs using it then appeared on September 12 and 13.
An Installer Designed to Stay Out of Sight
The package, elita.msi, has no signature. Its properties call it “Vertification” from “Internal Software”, a misspelling that mirrors the Ukrainian word on the lure page, next to a vendor name that could pass for an in-house IT tool.
Nothing about the install asks for administrator rights. Everything goes into a per-user folder under %LOCALAPPDATA%, so Windows never shows a UAC prompt, and the usual installer wizard never appears either. Its Add/Remove Programs entry shows no Modify or Repair buttons. A custom action starts the payload as soon as installation finishes; if that launch fails, the installer still reports success.
The MSI carries no malicious code of its own. Its only job is to put the loader on disk and start it.
Signed, Vulnerable and Already Inside the Kernel
Bring Your Own Vulnerable Driver. An attacker installs a legitimately signed but flawed driver, then uses its flaw to act inside the Windows kernel.
A notification Windows sends to registered drivers when a process starts, a thread is created or an image loads. Security products rely on them to see activity.
A control code a program sends to a driver to ask it to act. A driver that accepts IOCTLs without access checks lets any program borrow its powers.
A driver that plugs into the Windows Filter Manager to watch file activity. Most antivirus and EDR file monitoring works this way.
Hypervisor-protected Code Integrity. A Windows feature that restricts which code is allowed to run in the kernel.
A Microsoft-maintained list of drivers Windows refuses to load because they are known to be abusable.
| Terminating security processes | Zeroing kernel callbacks | |
|---|---|---|
| What the attacker does | Kills the agent’s processes through the driver | Removes the agent’s kernel notifications and leaves the processes running |
| What an administrator sees | An agent that stopped or went offline | An agent that looks healthy |
| What the console shows | A missing or stopped agent | Normal status, with fewer or no events |
| What it takes | A driver that can end protected processes | A driver with kernel read and write, plus exact offsets for the running Windows build |
| Product | Version | Status |
|---|---|---|
| Radeon Software Adrenalin Edition | Before 23.9.2 | Affected |
| Radeon Software Adrenalin Edition | 23.9.2 and later | Fixed |
| Radeon Software PRO Edition | Before 23.Q4 | Affected |
| Radeon Software PRO Edition | 23.Q4 and later | Fixed |
Updating is not enough. An attacker can bring an old copy of the driver along, so blocking depends on whether Windows refuses to load that specific file.
From User Mode to Kernel Without a UAC Prompt
On disk, the loader claims to be Canonical’s “Update Manager”, a product that does not exist on Windows. The compile timestamp says 2054. AES encryption covers every string that matters.
Getting from an ordinary user process to the kernel takes four moves, and none of them trigger a UAC prompt. The loader starts by rewriting its own process environment block until it looks like a Windows binary. That disguise is exactly what the auto-elevating CMSTPLUA COM object checks for, so the loader can ask it for administrator rights and get them silently. With those rights it switches on SeLoadDriverPrivilege. Finally, it registers and starts a service to load the driver, which it has carried all along inside an encrypted blob that makes up 91% of its file size.
One more preparation step happens before any kernel write. The loader pulls the build identifier out of ntoskrnl.exe and hands it to curl.exe, which fetches the matching debug symbols from Microsoft’s public symbol server while mimicking legitimate symbol traffic. With those symbols in hand, it knows where the callback tables sit on that particular build, and it needs no hardcoded offsets on any Windows 10 or Windows 11 machine.
Zeroing Callbacks Instead of Killing Processes
Abused here is PDFWKRNL.sys, an AMD component affected by CVE-2023-20598, rated 7.8. Its control handler exposes 12 IOCTL codes and performs no access checks on any of them. Two are enough: one reads kernel memory, the other writes it.
The loader reads each callback table entry and identifies which driver owns it. It then compares each owner against an encrypted blocklist of 20 security drivers. Whenever an owner matches, the loader overwrites that entry with zeroes. Nine of the 20 belong to two Russian antivirus products. The rest include the built-in Windows antivirus filter, Sysmon and several major endpoint products. Last on the list is fltMgr.sys, the Windows Filter Manager itself, which underpins every minifilter-based security tool regardless of vendor.
This copy changed after AMD signed it. Its Authenticode hash no longer matches the signature, yet Windows still loads it because the certificate chain and timestamp validate. Testing published with the analysis showed that neither HVCI nor Microsoft’s vulnerable driver blocklist stopped this variant from loading. The gap persists even though the LOLDrivers project has listed its hash since March 2026.
We covered a different use of a vulnerable driver in EnCase BYOVD EDR Killer: Old Forensic Driver Disables Endpoint Security Tools. That tool terminated security processes outright. Lunex leaves them alive and deaf. Nothing looks like a stopped agent, and no service goes missing.
What the Stealer Takes
The final payload carries a compile date of September 12, 2026, two days before the incident where it surfaced. It targets Chrome, Edge, Brave, Yandex Browser, Opera, Opera GX and Vivaldi. The stealer first force-closes each browser so that its database files unlock.
Key recovery covers three generations of Chrome’s local encryption, including the App-Bound Encryption introduced in July 2024. For that one, the stealer injects shellcode into a suspended Chrome process. The shellcode requests the key from Chrome’s own elevation service.
Saved passwords, session cookies, card numbers and autofill entries all leave over plain HTTP to the operator’s panel. Wallet data from five desktop apps and four browser extensions travels separately, packed into a ZIP archive.
A Backdoor Inside the Browser
Persistence runs through three channels. A registry Run key and a hidden scheduled task named psychedelicloveUtils both relaunch the stealer at logon.
The third channel matters most. Here the stealer registers a Chrome and Edge Native Messaging Host backed by a 13,200-byte PowerShell script. Through it, operators can list drives and folders, read and write any file, download data and run programs. The host operates inside the browser’s process context. Deleting the stealer binary, rebooting or restarting the browser leaves it in place.
The stealer also adds a malicious extension. For that, it defeats the integrity check on Chrome’s Secure Preferences file and enables developer mode. The extension gets access to cookies, history, tabs, proxy settings and every HTTP and HTTPS site.
One Platform, Many Operators
Lunex was first mapped in June 2026, when six panels were visible in five countries. By September the count reached 28 panels across 13 countries, six of them in Russia.
The operator interface ships with Russian as its default language and more than 150 Russian-language strings. Separate stealer builds written in Rust, C and .NET talk to the same panel design. Lunex is a product sold to several crews, not a single malware family. One panel in Turkey resolved to five phishing domains impersonating brands such as Sam’s Club and WhatsApp. A different operator than the Ukrainian one appears to run it.
Operational security was poor. The exfiltration server exposed phpMyAdmin with the root database user visible, and no C2 port used TLS. Careful malware engineering next to careless hosting suggests the developer and the operators are different people. The operators may also treat the servers as disposable.
Enforcement Before the Sensor Goes Deaf
Every step that mattered in this chain happened before the stealer ran. When it finally arrived, the endpoint agent was still up, but the kernel had stopped feeding it events, so there was nothing left for it to judge.
Execution Governance deals with the loader rather than the payload. That loader, dropped by elita.msi, had no signature and no reputation, and it claimed to be a Canonical tool Windows has never had. Without a trust verdict, it would run under Kernel API Virtualization on a Windows endpoint, which virtualizes its file system, registry and service operations. Loading PDFWKRNL.sys depends on creating a service. It would get no outbound sockets either.
The logs tell the difference too. An EDR agent with its callbacks wiped has nothing to report. Enforcement records what the unknown process attempted and what it could reach, and that record survives. Security teams still need EDR for the investigation that follows.
Conclusion: The EDR Was Running. The Sensor Was Blind.
Lunex demonstrates a more dangerous form of endpoint evasion than simply terminating a security product. The attack leaves endpoint protection running while removing the kernel callbacks that supply much of the activity it depends on. From an operational dashboard, the agent may still appear healthy. From the attacker’s perspective, however, the endpoint has stopped reporting what happens next.
The decisive stage occurs before Lunex Stealer ever arrives. A fake Cloudflare check convinces the victim to paste an msiexec command into the Windows Run dialog. The resulting unsigned loader silently gains elevated rights, loads a vulnerable AMD kernel driver, and uses its kernel read and write capabilities to zero callbacks belonging to security products. Only after that visibility has been weakened does the stealer collect browser passwords, cookies, payment data, cryptocurrency wallets, and establish persistent access inside the browser.
This changes the defensive priority. If protection depends entirely on recognizing the final payload, the attacker has already interfered with the mechanism expected to observe it. The stronger control point is the earlier unknown loader and the privileged operations it attempts before the sensor goes blind.
Why This Threat Matters
- A running security agent does not guarantee working telemetry. Lunex attacks the callbacks feeding endpoint visibility rather than simply killing the process.
- BYOVD turns legitimate kernel access into an attack primitive. A vulnerable signed driver provides capabilities ordinary user-mode malware does not have.
- The final payload arrives after defenses are weakened. The stealer benefits from security degradation performed earlier in the chain.
- Browser compromise survives simple malware removal. Native Messaging Host persistence and a malicious extension can remain after the original stealer binary is deleted.
- The attack begins with human execution. A fake verification page persuades the user to paste and run the command that starts the entire chain.
Where Defensive Control Must Operate
Xcitium Advanced EDR, powered by Xcitium’s patented Zero-Dwell platform, addresses the initial unknown loader before it can turn privileged execution into driver loading, persistence, and follow-on malware activity.
Execution Governance is especially important here because enforcement must occur before kernel telemetry is impaired. The question is whether the unsigned loader should be permitted to create services, modify the system, load a driver, or establish network access in the first place.
Xcitium Cyber Awareness Education teaches users to reject fake CAPTCHA and verification workflows that request Run-dialog commands, while Phishing Simulation tests whether employees actually resist those ClickFix-style instructions under realistic conditions.
Govern the Loader Before Visibility Disappears
Defenders should investigate this chain from the first user-executed installer, not only from the final stealer. Restrict unknown processes before they can create services or load drivers, monitor unusual driver activity and browser Native Messaging registrations, and treat an unexpectedly quiet EDR sensor as a potential security condition rather than evidence that nothing happened. Detection remains essential after the event, but enforcement has to act before the attacker can interfere with detection itself.
