Microsoft’s security team has raised the alarm on a subtle but effective evolution of the long-running
ClickFix social‑engineering scam: attackers are now tricking victims into opening
Windows Terminal and pasting encoded commands directly into it, which in multiple observed chains results in the deployment of the
Lumma Stealer infostealer and comprehensive browser credential theft.
Background
ClickFix-style scams first drew broad attention when threat actors began abusing fake CAPTCHA and “verification” pages to persuade users to run arbitrary commands on their machines. The classic pattern is simple and socially engineered: a web page displays a convincing prompt (a CAPTCHA failure, a fake Windows update, or a site-specific error), then instructs the user to press a keyboard shortcut such as Win+R, paste a command into the Run dialog, and press Enter. Because the user initiates the action, many browser protections and gateway filters are bypassed, letting PowerShell or mshta execute code that downloads loaders and stealers.
What Microsoft has documented in its most recent telemetry is an adaptation of that same formula: the attacker now tells the victim to press Windows+X → I (or otherwise launch
Windows Terminal) and paste a command there. Because
Windows Terminal is a legitimate developer/admin tool and commonly used by power users, activity originating from a Terminal window looks “normal” to many defenders. The result is an evasion technique that shifts the attack surface from the relatively monitored Run dialog to a tool that is both trusted by users and whitelisted by default security configurations.
This article unpacks the technical details Microsoft and other researchers have described, explains why this change matters, analyzes the Lumma Stealer threat that follows, and outlines practical mitigation, detection, and response guidance for both home users and enterprise defenders.
How the Windows Terminal twist changes the ClickFix playbook
The old model: Run dialog + clipboard hijack
The conventional ClickFix chain uses JavaScript to copy a malicious command to the clipboard and then persuades the user to open the Run dialog (Win+R). The Run dialog is a quick execution surface that accepts command strings like PowerShell one‑liners. Because the user triggers execution, many endpoint protections treat it as explicit consent and do not interfere.
Key traits of the classic approach:
- Clipboard hijack via JavaScript on a webpage.
- User presses Win+R and pastes a PowerShell one-liner.
- The one-liner typically decodes and launches a staged downloader/loader that pulls payloads from attacker-controlled infrastructure.
The new model: Windows Terminal as the execution surface
The observed change is subtle but meaningful: attackers now instruct victims to open
Windows Terminal (via Windows+X → I or other means) and paste the same kind of encoded command into it. This is important for three reasons:
- Legitimacy by default: Windows Terminal is a modern, signed Microsoft application. Frequent, legitimate use makes its activity appear benign in many telemetry streams.
- False sense of safety for users: Power users, developers, and administrators open Terminal regularly. A command pasted into a Terminal window is often perceived as routine troubleshooting.
- Detection blind spots: Some security products apply stricter heuristics or content inspection when commands are executed from mshta.exe, explorer.exe, or the Run dialog. Commands executed from a terminal process may not trigger the same behavioral signatures or sandboxing.
Attackers exploit these factors by tailoring the social engineering to the Terminal UI: the page shows a fake verification or troubleshooting screen and overlays step‑by‑step instructions that culminate in pasting a command into Terminal.
Technical anatomy of the observed infection chains
Microsoft’s telemetry and subsequent independent analyses have revealed at least two distinct infection patterns that pivot from the Terminal paste to Lumma Stealer deployment. Both use heavy obfuscation and multi‑stage loaders to complicate detection and analysis.
Common preamble: heavily encoded PowerShell or batch commands
The user-pasted input is not a single clear-text command. It’s a heavily encoded PowerShell command or a base64/obfuscated batch one-liner that performs the following high-level tasks:
- Decodes itself in memory.
- Fetches additional components from remote servers.
- Uses signed or legitimate tools to unpack or side-load payloads.
- Establishes persistence and disables or bypasses local defenses.
The obfuscation and multi-stage nature shield the core payload from static scanners and slow down incident responders.
Chain A — Archive side‑load and Lumma deployment
A representative Chain A observed in the wild behaves as follows:
- The decoded command downloads a renamed copy of 7-Zip (an archive utility commonly used by admins) to a temporary folder.
- A compressed payload is downloaded alongside the archive binary.
- The archive utility is invoked to extract further components. Using an external, legitimate extractor reduces suspicion and avoids triggering heuristic blocks tied to script-only unpacking.
- Extracted files include:
- A persistence mechanism (scheduled task, shortcut in Startup).
- A small loader that configures Microsoft Defender exclusions or attempts to disable certain checks.
- The final payload, Lumma Stealer, in a packed form.
- The final step launches Lumma, which injects into Chromium‑based browsers (Chrome, Edge) and extracts stored credentials, cookies, tokens, and other browser-resident secrets.
This chain is notable for using a legitimate utility (7-Zip) as an unpacker, turning a common admin tool into an unwitting accomplice for malware deployment.
Chain B — Script pivoting through VBScript and MSBuild (EtherHiding)
A second observed chain takes a different route:
- The command fetches a batch script that drops a VBScript file.
- The VBScript uses built-in utilities (for example, MSBuild or other signed components) to execute or compile code on the fly.
- The script opens outbound communication to infrastructure embedded in blockchain metadata or decentralized services — a tactic sometimes called EtherHiding — which makes takedown and attribution harder.
- Once the supporting binaries are staged, the loader again deploys Lumma Stealer or a similar credential-harvesting module.
This path is interesting because it demonstrates the use of living-off-the-land binaries and decentralized infrastructure to complicate takedowns and hide C2.
What Lumma Stealer does — capabilities and impacts
Lumma Stealer is a commercial infostealer product used by multiple threat actors. Its capabilities include:
- Browser credential theft: extracting saved logins, cookies, tokens, and autofill data from Chromium and Firefox profiles.
- Process injection: injecting into browser processes to extract in-memory secrets or bypass locked profiles.
- Wallet and crypto targeting: harvesting keys or mnemonic phrases stored in browser extensions and local files.
- Two‑factor token harvesting: capturing OTPs or 2FA tokens when they are available in storage or browser sessions.
- Exfiltration: sending stolen data to attacker-controlled C2 endpoints, which may be rotated or hidden via decentralized channels.
The real-world impact is severe: an infection can lead to account takeovers, financial theft, social engineering using stolen identity data, and lateral movement inside corporate environments when reused credentials provide additional access.
Why this vector is especially dangerous for organizations
- User-initiated execution removes many barriers: Because users paste and run the command themselves, browser-level and email-based protections are circumvented.
- Terminal legitimacy reduces automated scrutiny: EDRs and sandboxing solutions that apply different policies based on parent process and execution context may give Terminal-originated commands the benefit of doubt.
- Use of signed/legitimate binaries: Side-loading or using utilities like 7-Zip, MSBuild, and others reduces signature-based detection and increases dwell time.
- Multi-stage, obfuscated payloads: These increase analysis time, hampering rapid incident response.
- Credential-focused outcome: Stolen browser vaults, cookies, and tokens are high-value and enable follow-on attacks such as account takeover and fraud.
Because the attack depends on a single user action, it can scale widely through ad networks, malicious redirects on high-traffic sites, or mass mailings that bait users toward the exploit page.
Detection: what defenders should look for
Detecting these attacks requires a combination of endpoint visibility, telemetry correlation, and user awareness signals. No single signal will be definitive; defenders should hunt for combinations.
High‑value telemetry and host indicators:
- Command-line logging: look for encoded PowerShell commands executed under Windows Terminal processes. Suspicious flags include long Base64 blobs, Invoke‑Expression usage, or commands that write to %TEMP% and spawn network connections.
- Anomalous parent-child relationships: Terminal spawning network connections to suspicious domains, or Terminal invoking PowerShell/7z/MSBuild in rapid succession.
- Unsigned/relocated utilities: 7z.exe or other archive tools appearing in non-standard temporary directories.
- Defender exclusion modifications: registry edits or scheduled tasks that add exceptions to Microsoft Defender.
- Process injection or hollowing: indicators of browser process tampering, such as unexpected DLLs or unusual allocation patterns inside browser processes.
- Network indicators: connections to newly registered or obfuscated domains, especially if combined with blockchain-based infrastructure usage that attempts to hide C2.
- Persistence artifacts: scheduled tasks, Startup folder additions, or registry Run keys tied to odd executables in temp paths.
Practical detection tips:
- Enable detailed command-line auditing for PowerShell and terminal processes.
- Deploy Sysmon or equivalent system monitoring to log process creation, network connections, and file changes.
- Configure EDR to alert when signed Microsoft tools (like MSBuild) are used with unusual command line arguments or network behavior.
- Monitor clipboard hijack patterns at the browser or ingress filtering level where possible.
Immediate response and remediation steps for suspected infection
If you suspect a machine has executed such a command and may be infected, act quickly and methodically.
- Isolate the device from the network. This prevents further exfiltration and lateral movement.
- Preserve volatile evidence. Collect memory images and process lists if your team can do so safely for later forensic analysis.
- Perform a full scan with reputable endpoint protection and complement with offline/boot-time scanning tools.
- Look for persistence and remove it. Check scheduled tasks, Registry Run keys, Startup shortcuts, and unusual services. Remove or disable identified persistence mechanisms.
- Audit Defender exclusions and undo unauthorized changes. Re-enable protections the malware may have disabled.
- Reset credentials and tokens. Any accounts that were accessed from the infected machine should have passwords and 2FA tokens rotated. Consider force‑signing users out of web sessions and revoking tokens.
- Rotate secrets and certificates that may have been stored or cached on the host.
- Assess scope. Search for the same indicators of compromise across your estate using EDR and SIEM queries.
- Notify stakeholders and, if appropriate, law enforcement. If financial or personal data was exfiltrated, consider legal obligations and regulatory reporting.
- Reimage the host if necessary. If uncertainty remains about persistence or rootkits, a full reimage and restore from known good backups is the safest course.
For home users, simpler steps apply: disconnect, create a backup image for analysis if desired, run full offline AV scans, change passwords from a known-clean device, and notify banks if financial credentials may be impacted.
Preventive controls and policy recommendations
Stopping ClickFix variants that abuse Terminal requires both technical controls and user training.
Technical controls:
- Restrict the execution of scripts and one‑liners via AppLocker or Windows Defender Application Control (WDAC) policies. Only allow signed scripts from trusted locations.
- Constrain PowerShell. Enable PowerShell logging and set constrained language mode where practical.
- Harden Windows Terminal usage in managed environments by restricting access to specific users or whitelisting allowed instances.
- Disable or monitor clipboard execution behaviors in browsers and consider browser extensions or endpoint tools that block or warn on clipboard pastes from untrusted pages.
- Block execution of archives and utilities from temp directories. Only allow approved binaries from system locations.
- Use enterprise password vaults and agent-based authentication for sensitive applications, reducing reliance on browser-stored credentials.
- Endpoint detection rules: create behavioral rules that flag Terminal→PowerShell→network download chains and the creation of artifacts in TEMP with high-entropy filenames.
User-focused controls:
- Train staff on ClickFix tactics: emphasize that legitimate sites and services do not ask users to paste commands into system dialogs or terminals for verification.
- Simulated phishing campaigns that include clipboard and Run/Terminal scenarios can build institutional awareness.
- Clear policy: require that any troubleshooting guidance that asks for system-level commands be validated via an independent channel (phone, ticketing system, or IT helpdesk) before execution.
Critical analysis — strengths, gaps, and the attacker advantage
The Terminal-anchored ClickFix variant demonstrates the attackers’ pragmatic approach: they move into a slightly different execution context to dodge detection while relying on tried-and-tested human fallibility.
Strengths of the attack:
- High social-engineering leverage: convincing UI overlays and contextual messaging make the trap plausible.
- Low initial technical complexity: attackers rely on the victim to do the heavy lifting (paste and execute), which simplifies infection logistics.
- Operational flexibility: multiple staging paths (archive side-loading, script chains, EtherHiding) mean defenders must hunt across multiple telemetry domains.
- Leverages legitimate tooling: using Windows Terminal and common signed utilities reduces suspiciousness and increases the chance of a successful deploy.
Gaps and constraints:
- Requires user interaction: unlike many phishing attachments or drive‑by downloads, the campaign needs an active user decision. Effective awareness programs can blunt this vector.
- Observable patterns exist: even though Terminal is legitimate, the combination of encoded commands, temporary 7z copies in odd folders, and outbound connections to new domains can be detected by good EDR and SIEM correlation.
- Post-takedown resilience varies: Lumma Stealer’s infrastructure has been the target of law enforcement action before. While arrests and domain seizures impede operations, the underlying techniques can be adopted by other stealer families quickly.
Wider risk assessment:
- The surge in ClickFix-style attacks in 2024–2026 shows that social engineering is frequently the path of least resistance. Even when a malware family (like Lumma) is disrupted, the tools and distribution techniques persist because the human attack surface remains vulnerable.
- Enterprises that rely on browser‑stored credentials or lax session protections are particularly exposed; stolen cookies and tokens can enable immediate account takeovers even if passwords are later changed.
Final recommendations — how to harden against the Terminal-enabled ClickFix campaign
For IT teams, a layered strategy will be most effective:
- Reduce the attack surface: apply application control, restrict script execution, and limit who can run administrative tools like Terminal.
- Harden endpoints: enable PowerShell and Terminal auditing, deploy Sysmon, and monitor for suspicious parent/child process sequences.
- Elevate authentication hygiene: move away from browser-stored credentials; enforce strong MFA and use hardware-backed second factors where possible.
- Educate users: train staff to treat any instruction to paste commands into system dialogs as a red flag and require independent verification from IT.
- Prepare incident response playbooks: ensure teams can isolate, collect artifacts, and rotate credentials quickly after suspected exposure.
For individual users:
- Never paste commands from an untrusted web page into Run, Terminal, or PowerShell.
- If you mistakenly execute a pasted command, disconnect from the network immediately, run a full antivirus/antimalware scan from a clean medium, and change your passwords from a different, clean device.
- Use a reputable password manager instead of saving credentials directly in the browser.
Conclusion
The ClickFix scam’s migration from the Run dialog to
Windows Terminal is small in UI terms but significant in operational impact. By shifting the execution context to a legitimate, commonly used administrative tool, attackers increase the likelihood of bypassing heuristics and tricking users who already trust their terminal environment. Once the trick succeeds, payloads like
Lumma Stealer can extract high‑value secrets from browsers and vaults, enabling account takeovers and financial fraud.
Defenders can blunt this threat by combining technical controls (application allowlists, PowerShell restrictions, detailed telemetry), vigilant detection rules that correlate Terminal-originated activity with network downloads and persistence artifacts, and ongoing user training that treats any request to paste and run system commands as an immediate red flag. The underlying lesson is unchanged from earlier ClickFix waves: human behavior remains the pivot point of the attack, and only a layered, people‑plus‑technology defense will keep this class of social engineering effective.
Source: theregister.com
Microsoft spots ClickFix scam spreading Lumma infostealer