How to Harden PowerShell and the Windows Run Dialog Against Paste-and-Run Attacks

Paste-and-run intrusions like the TerminalFix campaign Microsoft documented in August 2026 all depend on one assumption: that a standard user can open a shell and execute whatever script lands on their clipboard. Take that assumption away and the entire attack chain fails at the first step, no matter how convincing the fake CAPTCHA. This is a practical guide to the controls that remove it. None of these are exotic; they are built into Windows and Microsoft's endpoint tooling, and most organizations simply have not turned them on.

Start by Removing Script Execution From Standard Users

The single highest-impact control is preventing non-administrative users from running arbitrary PowerShell. Use AppLocker or App Control for Windows (formerly Windows Defender Application Control) to restrict which scripts and binaries standard users can execute. The goal is not to break legitimate administrative workflows (administrators and signed management tooling still run) but to ensure that an unsigned script pasted from a website has nowhere to run.

Pair this with PowerShell's own execution policy. Set it to AllSigned or at minimum RemoteSigned so that scripts pulled from the internet will not execute without a trusted signature. Execution policy is not a security boundary by itself, since a determined operator bypasses it trivially, but in combination with application control it raises the cost of the paste-and-run step considerably.

Enforce Constrained Language Mode

PowerShell Constrained Language Mode restricts access to the sensitive language elements that malware relies on: arbitrary .NET type instantiation, Win32 API calls, and COM object creation. Legitimate administrative scripting largely continues to work, while the in-memory tradecraft used by staged loaders is blocked. When application control is enforced, PowerShell can be configured to drop automatically into Constrained Language Mode for untrusted scripts, which makes it a natural companion to AppLocker rather than a separate project.

Lock Down the Run Dialog and Windows Terminal

Because paste-and-run campaigns increasingly target Windows Terminal and PowerShell directly rather than the Run dialog, both need attention. Microsoft's guidance for these campaigns is specific: block or audit the Windows Run dialog (Win+R), and create an application-control policy that prohibits launching native Windows binaries directly from Run. Configure Windows Terminal to warn users when the text they are about to paste contains multiple lines. That single, well-placed prompt interrupts the exact behavior these attacks require.

Turn On the Telemetry You Will Need Later

Hardening reduces the attack surface; logging lets you detect what slips through. Enable PowerShell script block logging so that obfuscated or encoded commands are recorded in full, even when the visible command line is short. Enable module and transcription logging where practical. This telemetry is what makes it possible to reconstruct an intrusion after the fact and to write detections for the specific tradecraft, for example alerting when a signed binary executes from an unexpected directory, a hallmark of DLL sideloading.

Add Attack Surface Reduction Rules

Microsoft Defender's Attack Surface Reduction (ASR) rules add behavioral guardrails that complement application control. The rules that matter most here block execution of potentially obfuscated scripts, block executable files that do not meet a prevalence or trust threshold, and block script interpreters from launching downloaded executables. These rules target the exact transitions a staged loader depends on, and they apply regardless of how the initial script was delivered.

Put It in Order

A sensible rollout looks like this. First, deploy application control in audit mode to understand what your users actually run, then enforce it to block unsigned scripts for standard users. Second, set execution policy and enforce Constrained Language Mode. Third, restrict the Run dialog and configure Windows Terminal paste warnings. Fourth, enable script block logging and ASR rules. Layered this way, a user who falls for a ClickFix lure (and some always will) simply cannot execute the payload, and if something does slip through, you have the telemetry to catch the reverse-tunnel implant that campaigns like TerminalFix ultimately try to deploy.