The newly analyzed Lunex Stealer campaign demonstrates why Bring Your Own Vulnerable Driver attacks remain such a difficult problem for endpoint security. The malware chain does not rely on an unsigned kernel implant or a newly discovered Windows zero-day. Instead, it abuses a legitimate AMD kernel driver with dangerous capabilities, allowing the attackers to interfere with endpoint-security monitoring before deploying the final credential-stealing payload.

According to Ontinue, the campaign is part of the wider Lunex Malware-as-a-Service platform and has primarily targeted Ukrainian-speaking users. The attack chain begins with a fake CAPTCHA or ClickFix-style lure, continues through staged PowerShell execution, and eventually deploys an information stealer capable of harvesting browser credentials, cryptocurrency wallets, and other sensitive data. Before that final-stage malware runs, however, the attackers load the AMD driver PDFWKRNL.sys and use it as the foundation for a BYOVD attack intended to disable security-product callbacks at the kernel level.

The significance of this approach is straightforward: the attacker is attempting to blind the security software before the most valuable malicious activity begins. Traditional antivirus or EDR products may detect the initial stages, but if the vulnerable driver successfully disrupts their kernel callbacks, later credential theft and persistence can occur with substantially reduced visibility.

The AMD driver is legitimate, but its capabilities are dangerous

The abused file is AMD’s USB-C Power Delivery Firmware Update Utility Driver, identified as PDFWKRNL.sys. Ontinue found that the driver is legitimately signed through a certificate chain involving AMD, Sectigo, USERTrust, and Microsoft’s Code Verification Root.

That signature matters because Windows trusts signed kernel drivers far more readily than random unsigned malware. The attacker therefore gains an important advantage: instead of writing a malicious driver and immediately fighting Windows kernel-signing protections, they bring an already trusted driver into the environment and abuse its exposed functionality.

This is the essence of BYOVD.

The driver itself is not malware.

The attacker weaponizes legitimate but dangerous kernel functionality.

The driver exposes 12 IOCTL interfaces without access controls

Ontinue’s reverse engineering identified 12 IOCTL control codes exposed through a device named:

\\.\PdFwKrnl

Critically, the driver does not perform appropriate access-control checks on those interfaces.

This means a user-mode process can send specially crafted requests to the driver and gain capabilities that would normally require kernel-level access.

AMD previously documented a related privilege-management issue in the Radeon graphics kernel driver as CVE-2023-20598, where an authenticated attacker could craft IOCTL requests to gain control over arbitrary hardware ports or physical addresses and potentially achieve arbitrary code execution.

The Lunex campaign demonstrates why such driver flaws remain valuable to malware authors long after initial disclosure.

Kernel access changes the balance against security products

Endpoint-security products rely heavily on kernel callbacks to observe sensitive activity.

Windows security products commonly register callbacks for events such as process creation, thread creation, image loading, registry modifications, and object access.

These mechanisms allow EDR platforms to detect activity such as credential theft, code injection, suspicious process chains, persistence changes, or malicious child processes.

If malware can manipulate or disable those callbacks from kernel mode, the security product may continue running visually while losing part of its telemetry.

That can be substantially more dangerous than simply terminating the EDR process.

A user or administrator may still see the security agent running and assume the endpoint remains protected, even though important monitoring capabilities have been disabled underneath it.

Lunex uses BYOVD before deploying the stealer

Ontinue specifically notes that BYOVD is not a new technique, but its placement in this chain is unusual.

Vulnerable drivers have frequently been used by ransomware operators, EDR-killer tools, and post-exploitation frameworks.

Using one before an information stealer is less common.

The attack flow becomes:

fake CAPTCHA → PowerShell execution → staged loader → vulnerable AMD driver → kernel monitoring disabled → Lunex Stealer → credential theft and persistent remote access

This sequencing is deliberate.

The attackers want the endpoint-security product impaired before the stealer starts accessing password databases, cryptocurrency wallets, browser profiles, and other high-value information.

The final stealer targets seven Chromium-based browsers

Once security monitoring has been weakened, Lunex Stealer collects information from multiple Chromium-based browsers.

Ontinue says the malware can extract credentials and browser-related data from seven Chromium-family browsers, together with cryptocurrency wallet information and other stored secrets.

The campaign therefore targets exactly the sort of information modern infostealer operators can monetize quickly: passwords, cookies, authenticated sessions, cryptocurrency information, and other credentials that may provide access to online services.

