Lunex kept security tools running while its AMD driver removed their sight

The noteworthy step happens before the information stealer starts

On 24 September 2026, Ontinue published its analysis of four recovered files in a Lunex campaign aimed at Ukrainian-speaking users. The delivery began with a fake CAPTCHA page instructing the victim to run an msiexec command. It ended with a stealer capable of collecting browser credentials, session tokens and cryptocurrency-wallet data while polling for further commands.

The unusual component sits between those stages. Before downloading the final stealer, the loader installed PDFWKRNL.sys, a legitimate AMD kernel driver affected by CVE-2023-20598. The malware used the driver's memory-access operations to locate and zero kernel callback entries associated with selected security products.

This is not the same as terminating an antivirus or EDR process. Ontinue says the products may continue running while losing visibility into process creation, thread creation or image loading through the affected callbacks. An operator looking only for a stopped service or dead process could therefore see an apparently healthy product while an important detection channel is absent.

The first two stages are designed to look quieter than their effect

The lure page presents a fake CAPTCHA and tells the victim to execute a Windows Installer command. The retrieved file, elita.msi, is a 1.1 MB unsigned package labelled with a misspelled product name. It installs under the user's local application-data directory, suppresses the normal installer interface and launches its payload through a custom action.

The package itself contains no driver service or embedded malicious DLL. That separation matters for triage: the MSI can look sparse because the next executable holds the operational logic. Ontinue calls that second-stage binary LunexLoader. It encrypts its meaningful strings, spoofs product information and uses dead code to make static import analysis less useful.

The loader first changes process information so it appears to be a trusted Windows binary. It then instantiates the auto-elevating CMSTPLUA COM object. After elevation, it enables SeLoadDriverPrivilege and creates and starts a service for the recovered driver. This sequence takes the process from a per-user installation to kernel-level influence without presenting the expected UAC prompt in the analysed chain.

A signed kernel component converts an administrator foothold into arbitrary memory access

AMD's bulletin describes CVE-2023-20598 as improper privilege management in the Radeon graphics driver. An authenticated attacker can craft an IOCTL request to gain control over hardware ports or physical addresses, with potential arbitrary code execution. AMD rates the issue High and directs users to fixed graphics-driver releases listed for affected products.

Ontinue's analysis is more specific to the recovered binary. PDFWKRNL.sys registers the device path \\.\PdFwKrnl and exposes twelve control codes without access-control checks. The loader uses one operation to read kernel callback-table entries and another to write zeroes over entries owned by drivers on its blocklist.

The loader does not assume that kernel offsets are identical across Windows versions. It reads the kernel build's debug identifier, downloads the matching PDB from Microsoft's symbol service and resolves the symbols required to find callback tables. That design allows the same logic to adapt to the kernel running on the victim rather than relying on one hard-coded layout.

The two driver operations Ontinue observed in the callback-removal loop

Operation	Observed use	Defensive implication
Kernel memory read	Retrieve callback-table entries	Detect unexpected access to the PdFwKrnl device and the recovered driver hash
Owner resolution	Map callback addresses to loaded driver names	Watch for non-development processes resolving kernel symbols and enumerating driver ownership
Kernel memory write	Replace matching callback entries with zeroes	A running security process is not proof that its kernel telemetry remains intact

The target list is about event visibility, not one antivirus brand

Ontinue recovered an encrypted list of twenty driver names covering Microsoft Defender, Microsoft security events, Kaspersky, Dr.Web, ESET, Elastic, Sysmon, CrowdStrike, SentinelOne and the Windows Filter Manager. The presence of fltMgr.sys is especially important because filter-manager callbacks can underpin visibility used by multiple products.

A defence plan built around one vendor name will therefore miss the architectural issue. The malware is looking for callback ownership and removing selected entries. Teams need evidence that the endpoint product is receiving and processing expected kernel events, not merely evidence that its user interface opens and its service process exists.

Ontinue also reports that its testing did not see Hypervisor-Protected Code Integrity or the then-current Microsoft vulnerable-driver blocklist prevent this driver variant from loading. That is a test result for the analysed environment and hash, not a statement that those protections never work. It does show why driver blocking needs telemetry and validation rather than a configuration screenshot alone.

The final payload reaches seven Chromium browsers and becomes a remote agent

After clearing callbacks, the loader downloads LunexStealer. Ontinue says the analysed sample targeted Google Chrome, Microsoft Edge, Brave, Yandex Browser, Opera, Opera GX and Vivaldi. It understood multiple generations of Chromium credential protection, copied browser databases and extracted passwords, cookies, tokens, payment data and autofill records.

The same sample searched for five desktop cryptocurrency wallets and four browser-extension wallets. It also installed a PowerShell-based Native Messaging Host, giving the operator a persistent route to browse the victim's filesystem through the browser integration mechanism.

Its command-and-control protocol did more than accept stolen files. The agent registered a machine fingerprint, retrieved configuration, checked for a kill-switch response, sent heartbeats and polled for download-and-execute tasks. The better description is therefore an information stealer with continuing remote-agent capability, rather than a one-time password grabber.

Detection has to favour the stages before callback removal

Key facts