Lunex Unmasked: A New Information Stealer Deployed Through BYOVD

Published September 24, 2026

• Executive Summary
• Samples Analysed
• Attack Chain
  • Stage 1: The MSI That Installs Itself
  • Stage 2: Loader / Dropper
    • Where Are the Strings?
    • Privilege Escalation
    • Downloading the Kernel’s Own Blueprint
    • The 20-Driver Hit List
  • Stage 3: BYOVD Abuse
    • 12 IOCTLs, Zero Access Controls
  • Stage 4: LunexStealer That Is Also a C2 Agent
    • C2 Protocol
    • Browser Credential Theft
    • Cryptocurrency Wallet Theft
    • The Backdoor That Survives Deletion
  • C2 Infrastructure
    • Russian Origin
    • 28 Panels Across 13 Countries
• Threat Actor
• Indicators of Compromise
  • Link to github
• Conclusion
• References

Executive Summary

The Ontinue Cyber Defence Centre has identified and reverse-engineered a four-stage attack chain associated with the Lunex Malware-as-a-Service platform, targeting Ukrainian-speaking users. The analysed stealer binary was compiled on 12 September 2026, with its supporting infrastructure provisioned shortly beforehand, indicating active development.

The attack chain begins with a fake CAPTCHA page and culminates in the deployment of a fully featured C2 agent. The stealer extracts credentials and data from seven Chromium-based browsers, exfiltrates cryptocurrency wallets, and establishes persistent remote filesystem access through a PowerShell-based Native Messaging Host installed within the victim’s browser.

Before deploying the stealer, the loader runs a Bring Your Own Vulnerable Driver (BYOVD) chain that disables kernel-level security monitoring. Deploying a BYOVD is not uncommon, but it is rarely used before a final-stage payload such as an information stealer. This lets the final payload run after disabling callbacks from multiple endpoint security products.

The Lunex command-and-control platform was first documented through OSINT research published by Luke Wilkinson at BlueTeamCoolTeam in June 2026, who identified six active panels across five countries and documented the platform’s externally visible operator capabilities. No public technical analysis of the underlying binaries or operational tooling existed. This article provides that analysis. Internet-wide scanning during this investigation identified 28 Lunex panels across 13 countries, and analysis of the panel source code revealed Russian-language operator UI strings and banking trojan capabilities not covered in prior reporting.

We assess with confidence that this activity originates from a financially motivated, CIS-aligned threat actor operating through the Lunex platform. To our knowledge, this article presents the first public, in-depth binary analysis of the operational tooling associated with Lunex.

Samples Analysed

The analysis covers four binaries that form a complete attack chain, recovered alongside Ukrainian-language lure infrastructure on uasputnik[.]com. The delivery mechanism uses a fake CAPTCHA page that instructs the victim to execute an msiexec command, silently installing the MSI from the attacker’s URL.

Stage	File	SHA-256	Size
1	elita.msi (MSI installer)	38E90AFFE37342EE36917CDC535FE9BF04589AFA8430EB8D1BA1016ADCFC1878	1.1 MB
2	psychedelic.exe / config.exe (LunexLoader)	bf14cd6c3328ebd08e940478b5d1da04e9e5aa576d045d41950bf4f1e2456dd8	2.3 MB
3	PDFWKRNL.sys (AMD BYOVD driver, CVE-2023-20598)	6e8b49cf70bf854e8c59c7d27cefa89406caf8978461190dabb86dafcd8554e1	80 KB
4	psychedeliclove.exe (LunexStealer)	06f434695f93d7fd11eeff71358ff69fed79d310a66d993bbcc4ff979c117c90	275 KB

The MSI is a 1.1 MB unsigned OLE Compound Document presenting itself as “Vertification” by “Internal Software.” The deliberate misspelling corresponds to the Ukrainian word in the lure text. Properties suppress the installer wizard, hide the entry from Add/Remove Programs, and configure a Custom Action to auto-launch the payload. The package requires no administrator privileges and installs to a per-user path under %LOCALAPPDATA%.

Attack Chain

Stage 1: The MSI That Installs Itself