In corporate environments, browser data can also contain access to SaaS platforms, email systems, cloud consoles, developer tools, and internal web applications.

One infected workstation can therefore expose significantly more than personal browser passwords.

The malware also creates persistent browser-based remote access

One of the more interesting components is a PowerShell-based Native Messaging Host installed into the victim’s browser environment.

The relevant registry path identified by Ontinue includes:

NativeMessagingHosts\com.lunex.explorer

This allows the malware to maintain persistent access to the filesystem through browser-native messaging functionality.

That creates a second problem for incident response. Removing the primary stealer binary may not eliminate the attacker’s foothold if the Native Messaging Host remains installed.

Ontinue therefore recommends treating this registry artifact as a high-value indicator during remediation.

The campaign is more than a single stealer family

Lunex appears to be a broader Malware-as-a-Service platform rather than one fixed malware codebase.

Earlier OSINT research identified six active Lunex panels across five countries. Ontinue’s later Internet-wide scanning found 28 panels across 13 countries, indicating substantial growth in the infrastructure.

Researchers also observed different malware implementations communicating with the same general panel architecture. Earlier research documented a Rust-based stealer, while the sample analyzed by Ontinue was written in C and compiled with MinGW-w64.

That supports the assessment that Lunex is better understood as a platform sold to multiple operators rather than one tightly controlled malware family.

This distinction matters because indicators associated with one sample may not apply to every campaign using Lunex infrastructure.

The threat appears financially motivated

Ontinue assesses with confidence that the activity is associated with a financially motivated, CIS-aligned actor operating through the Lunex platform.

The infrastructure contains Russian-language operator-interface strings, and the malware includes capabilities consistent with information theft and banking-fraud activity.

However, these indicators should not be converted into state attribution.

Russian-language artifacts and CIS targeting patterns may help characterize the criminal ecosystem, but they do not prove government sponsorship or operator nationality.

The AMD driver has reportedly been modified after signing

Ontinue discovered another concerning detail: the driver image used in the campaign had been modified after signing.

Its Authentihash did not match the digest embedded in the signature.

Despite that mismatch, Windows still loaded the driver because the certificate chain remained valid and the countersignature timestamp fell within the certificate’s validity period.

This illustrates an uncomfortable limitation of relying on signature status alone.

A signed file does not automatically mean:

“This exact binary is safe.”

It means a signing relationship exists that Windows considers valid under its trust rules.

Attackers have repeatedly demonstrated that signed or previously trusted drivers can still become extremely effective offensive tools.

Microsoft’s vulnerable-driver protections did not stop this sample

Perhaps the most important defensive finding is that Ontinue’s testing showed neither Hypervisor-Protected Code Integrity (HVCI) nor Microsoft’s current Vulnerable Driver Blocklist prevented the specific PDFWKRNL.sys variant used in the campaign from loading.

That is notable because the driver hash had already been catalogued by the LOLDrivers project since March 2026.

This creates a difficult defensive gap.

Organizations may believe that enabling HVCI and Microsoft’s vulnerable-driver protections provides comprehensive protection against BYOVD attacks.

They help.

They do not guarantee it.

Driver blocklists inevitably lag behind the constantly expanding population of legitimate but exploitable kernel drivers.

BYOVD remains attractive because attackers inherit kernel trust

The economics of BYOVD are compelling for attackers.

Developing and signing a malicious kernel driver is difficult.

Finding an older legitimate driver with a dangerous IOCTL interface is much easier.

The attacker can then load the trusted driver and issue requests from ordinary user mode to gain privileged capabilities.

This turns vendor-signed software into an unintended privilege-escalation framework.

Recent campaigns have demonstrated the same concept using drivers from multiple vendors, including cases where Microsoft-signed or hardware-certified drivers were used to terminate endpoint-security products.

The problem is therefore much larger than AMD or Lunex.

Driver trust should be treated as a privilege boundary

Organizations should increasingly treat kernel drivers as highly privileged software rather than ordinary dependencies.

A driver has access far beyond that of a normal application.

Driver inventory, version management, signing provenance, blocklisting, and runtime behavior should therefore receive much greater attention.

Security teams should know which drivers are present on endpoints, whether they are required, whether vulnerable versions exist, and whether an unknown process suddenly installs or starts a kernel service.

Detection needs to happen before EDR visibility disappears

Ontinue emphasizes that the strongest detection opportunities occur before the BYOVD stage successfully disables security monitoring.

