A colleague calls the helpdesk: a website asked them to prove they were human, then told them to open a system window and paste something. They followed the instructions. The page now works, the computer looks normal, and they want to know whether anything needs doing.
If you ran a command from a suspicious verification page, stop using that device, disconnect its network connections and contact your IT or security team from another device. Use a trusted device for account recovery. Tell the responder what you did, including whether you pressed Enter, installed anything or entered a password. An ordinary-looking desktop does not settle the question.
This guide explains ClickFix fake CAPTCHA attacks and a practical response for Luxembourg SMEs. The response workflow below is our recommended approach, rather than a claim that every encounter causes the same infection.
What is ClickFix, and why cover it now?
ClickFix persuades a person to execute a command under the pretence of fixing an error or completing verification. The decisive step is the move from a website into a system tool. A familiar logo, reassuring text or a page you have visited before is not enough to authorise that step.
In its August 2026 TerminalFix investigation, Microsoft documented compromised websites leading visitors into PowerShell and ultimately a reverse tunnel. That is evidence of one investigated campaign, not proof that every fake CAPTCHA installs that payload.
Microsoft also documented a macOS ClickFix campaign. Its conditional delivery helps explain why a suspicious link can look harmless when someone else checks it. This problem therefore belongs in the support process for both Windows and Mac users.
First establish how far the interaction went
Start with a calm conversation. Ask the user to describe the sequence in their own words before showing them a checklist. Record the approximate time and device. Avoid turning uncertainty into a confident answer: “I think I only copied it” needs investigation, not a tick in the safe column.
| What happened? | Recommended next action |
|---|
| The page appeared, but no instruction was followed. | Close it, record the address and report it. A page view alone does not prove command execution. |
| Text was copied or pasted, but no command was executed. | Do not execute it. Close the system window, replace the clipboard with harmless text and tell IT what happened. |
| A command ran, software was installed, credentials were entered, or the sequence is unclear. | Escalate promptly. Isolate a suspected infected device and investigate account exposure separately. |
These distinctions help triage; they are not a remote diagnosis. A download, browser permission or password submission can create a separate issue even if no command ran. ESET's October 2026 fake CAPTCHA guidance also distinguishes copying text from executing it. Do not ask someone to recreate the event to obtain certainty.
Contain the device without losing the story
For a work laptop suspected of executing the command, disconnect Wi-Fi and wired networking, or have the security team use the managed isolation function. Notify the responder by phone or from another device. Do not keep using the laptop for email, banking or administration while waiting for an answer.
On a managed fleet, the responder should verify that the isolation action actually succeeded. Microsoft's device response documentation describes supported isolation actions and their limitations. A pending action on an offline device is not evidence that the device has been contained.
Keep the incident timeline: user, device identifier, time zone, page address, actions taken and available alerts. A screenshot of the instructions can help if already available; do not revisit the page to obtain one. Send evidence through the organisation's approved channel rather than copying suspicious commands into general staff chats.
Leave shutdown, restart, evidence collection and rebuilding decisions to the responder once the device is isolated. A hurried factory reset may remove information needed to understand account exposure. Conversely, preserving evidence does not justify leaving a suspected infection connected to the business network.
Recover accounts from a trusted device
Draw up an exposure list with the user: work email, browser sessions, administrator accounts, VPN, password manager, developer credentials and customer systems used on that device. This is a scoping exercise, not an assertion that every item was stolen. Prioritise accounts that would let someone control other accounts or move money.
For accounts judged exposed, coordinate password changes, session revocation and credential rotation. Review authentication methods and connected applications for unexplained additions. Check relevant mail forwarding rules and recent account activity. Use a separate trusted device and the service's official administration interface, not links supplied by the suspicious page.
Microsoft's access revocation guidance explains why revocation can take time and depend on the application. Do not assume that changing a password immediately ends every existing session. Record which services were checked and how access was invalidated.
Multi-factor authentication remains valuable, but account protection and endpoint recovery are different jobs. Our existing guide to phishing-resistant MFA covers the authentication side. Here, the question is whether a computer and the credentials available through it can still be trusted.
Ask for an investigation outcome, not just a clean scan
The responder should reconstruct what executed, what it contacted, what it created and whether it established persistence. Where available, correlate endpoint events, DNS or proxy records and identity logs around the reported time. Expand the investigation if evidence shows access to additional systems.
A scan is useful evidence within that investigation. It does not, by itself, explain which accounts were accessible, whether a session was used elsewhere or whether the original download completed. Equally, a missing alert is not grounds for claiming that compromise definitely occurred. State what the evidence supports and what remains unknown.
Before returning the device, document the remediation decision and acceptance checks. That might involve a rebuild, restored business data, verified endpoint protection, working updates and confirmation that required credentials have been replaced. Give the user a safe way to resume work while investigation continues; otherwise practical pressure will drive an early reconnection.
Reduce execution opportunities without breaking the business
Begin with an inventory of who needs scripting tools and why. A finance workstation and an administrator's engineering laptop have different requirements. Define authorised software and execution paths for each role, then pilot restrictions with representative users before wider deployment.
Do not describe a PowerShell execution policy as a complete barrier. Microsoft explicitly describes its limits. Review application control, privilege management, browser protection and endpoint detection together, with an administrator who can test the resulting behaviour.
For a small IT team, a useful starting deliverable is a short control record: what is allowed, what is blocked, how an exception is approved and who handles an alert. Include Mac devices and contractors in that scope. A policy for only the centrally purchased Windows laptops leaves an obvious support gap.
Our security services can help scope that review. Keep the desired result concrete: a representative user's device resists an unauthorised execution path, legitimate work still functions, and the support team receives an actionable event.
Give staff one rule they can use under pressure
A website asking you to prove you are human does not authorise you to run a system command. Stop and use the known helpdesk contact.
Teach the boundary rather than a single keyboard shortcut. The suspicious request may name Run, PowerShell, Terminal or another application. It may arrive through a search result, a shared link or a compromised legitimate website. Staff should not need to identify the malware family before asking for help.
Use a safe screenshot or a non-executing demonstration in security training. Rehearse the reporting step as well as recognition: which number to call, what information to provide and how to continue working. Do not include a live malicious command in a staff exercise.
For a multilingual Luxembourg workplace, make the reporting instructions available in the languages people use at work. The goal is a quick, usable response when someone is uncertain. Blaming a person for reporting late makes the next incident harder to investigate.
Check the out-of-hours route as part of that handover. A person working late should know whether to disconnect the laptop, call a provider or wait for the next working day. Agree who can authorise containment and provide a replacement device. Test the contact details with a harmless reporting exercise before relying on them during a real event.
What the manager should ask for
Request a short closure record covering the known entry point, affected devices, account recovery, investigation limits and follow-up owners. Separate confirmed findings from precautionary actions. “We reset everything” is neither a scope statement nor evidence that recovery was complete.
Review the handover between helpdesk, security provider and identity administrator. The endpoint supplier may not control cloud sessions; the cloud administrator may not have access to device telemetry. Name who coordinates the incident before that gap causes a delay.
If you need help assessing a ClickFix report or improving endpoint controls, contact ObsidianCorps with the device type, approximate time and actions taken. We can agree the investigation scope and the next practical steps without treating uncertainty as a sales claim.