The MSI package elita.msi demonstrates deliberate design choices that minimise the victim’s awareness of the installation. The LIMITUI=1 property suppresses the standard Windows Installer wizard. The product name “Vertification” is a plausible-looking misspelling, not a random string, and corresponds to the Ukrainian word used in the lure page. The manufacturer name “Internal Software” suggests a corporate tool, lowering suspicion in enterprise environments.

The package installs to %LOCALAPPDATA%\\Programs\\Internal Software\\Vertification\\, a per-user location that requires no administrative privileges and triggers no UAC elevation prompt. Two properties, ARPNOMODIFY=1 and ARPNOREPAIR=1, hide the Modify and Repair buttons from the Add/Remove Programs entry. The user cannot interact with the installation through standard Windows interfaces.

A Type 226 Custom Action at sequence position 6700, immediately after InstallFinalize at position 6600, auto-launches the payload. The action fires only on first-time installation, not during repair, uninstall, or administrative deployment. The “continue on error” flag embedded in the Custom Action type means the MSI reports a successful installation even if the payload fails to execute.

The MSI also contains an Upgrade table. Any prior version with the same UpgradeCode, {2F40B8FA-6CB2-4328-B2A3-4B15A124F441}, is detected and uninstalled before the new version installs. This mechanism enables the threat actor to update the payload on previously compromised systems simply by distributing a new MSI with an incremented version number.

The MSI contains no malicious code of its own. No ServiceInstall entries. No Registry table entries. No embedded custom action DLLs. All persistence and malicious functionality is deferred entirely to the installed binary.

Stage 2: Loader / Dropper

Loader (config.exe, delivered as psychedelic.exe) is a 2.3 MB 64-bit executable compiled with MinGW-w64. It spoofs Canonical Ltd.’s “Update Manager” in its version information, a product that does not exist on Windows. The compilation timestamp is falsified to the year 2054. Two TLS callbacks execute before the PE entry point, a strong malware indicator. And every operational string in the binary is encrypted.

Where Are the Strings?

Running strings on the Loader produces almost nothing useful, yielding only import table names, the dead-code anchor’s API references, and a single plaintext string: payload.exe. Everything else, including API names, file paths, registry keys, WMI queries, C2 URLs, process names, and kernel symbol names, is encrypted with AES-256 in CTR mode.

Two decoder functions resolve strings at runtime. Both share a 32-byte key and a 16-byte IV embedded in the .rdata section. Offline extraction of these bytes allowed recovery of all 126 encrypted strings without executing the malware.

A dead-code function adds a layer of import table obfuscation. The function is gated behind GetTickCount() == 0x9E3779B9, the TEA and XTEA cipher constant derived from the golden ratio. This condition is mathematically impossible under normal execution. The function body calls 55 imported APIs with NULL parameters, existing solely to inflate the Import Address Table with decoy entries from SHELL32, WINHTTP, WS2_32, CRYPT32, GDI32, and ten additional DLLs. Static import analysis is misleading by design.

Figure 2: Dead-code IAT anchor.

Privilege Escalation

Loader executes a four-step privilege escalation chain that takes it from an unprivileged user-mode process to kernel-level access without triggering a User Account Control prompt.

First, it overwrites the ImagePathName, CommandLine, and InMemoryOrderModuleList entry in the Process Environment Block with a path derived from GetWindowsDirectoryA. Process inspection tools see a legitimate Windows binary. This PEB masquerade is not merely cosmetic. It is a prerequisite for the next step.

Second, it calls CoGetObject with the COM Elevation Moniker string Elevation:Administrator!new:{3E5FC7F9-9A51-4367-9063-A120244FBEC7}. The CLSID {3E5FC7F9-9A51-4367-9063-A120244FBEC7} corresponds to the CMSTPLUA COM object, a Microsoft Connection Manager component marked as auto-elevate in the Windows registry. Auto-elevate COM objects can be instantiated with Administrator privileges without a UAC prompt, provided the caller appears to be a trusted Windows binary. The PEB masquerade from step one satisfies this check.

Third, once running with Administrator privileges, it calls OpenProcessToken, LookupPrivilegeValueA (for SeLoadDriverPrivilege), and AdjustTokenPrivileges to enable the kernel driver loading privilege.

