There’s a special kind of insult in a signed AMD driver walking into a Windows box and telling your sensors to leave. Ontinue’s write-up on Lunex, the malware-as-a-service shop behind Psychedelic Stealer, describes a four-stage chain that starts with a fake Cloudflare check and ends with browser credentials walking out after local cybersecurity controls have already gone quiet. The operator didn’t smash the door. They asked your machine to look away, and it did.

You know this genre. Compromised sites. A “verification” prompt. A user who thinks they’re proving they’re human. Then a kernel-adjacent mute button, and your threat detection stack is suddenly taking a break. That’s the part that should ruin your weekend, not the stealer family name.

The CAPTCHA was the polite part

Lunex is selling a kit. Psychedelic Stealer is the payload currently in rotation, pushed at Ukrainian-speaking users through compromised sites that dress up as Cloudflare human checks. ClickFix-style prompts do what they always do: they put the next command in the victim’s hands and let the victim paste it. Your users aren’t “bypassing” a control. They’re completing a form the attacker designed.

Stage one is theater. Stage two is execution on a box that still thinks it passed a vendor check. Stage three is where Lunex gets interesting for anyone who actually runs a SOC: an AMD driver gets pressed into service to disable security monitoring. Stage four is the boring, expensive part. Cookies, passwords, session tokens. The stuff that lets someone else be your user tomorrow without a brute-force campaign against the login page.

Your firewall never saw the CAPTCHA. It saw HTTPS to a site you already allow, then a driver load that looks like hardware support, then a lot of nothing. Threat-protection products that only shout when a binary is unknown will have a quiet hour while a signed component does the unplugging. That’s a bad look for any stack that sells “we would have caught that.”

MaaS just means the next affiliate gets a new lure tomorrow. You will not patch your way out of a fake verification page on a site your people already trust. You can make the mute button expensive, and you can make the credential grab a short-lived win.

If cybersecurity goes quiet, that’s the page

Most incident response runbooks still treat “EDR stopped reporting” as a health event. Ticket the sensor. Restart the service. Wait for the next check-in. Lunex is betting you’ll do exactly that while the browser vault empties.

The driver abuse is not a clever puzzle for reverse engineers. It’s a volume control. Once local monitoring is blind, the rest of the chain is commodity stealer work: pull saved logins, grab cookies, ship them to whoever paid for the panel. Cyber security programs that measure success by alert volume will grade this incident as a non-event until helpdesk hears about locked accounts.

That delay is the product. Silence buys time for token replay, mailbox rules, and whatever SaaS the stolen session can still touch. Defense in depth that stops at the perimeter is doing you no favors here. The host already had a path to the identity store in the browser. The attacker needed your watchers offline more than they needed a new exploit.

If your paging rules ignore “sensor died” unless the box is also offline, you’re running a gentleman’s agreement with the malware. It will honor that agreement.

Driver loads from paths that are not your gold image should be a story, not a curiosity. So should security services that stop without a corresponding change ticket. So should a workstation that still has network but no telemetry. That last one is the Lunex shape. The machine looks fine. The SOC looks empty. The cookies are already gone.

Stop treating mute buttons as health checks

You don’t need Lunex’s panel to get ready for the next affiliate. You need a bias: telemetry death is hostile until proven otherwise. Security hardening on the endpoint is the control that still works after the fake CAPTCHA succeeded.

• Page on silence the same day. If the agent, event-forwarder, or AV service stops, isolate the host and pull a triage dump before anyone “just restarts it.” Treat a live network plus dead sensors as an active incident, not a broken install. Hunt for unexpected kernel drivers, especially vendor-signed files that are not in your standard image, and for browser processes touching credential stores right after a driver load.
• Kill the ClickFix habit in the OS, not in a poster. Block or alert on users launching the Run dialog and PowerShell from clipboard content after a browser session. Restrict who can load drivers. If you can’t get to an allowlist yet, inventory every driver that loaded this month and explain the ones that aren’t OEM baseline. That’s cheaper than pretending the next fake Cloudflare page will lose.
• Assume the browser is a vault and empty it on suspicion. Rotate cookies and tokens for the user, not just the password. Revoke refresh tokens in IdP and SaaS. Check for new mail rules, OAuth grants, and sessions from odd ASNs. The stealer wanted a session, not a password spray.
• Keep the edge honest, then move on. Your firewall and any ip-level blocks still matter for C2 you already know. They will not save you from a first-visit lure. Pair egress allowlists for workstations with browser isolation for the people who live in webmail all day. Log driver loads to a store the endpoint cannot mute.

Do the immediate work on any host that showed a fake verification prompt, a surprise driver, or a sensor gap. Do the ongoing work in the image: few people can load drivers, sensors heartbeat to a collector the host doesn’t own, and a dead heartbeat pages the same way a ransomware note would. That’s incident response you can run on a Tuesday without waiting for a decoder ring.

Don’t build your detection story around brute-force counters and call it done. This chain skipped guessing. It asked a person to paste a command, then asked Windows to stop watching.

A scheduled blackout is still an incident

While stealers were learning to mute the room, Kiteworks, formerly Accellion, told customers to shut systems down for nine hours after federal intelligence warned that some of its gear might be targeted. That’s a vendor asking you to go dark on purpose. Same operational shape, different author. You still lose logs, still freeze file movement, still have to prove what happened when the lights come back.

If your only move is “power it down and hope,” you will come up with the same evidence Lunex wants you to have: none. Snapshot configs and auth logs before the shutdown window. Park the system off the network if you can, rather than leaving an unmonitored listener. When it returns, diff users, keys, jobs, and outbound destinations against the snapshot. A precautionary outage without a return-to-service hunt is just an unscheduled maintenance window the attacker also enjoyed.

The thread is not “vendors are scary” and it isn’t “AMD is the villain.” Signed drivers and file-transfer appliances are both places where trust is pre-installed. Attackers will keep borrowing that trust to turn your watchers off. You should keep treating the off state as the event.

Next fake CAPTCHA will have a different skin. Next MaaS panel will have a different cartoon name. The mute button will look like a helper. Your job is to notice the room got quiet, and to move before the cookies do.

Sources

• Lunex Stealer Abuses AMD Driver to Disable Security Monitoring and Steal Browser Credentials
• Kiteworks Urges Customers to Shut Down Systems for 9 Hours Over Possible Cyber Attack