The Fake Guard at the Gate: How LunexStealer Turned Cloudflare Checks Into a Trap
Every visitor knows the routine.
You approach a building. A security guard stands at the entrance. He wears the right uniform, stands behind an official-looking checkpoint and asks you to complete a routine verification before entering.
You comply. After all, the guard is supposed to protect the building.
Now imagine the guard is not employed by the building at all.
He has stolen the uniform, taken control of the checkpoint and rewritten the instructions. Instead of checking whether you belong inside, he persuades you to hand over the keys to your own office.
That is the deception at the center of a campaign uncovered by CERT-UA, in which more than 100 compromised websites were used to distribute LunexStealer through fraudulent Cloudflare verification pages.
The attackers did not simply hide malware behind a malicious download.
They disguised the first step of the intrusion as an act of security.
Phase 1 — The Thieves Take Over the Building
The operation began long before a visitor encountered the fake guard.
Threat actors tracked as UAC-0277 compromised more than 100 legitimate websites and injected malicious JavaScript into their pages.
These were not necessarily websites created by the attackers.
They were real buildings whose entrances had been quietly modified.
Visitors could arrive through ordinary search results, recognize the website they expected to visit and assume everything was operating normally.
But hidden inside the page was a mechanism capable of replacing an ordinary browsing experience with a fraudulent verification checkpoint.
CERT-UA observed the campaign in September 2026. However, it did not identify the victims or establish whether the attacks resulted in successful endpoint compromises.
The guard’s trap was documented.
How many visitors ultimately fell for it remained unknown.
Phase 2 — The Fake Guard Puts On Cloudflare’s Uniform
The next stage depended on familiarity.
Cloudflare verification pages are widely recognizable. They represent an ordinary security procedure that many internet users have encountered.
The attackers exploited that recognition.
When the malicious JavaScript activated, the visitor encountered a page impersonating Cloudflare and claiming that an additional human verification step was necessary.
But instead of completing a normal browser-based challenge, the visitor was instructed to execute a command on their Windows computer.
This was ClickFix: a social engineering technique that convinces users to perform the malicious action themselves.
The guard was no longer asking to inspect a visitor’s identification.
He was telling the visitor to unlock a door that security controls were supposed to keep closed.
And because the instruction appeared to come from a trusted security checkpoint, the deception became considerably more convincing.
Phase 3 — The Guard Receives Orders From a Hidden Headquarters
The attackers also needed a way to control when the fake checkpoint appeared.
Rather than keeping all their instructions inside the compromised websites, they used EtherHiding.
This technique retrieves configuration information from smart contracts on the Polygon or Ethereum blockchain.
Imagine the fake guard receiving instructions from a headquarters hidden somewhere beyond the building.
The orders determine whether he should remain invisible, observe visitors or begin the deception.
CERT-UA identified three operating modes:
Mode 0 — Inactive: The malicious mechanism remains dormant.
Mode 1 — Surveillance: The script collects information about visitors and their browsing context.
Mode 2 — Impersonation: The fraudulent Cloudflare verification page appears.
The attackers also applied selective targeting.
In Mode 2, the checkpoint appeared only to Windows visitors arriving through search engine results, and no more than twice within a 12-hour period.
This made the operation less conspicuous.
Not every visitor would see the impostor.
Not every inspection would reveal the trap.
The guard knew when to put on his disguise—and when to disappear.
Phase 4 — The Visitor Opens the Door
Once the victim followed the fake verification instructions, the attack moved from the browser into Windows.
The command initiated the download and installation of a malicious MSI package.
CERT-UA identified at least three delivery variants.
The first installed LunexStealer directly.
The second attempted to bypass Windows User Account Control, configured Microsoft Defender exclusions and used a legitimate but vulnerable AMD driver, PDFWKRNL.sys, to interfere with security software before retrieving the stealer.
The third relied on DLL sideloading, using the legitimate FnHotkeyUtility.exe executable to load a malicious spkvol.dll that decrypted and executed LunexStealer.
Three different approaches.
One objective.
Get the intruder inside the machine.
The visitor believed they were completing a security procedure.
In reality, they had been recruited to help the attackers cross the checkpoint.
Phase 5 — The Thieves Move Into the Browser
Installing LunexStealer was not necessarily the end of the operation.
The malware could also deploy a malicious browser extension called LUNARAXE, disguised as Microsoft Office Word Editor.
The deception continued.
The fake guard had opened the building. Now another impostor was sitting inside the office, pretending to be a legitimate productivity tool.
LUNARAXE contained three components with complementary capabilities.
LUNARAXE.CORE handled command-and-control communications, browser data collection and remote actions. It could access cookies, browsing history, bookmarks and information about installed extensions, manipulate tabs, display deceptive overlays and execute JavaScript on web pages.
LUNARAXE.STEALER intercepted credentials entered into web forms, along with the associated page URLs.
LUNARAXE.STRIP weakened browser protections by stripping Content Security Policy headers from HTTP responses, helping malicious JavaScript execute in contexts where it would otherwise face restrictions.
The attackers were no longer simply trying to enter the building.
They were watching what happened inside.
Passwords typed into forms.
Sessions maintained through cookies.
Pages visited.
Information passing through the browser.
The security checkpoint had become the beginning of a surveillance operation.
Phase 6 — A Secret Passage Opens Into the Filesystem
LUNARAXE could also receive support from an auxiliary component called NAIVEMESS.
Its role was to extend the browser extension’s reach into the Windows filesystem through a PowerShell-based Native Messaging Host.
In the building metaphor, this was the moment the thieves discovered that the office had a hidden passage leading into the archives.
NAIVEMESS could enumerate drives, browse directories, read files, create or overwrite them, and execute files.
Data could be transferred in Base64-encoded chunks, while directories and groups of files could be compressed into ZIP archives before transfer.
Crucially, NAIVEMESS did not require an independent command channel to operate. Its instructions were relayed through LUNARAXE.
The malicious extension became the messenger.
NAIVEMESS became the operative inside the records room.
Together, they extended the attack beyond browser credential theft into broader access to local information and system functionality.
What began as a fake identity check could become a route from a website into the victim’s files.
Phase 7 — The Real Guards Learn to Recognize the Impostor
The campaign exposed a dangerous weakness in the relationship between users and security interfaces.
Attackers were not necessarily defeating Cloudflare.
They were impersonating Cloudflare to persuade users to defeat their own endpoint protections.
That distinction matters.
Defending against the technique requires controls at several levels.
Organizations should restrict access to the Windows Run dialog where appropriate, prevent unauthorized MSI installations and monitor suspicious execution of msiexec.exe.
They should also enable Microsoft’s vulnerable driver blocklist and consider the Attack Surface Reduction rule designed to block abuse of vulnerable signed drivers.
Browser extension installation should be restricted to approved software, reducing the opportunity for malicious extensions such as LUNARAXE to establish themselves.
And users must understand one essential rule:
A website asking you to run a system command is not performing an ordinary human verification.
The appearance of a familiar security brand does not make the instruction legitimate.
The guard’s uniform is not proof that he belongs at the gate.
Phase 8 — The Checkpoint Was the Weapon
The most unsettling element of this operation was not any single malware component.
It was the way the entire intrusion was constructed around a trusted security ritual.
A legitimate website brought the visitor to the entrance.
A forged Cloudflare page supplied the authority.
ClickFix persuaded the visitor to execute the command.
An MSI package delivered the payload.
LunexStealer established the compromise.
LUNARAXE moved into the browser.
NAIVEMESS extended access into the filesystem.
And blockchain-hosted configuration helped determine when the deception should appear.
Each stage built on the trust established by the one before it.
The attackers did not need every visitor to believe an obvious lie.
They needed selected visitors to follow an instruction that appeared to come from someone responsible for protecting them.
That is what made the operation dangerous.
The checkpoint looked legitimate.
The instructions sounded routine.
The visitor believed the guard.
But the guard was never there to keep the thieves out.
He was the first thief through the door.
The Hacker News
Comentarios