Fourth, it installs and loads the BYOVD driver via OpenSCManagerA, CreateServiceA, and StartServiceA.

The loader also performs WMI-based virtual machine and sandbox detection through two ExecQuery calls with 16 encrypted property names, enumerates running processes with CreateToolhelp32Snapshot to check against a 20-entry AES-encrypted security driver blocklist, and resolves approximately 30 API functions dynamically through runtime string decryption. None of these API names appear in the static import table.

Downloading the Kernel’s Own Blueprint

The loader reads C:\\Windows\\system32\\ntoskrnl.exe to extract the RSDS PDB GUID from the PE debug directory. This GUID is unique to the specific Windows kernel build on the target machine. The loader then spawns curl.exe with a carefully constructed command:

The User-Agent Microsoft-Symbol-Server/10.1700.661.0 mimics legitimate Windows symbol resolution traffic. The URL targets Microsoft’s official Symbol Server. To a network monitor, this connection appears routine. The downloaded PDB file, ntkrnlmp.pdb, the kernel debugging symbols, contains exact structure offsets and type definitions for the running Windows build.

The loader memory-maps the PDB and parses it with eight dbghelp.dll APIs: SymInitialize, SymLoadModuleEx, SymFromName, SymGetTypeInfo, SymGetTypeFromName, SymCleanup, SymUnloadModule64, and SymSetOptions. It resolves 15 kernel symbols, including PspCreateProcessNotifyRoutine, PspCreateThreadNotifyRoutine, PspLoadImageNotifyRoutine, ActiveProcessLinks, Token, Protection, SignatureLevel, and CallbackListHead. The resulting offsets are stored in seven global variables and used to locate kernel callback tables, notification chains, and process structure fields. This technique is version-agnostic: it works on any Windows 10 or Windows 11 build because the offsets are always correct for the running kernel.

The 20-Driver Hit List

The 20-Driver Hit List

The loader contains an AES-256-GCM encrypted overlay spanning 2 MB, 91% of the total file size. The authentication tag bd8edd25bcf7717b is hardcoded. The decryption key derives from constants in the .rdata section. When decrypted, the 80,536-byte output is a native x64 kernel driver.

Before deploying the driver, the loader checks running processes and kernel modules against a 20-entry blocklist, all entries AES-256-CTR encrypted. Each driver name was recovered through offline key extraction:

#	Driver	Vendor
1	WdFilter.sys	Microsoft Defender
2	MsSecFlt.sys	Microsoft Security Events
3-8	klif.sys, klflt.sys, klam.sys, klark.sys, kneps.sys, klhk.sys	Kaspersky (6 drivers)
9-11	dwprot.sys, drwebmon.sys, SpIDer.sys	Dr.Web (3 drivers)
12-14	eamonm.sys, ekbdflt.sys, epfwwfp.sys	ESET (3 drivers)
15	elastic-endpoint-driver.sys	Elastic
16	SysmonDrv.sys	Sysinternals
17-18	CrowdStrike.sys, csagent.sys	CrowdStrike
19	SentinelMonitor.sys	SentinelOne
20	fltMgr.sys	Windows Filter Manager

Entry 20, fltMgr.sys, is the Windows Filter Manager itself. Removing hooks from this driver would disable all minifilter-based security products simultaneously, regardless of vendor. The blocklist composition, with 45% targeting Russian and CIS antivirus products alongside Western EDR, is consistent with a commercial tool designed for broad geographic applicability.security products simultaneously, regardless of vendor. The blocklist composition, with 45% targeting Russian and CIS antivirus products alongside Western EDR, is consistent with a commercial tool designed for broad geographic applicability.

Stage 3: BYOVD Abuse

The AES-256-GCM encrypted payload was discovered as a Bring Your Own Vulnerable Driver (BYOVD) in AMD’s PDFWKRNL.sys, the USB-C Power Delivery Firmware Update Utility Driver. The binary is Authenticode-signed through the chain AMD → Sectigo → USERTrust → Microsoft Code Verification Root. It was compiled with Microsoft Visual Studio 2022; the compilation timestamp, December 2022, is consistent with the build. Its version information identifies it as a legitimate AMD product.