Once kernel callbacks are removed or impaired, defenders may lose exactly the telemetry that would ordinarily expose the final payload.

Useful early-stage indicators include unusual PowerShell execution, suspicious downloads of PDB or driver-related files from non-development processes, driver files being dropped into temporary directories, and creation of kernel-driver services from non-standard filesystem paths.

That temporal ordering matters.

Security controls should not only look for the stealer.

They should identify the preparatory activity that attempts to blind the security stack.

Driver service creation is particularly important

Loading a kernel driver typically requires creating or starting a Windows service of type SERVICE_KERNEL_DRIVER.

Security teams should therefore monitor for new driver services, especially where the binary originates from:

  • %TEMP%;
  • %APPDATA%;
  • user-profile directories;
  • browser download directories;
  • newly created folders;
  • or other non-standard locations.

A legitimate hardware driver normally arrives through predictable installer and update processes.

A random executable creating a kernel service for an AMD driver from a temporary directory should be extremely unusual.

Native Messaging Host persistence provides a strong post-compromise indicator

Once the EDR-blinding phase is complete, the browser Native Messaging Host becomes one of the more durable artifacts.

Organizations should search for the registry key associated with:

com.lunex.explorer

and inspect browser Native Messaging Host configurations for unfamiliar entries.

Security teams should also review scheduled tasks, Run keys, PowerShell persistence, and other components associated with the Lunex chain.

Removing only the stealer executable may leave additional access behind.

Credential rotation is necessary after confirmed infection

If Lunex Stealer executes successfully, organizations should assume browser-stored credentials and active sessions may have been exposed.

That can require rotation or invalidation of:

  • browser passwords;
  • authentication cookies;
  • SaaS sessions;
  • cloud credentials;
  • cryptocurrency wallet secrets;
  • developer tokens;
  • VPN credentials;
  • and other credentials accessible from the user profile.

The important point is that cleaning the endpoint does not invalidate credentials already stolen by the attacker.

A successful infostealer compromise should therefore be treated as an identity-security incident as well as an endpoint incident.

Fake CAPTCHA and ClickFix remain effective delivery mechanisms

The campaign also reinforces the continuing success of fake CAPTCHA and ClickFix techniques.

Instead of exploiting a browser vulnerability, attackers convince the victim to execute a PowerShell command manually.

That action then begins the multi-stage compromise.

The social-engineering message is simple enough for users to understand: a legitimate CAPTCHA or Cloudflare verification page should never require you to open PowerShell, Windows Run, Terminal, or Command Prompt and execute a command.

Any verification page requiring operating-system command execution should be considered malicious.

The broader cybersecurity lesson

Lunex demonstrates how modern malware increasingly attacks the security stack before attacking the data.

The information-stealing functionality itself is familiar.

Browser credentials, cryptocurrency wallets, sessions, and stored secrets have been targeted by hundreds of malware families.

What makes this campaign noteworthy is the preparatory stage:

bring a vulnerable signed driver → gain kernel capability → disable security monitoring → deploy the stealer under reduced visibility.

That changes the defender’s job.

Endpoint security can no longer assume that the operating-system telemetry it depends on will always remain available.

The monitoring mechanism itself has become part of the attack surface.

The broader attack chain can therefore be summarized as:

fake CAPTCHA → PowerShell → staged loader → AMD PDFWKRNL.sys BYOVD → kernel callbacks disabled → Lunex Stealer → credential theft → browser-based persistent remote access

The most important lesson is not simply to block one AMD driver hash.

Attackers can replace it with another vulnerable driver.

The durable defensive strategy is to identify the behavior of BYOVD attacks: unexpected driver deployment, suspicious kernel-service creation, unusual privileged device access, EDR telemetry suddenly disappearing, and high-risk credential activity immediately afterward.

A signed driver should be considered trusted only for the purpose and environment in which it was intended to operate, not automatically trusted simply because Windows is willing to load it.

Lunex is another reminder that once malware reaches kernel level, the defender may lose visibility before losing the credentials.

The Psychedelic Stealer malware distributed via compromised Ukrainian websites using ClickFix-style Cloudflare verification checks is part of a wider malware-as-a-service (MaaS) platform called Lunex. The new findings come from Ontinue, which described the activity as a four-stage attack chain aimed at targeting Ukrainian-speaking users. "The attack chain begins with a fake CAPTCHA page and

Source: Lunex Stealer Abuses AMD Driver to Disable Security Monitoring and Steal Browser Credentials via The Hacker News — published 26 Sep 2026.