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 matterMatter🏠A new universal smart home standard backed by Apple, Google, and Amazon for cross-platform compatibility. 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 policyExecution Policy🛡️A PowerShell security feature that determines the conditions under which PowerShell loads configuration files and runs scripts, ranging from Restricted (no scripts) to Bypass (no restrictions).. 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 — it is trivially bypassed by a determined operator — but in combination with application control it raises the cost of the paste-and-run step considerably.

Enforce Constrained Language ModeConstrained Language Mode🛡️A PowerShell operating mode that restricts access to sensitive language features such as arbitrary .NET type instantiation and Win32 API calls, blocking common in-memory attack tradecraft while allowing most legitimate administrative scripting to continue.

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 — a single, well-placed prompt that interrupts the exact behavior these attacks require.

Turn On the Telemetry You Will Need Later

Hardening reduces the attack surfaceAttack Surface🛡️The sum of all points where an unauthorized user could attempt to enter or extract data from a system: exposed services, interfaces, accounts, and integrations. Reducing attack surface means removing reachability, not just patching.; 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 sideloadingDLL Sideloading🛡️An attack technique that places a malicious DLL alongside a legitimate signed executable so the Windows loader resolves and loads the attacker's library instead of the real one, running malicious code under the trust of the signed program..

Add Attack Surface Reduction Rules

Microsoft Defender's Attack Surface Reduction (ASR) rulesAttack Surface Reduction (ASR) Rules🛡️A set of configurable Microsoft Defender rules that block common malware behaviors, such as script interpreters launching downloaded executables or the execution of obfuscated scripts, adding behavioral guardrails independent of file signatures. 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.