The file has been modified after signing. The Authentihash computed from the PE image does not match the digest embedded in the signature. Despite this tampering, Windows loads the driver because the certificate chain validates and the countersignature timestamp falls within the certificate’s validity peri.od

12 IOCTLs, Zero Access Controls

The driver registers a device at \\\\.\\PdFwKrnl and handles IRP_MJ_DEVICE_CONTROL through a switch statement on 12 IOCTL control codes. No access control checks are performed on any path. Any user-mode process with a handle to the device has full access to all operations.

Figure 3: PDFWKRNL.sys IRP_MJ_DEVICE_CONTROL handler

IOCTL	Operation	Purpose
0x80002028	Kernel memory read	Copies kernel callback table entries to a user-mode buffer
0x80002014	Kernel memory write	Copies zeroes into callback table entries belonging to security products

Both IOCTLs route through the same SIMD-optimised memory copy function. IOCTL 0x80002028 copies from kernel space to a user-mode buffer. IOCTL 0x80002014 copies from user-mode data to a kernel address. The loader uses the read IOCTL to retrieve callback table contents, resolves which kernel module owns each entry through K32GetDeviceDriverBaseNameA, checks the module name against the 20-entry blocklist, and zeroes matching entries through the write IOCTL.

The vulnerability is a design flaw in the IOCTL handler, not a code execution bug. CVE-2023-20598 describes this absence of access controls. The driver is catalogued on LOLDrivers. Public proof-of-concept exploits have been available since 2023. ESET identified PDFWKRNL.sys as actively abused in their March 2026 EDR killer research. What distinguishes this Lunex campaign is the integration of PDFWKRNL.sys into a multi-stage delivery chain with PDB-guided callback zeroing rather than blind process termination.

Stage 4: LunexStealer That Is Also a C2 Agent

After the kernel callbacks are zeroed, Loader downloads the final payload from http://107.175[.]82[.]242:9000/wilow/psychedeliclove.exe. This binary, which we designate LunexStealer, is a 281 KB 64-bit executable compiled with MinGW-w64 on 12 September 2026, two days before the incident. It contains 11 PE sections, 169 imports across 11 DLLs, and an embedded 2,124-byte JSON configuration in a custom .embed section.

C2 Protocol

LunexStealer communicates with the Lunex panel at 193.178.159[.]128 over HTTP with API-key authentication. The exfiltration API runs on port 8080. The operator panel runs on port 8000. The protocol follows a structured flow: initialisation, configuration decryption, machine fingerprinting with 17 collected fields, check-in with a kill switch check, credential and wallet theft with structured exfiltration, and persistent task polling with randomised heartbeat intervals.

Endpoint	Method	Purpose
/api/v1/checkin	POST	Initial registration with system fingerprint; kill switch at status code 2
/api/v1/agent/config	GET	Dynamic configuration update with 11 toggleable fields
/api/v1/agent/ping	GET	Heartbeat beacon with 20 to 25 second randomised jitter
/api/v1/agent/tasks	GET	Task polling for download and execute commands
/api/v1/agent/tasks/<id>/ack	POST	Task completion acknowledgment
/api/v1/ext/passwords	POST	Stolen credentials in JSON format
/api/v1/ext/tokens	POST	Session cookies and authentication tokens in JSON
/api/v1/ext/wallets	POST	Wallet data as multipart form-data with ZIP compression

All requests carry an X-API-Key header set to c9daf8dbafc5e1f63e4af742a14a8a6669365e106ab0247ab366621bbc1f6967 and a Mozilla/5.0 User-Agent. The API CORS headers additionally include X-Clipper-HWID, indicating the Lunex panel also supports clipboard-hijacking malware alongside the st

Browser Credential Theft

LunexStealer targets seven Chromium-based browsers: Google Chrome, Microsoft Edge, Brave, Yandex Browser, Opera, Opera GX, and Vivaldi. The theft process follows a consistent pattern across all targets. The browser process is terminated with taskkill /F /IM <exe> /T to release locks on the SQLite database files. The Login Data, Login Data For Account, Web Data, and Cookies databases are copied to a temporary file named wd_tmp.db for processing.

The binary does not link the SQLite library. It implements a custom B-tree page parser to read browser databases directly. This eliminates a dependency that signature-based detection could target and reduces the binary’s import footprint.

Encryption key extraction handles three Chrome versions. Version 10 uses AES-GCM with a DPAPI-protected master key retrieved from the encrypted_key field in the browser’s Local State JSON file and decrypted through CryptUnprotectData. Version 11, Chrome’s App-Bound Encryption introduced in July 2024, requires COM-based process injection: the stealer generates x64 shellcode at runtime, creates a suspended Chrome child process, and injects shellcode that calls CoInitializeEx, CoCreateInstance, and CoSetProxyBlanket to interact with Chrome’s IElevator COM service and retrieve the app_bound_encrypted_key. Version 20 uses ChaCha20-Poly1305 authenticated encryption, the newest Chrome encryption format. Most publicly documented stealer families stop at version 11. Credit card data from the Web Data database and form autofill entries are also collected.

Cryptocurrency Wallet Theft

The stealer enumerates five desktop cryptocurrency wallets, Bitcoin Core, Litecoin, Exodus, Atomic Wallet, and Electrum, and four browser extension wallets, MetaMask, MetaMask Legacy, OKX Wallet, and SafePal Wallet. Extension data is accessed through IndexedDB\\chrome-extension_<ID>_0.indexeddb.leveldb and Local Extension Settings paths. All wallet data is compressed into wallet.zip using a custom ZIP builder with raw PK headers and no compression library dependency, then exfiltrated via multipart form-data POST to /api/v1/ext/wallets.

The Backdoor That Survives Deletion

The stealer’s persistence mechanism is the most operationally significant component. It establishes three independent persistence channels.

A registry Run key is written through RegCreateKeyExW and RegSetValueExW with the value format UserStarts <path> at user logon. A hidden scheduled task named psychedelicloveUtils is created through the Task Scheduler COM interface, configured to execute at user logon.

The third channel is the most persistent. The stealer writes a registry key at HKCU\\Software\\Google\\Chrome\\NativeMessagingHosts\\com.lunex.explorer and an identical key for Microsoft Edge. This registers a Chrome Native Messaging Host, a mechanism designed for legitimate browser extensions to communicate with native applications. The host is backed by a 13,200-byte PowerShell script embedded in the .rdata section that implements the Chrome Native Messaging protocol over standard input and output.

The script provides six filesystem actions:

Action	Capability
list_drives	Enumerate all drive letters C through Z
list_dir	List directory contents with file sizes
read_file	Read arbitrary files in 512 KB chunks, up to 524 MB
write	Write arbitrary data to any file path
download	Download files from the system
run	Execute arbitrary programs

The NMH operates within Chrome’s process context. It survives stealer binary deletion, system reboots, and browser restarts. An incident responder who identifies and removes the stealer executable but does not audit Native Messaging Host registrations leaves the attacker with full filesystem access through the browser. A mutex named Local\\psychedeliclove-guard prevents multiple stealer instances.

The stealer also injects a malicious Chrome extension by manipulating Chrome Secure Preferences. An HMAC bypass extracts a seed value, recomputes the MAC tree recursively, removes integrity hash entries, and enables developer mode. The extension manifest, embedded in the JSON configuration, declares permissions for cookies, history, bookmarks, tabs, storage, proxy, scripting, declarativeNetRequest, and all HTTP and HTTPS URLs. This combination provides the extension with complete visibility and control over browser activity.

The binary implements several techniques that exceed typical stealer complexity. FNV-1a hash-based API resolution, similar to Cobalt Strike’s beacon, avoids plaintext API name strings in memory. The binary extracts raw syscall numbers directly from ntdll.dll to perform direct syscalls, bypassing user-mode EDR hooks. Custom implementations throughout, including a hand-written JSON parser using linked-list dictionaries, a SQLite B-tree page reader, a ZIP builder with raw PK headers, and Shell.Application COM-based extraction, eliminate external library dependencies that signature-based detection could target. Full Ghidra decompilation across 275 functions produced 992 KB of pseudocode.

C2 Infrastructure

The campaign operated across three hosts under different providers in different countries. The payload server at 107.175.82[.]242 (OneProvider, Seattle) served LunexStealer on port 9000 and was managed through EasyPanel, a self-hosted server management dashboard. The exfiltration server at 193.178.159[.]128 (UFO Technologies, Roubaix, France) hosted four services: the Lunex operator panel on port 8000, the REST API on port 8080, a publicly exposed phpMyAdmin 5.2.3 instance on port 8081 with the root MySQL user visible in the login form, and SSH. The delivery domain uasputnik[.]com resolved to shared hosting in Warsaw, Poland, co-located with a domain using the Russian word “Vostok.”

Both C2 hosts shared an identical SSH HASSH fingerprint, confirming a single operator managing both servers with the same provisioning tooling. No TLS was configured on any C2 port. The phpMyAdmin instance provided direct, unauthenticated database access. The operator’s infrastructure security was poor, contrasting sharply with the loader’s technical sophistication. This disconnect, advanced malware engineering paired with amateur infrastructure management, suggests either separate individuals handling development and operations, infrastructure designed to be disposable, or both.

Figure 5: Lunex C2 operator panel login page operates on port 8000

Russian Origin

Analysis of the Lunex panel frontend (a React single-page application served by nginx) revealed a 453 KB JavaScript bundle containing the complete operator interface. The panel’s internationalisation framework (i18next) loads Russian as the default locale. Over 150 Russian-language UI strings are embedded, including empty-state messages (“Ботов пока нет – подключи установщик с API-ключом” / No bots yet, connect the installer with an API key), error messages (“Неверный логин или пароль” / Invalid username or password), and operational labels (“Команд в очереди” / Commands in queue). The language selector lists “Русский” (Russian) as the primary option. A placeholder example in the browser spoofing configuration uses “ya.ru”, Yandex Russia’s homepage, as the target domain. The panel was built by and for Russian-speaking operators.

We also found that one of the IP addresses hosting Lunex had an operator panel likely specific to the developer/operator, and the version number on the screen indicates it is still in development.

28 Panels Across 13 Countries

Internet-wide scanning identified 28 unique Lunex panels across 13 countries, a significant expansion from the six panels BlueTeamCoolTeam documented in June 2026. Russia hosts the most panels (6), followed by the United States (4), the United Kingdom (3), and the Netherlands, France, Germany, Turkey, and Bangladesh (2 each). UFO Technologies in Krasnogorsk (Moscow region) hosts four panels, making it the most concentrated cluster. One of these panels (193.178.158.61) sits on the same /24 network as the exfiltration server in this analysis, suggesting shared operator infrastructure. ZORNTECH, which hosts the delivery domain uasputnik[.]com, also hosts a panel at a separate IP.

One panel in Turkey (103.101.85[.]123) was found resolving to five phishing domains: account-sams-club[.]com, teamwork-recover-password[.]com, namshi-uae[.]com, whatsappbusineses[.]com, and ibraq-perfumes[.]com. This confirms Lunex is being used for brand impersonation and phishing alongside credential theft, consistent with the web inject and browser spoofing capabilities identified in the panel source code.

The infrastructure timeline reflects a compressed operational tempo. The network block was allocated in July 2026. The Lunex panel was deployed on 11 September. LunexStealer was compiled on 12 September. Both C2 servers were confirmed live during analysis on 2026-09-15.

Threat Actor

We assess with confidence that the Lunex platform is developed by a Russian-speaking developer or development team and sold to multiple independent criminal operators. The panel frontend contains over 150 Russian-language UI strings loaded through an internationalisation framework as the default locale, not as a translation layer over English. The language selector lists “Русский” as the primary option. A placeholder in the browser spoofing configuration uses “ya.ru” (Yandex Russia’s homepage) as the default target domain, a reference that is natural only for a Russian-speaking developer. The highest concentration of panels (6 of 28) is hosted on UFO Technologies in Krasnogorsk, a satellite city of Moscow, suggesting the developer operates from or provisions infrastructure through the Moscow region. The malware engineering, including custom AES-256 implementations, PDB-guided kernel symbol resolution, and a dead-code IAT anchor technique not documented in public literature, is consistent with an experienced developer rather than a MaaS customer.

The 28 panels identified across 13 countries, the self-registration endpoint, and the existence of multiple stealer codebases (Rust, C, .NET) connecting to the same panel architecture indicate the platform serves multiple independent operators. The operator in this analysis, identified by the config tag “Psychedelic”, targeted Ukrainian-speaking users through a fake CAPTCHA lure on uasputnik[.]com. The delivery domain is co-located with a domain using the Russian word “Vostok” (East) on shared hosting in Warsaw. The MinGW-w64 toolchain and the security driver blocklist (45% targeting Kaspersky and Dr.Web) are consistent with a CIS-region criminal operator. A separate operator appears to be running the Turkey-based panel behind five phishing domains targeting Western and Middle Eastern brands (Sam’s Club, Teamwork, Namshi, WhatsApp), entirely different targeting from the Ukrainian lure. The poor infrastructure OPSEC observed, no TLS, phpMyAdmin exposed with root access, wildcard CORS, contrasts with the developer’s engineering quality, consistent with a separation between the developer who builds the platform and the operators who run campaigns.

The Chrome Secure Preferences integrity bypass present in LunexStealer initially raised a potential link to APT31’s SUPERSTOMP tool, documented by Volexity on 9 September 2026. We subsequently downgraded this assessment. Within September 2026, at least four independent implementations of the same bypass were identified across unrelated operations, indicating the technique has fully proliferated. The bypass is no longer a reliable indicator of state-sponsored activity.

BlueTeamCoolTeam documented the Lunex platform through OSINT panel mapping in June 2026, identifying six panels across five countries. Internet-wide scanning during this investigation identified 28 unique panels across 13 countries, demonstrating significant growth in the platform’s operational footprint. Their research documented a Rust-based stealer. The stealer in this analysis is compiled with MinGW-w64 in C. Multiple codebases connecting to the same panel architecture reinforce the assessment that Lunex is a platform sold to operators, not a single malware family.

Indicators of Compromise

Indicators here: https://github.com/ontinue-research/threat-intel-iocs/blob/main/Public/LunexMalware/2026-09-22-LUNE…

Conclusion

This analysis presents the first public deep-dive binary analysis of the Lunex platform’s operational tooling and reveals a platform significantly more capable than previously understood. What prior OSINT research documented as a stealer management panel is, on closer inspection, a full-featured crimeware platform with web inject management, browser spoofing, remote browser control, and persistent filesystem access through Chrome Native Messaging Hosts. The panel is built by Russian-speaking developers, operates across 28 identified panels in 13 countries, and is actively used for both credential theft and brand impersonation phishing.

The BYOVD delivery chain, using PDB-guided kernel callback zeroing rather than process termination, represents a quieter approach to EDR neutralisation that leaves security products running but blind. Validated testing demonstrated that neither HVCI nor the current Microsoft Vulnerable Driver Blocklist prevents the specific PDFWKRNL.sys variant used in this chain from loading, a gap that persists despite the driver hash being catalogued in the LOLDrivers project since March 2026.

For defenders, the critical insight is that detection must focus on the stages before EDR blindness occurs: PDB downloads from non-development processes, driver drops to temporary directories, and service creation for unsigned drivers from non-standard paths. Post-blindness, the Native Messaging Host registry key (NativeMessagingHosts\com.lunex.explorer) is the most reliable indicator of compromise and must be included in any remediation scope alongside the stealer binary, scheduled task, and Run key.

References

• BlueTeamCoolTeam, “The Panel Behind the Prompt: OSINT into a Live Lunex Stealer Network,” 13 June 2026. https://blueteam.cool/posts/lunex-c2-osint/
• ESET, “EDR Killers Explained: Beyond the Drivers,” 19 March 2026. https://welivesecurity.com/en/eset-research/edr-killers-explained-beyond-the-drivers
• Volexity, “Mind the Patch Gap: Multiple Chinese Threat Actors Chain 0-Day Exploits in Chrome and Windows,” 9 September 2026. https://www.volexity.com/blog/2026/09/09/mind-the-patch-gap-multiple-chinese-threat-actors-chain-0-day-exploits-in-chrome-windows/
• Proofpoint, “Unpacking Cruciferra: An Analysis of a Sophisticated Crypter Service,” July 2026. https://www.proofpoint.com/us/blog/threat-insight/unpacking-cruciferra-analysis-sophisticated-crypter-service