Mitigating Win+X paste attacks with PowerShell settings

ClickFix mitigation

ClickFix-style lures have moved from Run (Win+R) to the Windows + X shortcut, then push victims to paste commands into Windows Terminal. Paste skips a lot of the usual warning signs and drops an attacker straight into a shell. The sensible response is a mix of user guidance, tighter execution control, and logging that actually shows what ran.

Tell users the simple rule: no legitimate support process should ever ask them to open Win+X and paste random text. Keep that message short, repeat it in onboarding, and put it in desktop prompts. If you run phishing tests, include the Win+X path and track the results.

Technical controls

• Block or limit how Windows Terminal (wt.exe) starts. Use AppLocker GPO rules or Windows Defender Application Control (WDAC) to restrict wt.exe to admin machines only. Where possible, allow it only from System32 paths and only for specific AD groups.
• Create AppLocker rules that deny execution of renamed binaries that copy trusted tools, for example 7z.exe renamed as 7-zip.exe. Use file hash or publisher rules for signed apps where you can.
• Limit LOLBin abuse. Write rules that keep MSBuild.exe, regsvr32.exe and rundll32.exe to expected paths and signing. Path plus publisher rules are usually less noisy than broad filename blocks.

Detection and response

• Turn on ScriptBlockLogging and ModuleLogging so pasted PowerShell shows up in event logs. Use transcription on sensitive hosts if you want a full record of session input.
• Audit scheduled tasks and services. Run Get-ScheduledTask and schtasks /Query to find odd entries. Scheduled tasks are a common persistence method after a ClickFix paste.
• Check Microsoft Defender exclusions. Use PowerShell to list them:

Get-MpPreference | Select -ExpandProperty ExclusionPath
Get-MpPreference | Select -ExpandProperty ExclusionProcess

Remove anything that gives an attacker room to work.

User controls and training

• Teach one rule: never paste commands from chat, email, or a web prompt. Show an example of a hex-decoding command and why it is malicious.
• Give users an approved sandbox or jump box for pasting harmless diagnostic commands when support really needs input. Make the process official and logged.

PowerShell hardening

Execution policy and language constraints

• Set a restrictive execution policy through Group Policy: Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell > Turn on Script Execution, set to “Allow only signed scripts”. On endpoints that do not need scripts, Set-ExecutionPolicy Restricted -Force does the job. Use GPO rather than local registry changes where possible so a non-admin cannot just flip it back.
• Use Constrained Language Mode for user sessions that do not need full language features. Apply AppLocker or WDAC rules to match allowed modules and block dynamic code features for standard users.

Logging and telemetry

• Enable ScriptBlockLogging and ModuleLogging through Group Policy or registry so pasted commands land in logs. The registry keys are:

HKLMSoftwarePoliciesMicrosoftWindowsPowerShellScriptBlockLoggingEnableScriptBlockLogging = 1
HKLMSoftwarePoliciesMicrosoftWindowsPowerShellModuleLoggingEnableModuleLogging = 1
HKLMSoftwarePoliciesMicrosoftWindowsPowerShellModuleLoggingModuleNames = *

• Turn on PowerShell transcription on high-risk hosts so full session input is recorded. Set the registry or GPO values under Windows PowerShellTranscription, and point the output to a central writable server.

Application control policies

• Use AppLocker GPO rules to allow only signed PowerShell scripts from trusted publishers, or hash rules for known in-house scripts. Start in audit mode, collect logs, then move to enforcement.
• On servers and high-value desktops, deploy WDAC with a baseline whitelist that permits only explicitly signed binaries. Managed policies cut down the admin overhead.

Detecting hex-encoded payloads and LOLBin techniques

• Add detection rules for the common decode patterns used in paste attacks. Watch for PowerShell expressions like:

[System.Text.Encoding]::UTF8.GetString([Convert]::FromBase64String(
[Convert]::FromBase64String(
[System.Text.Encoding]::Unicode.GetString([System.Convert]::FromBase64String(

• Add simple regex detection for hex sequences that may decode to shellcode, for example (?i)(?:0x)?([0-9A-F]{2}s?){30,}. Tune the length to cut false positives. Use the rule in your EDR or SIEM ingestion and in ScriptBlockLogging parsing.
• Watch for renamed trusted binaries. Alert when 7z.exe or 7za.exe run from user temp folders or Downloads, and when MSBuild.exe starts from a non-standard path or with a browser as the parent process.

Persistence cleanup and verification

• Run a regular sweep for suspicious persistence artefacts. Use PowerShell:

Get-ScheduledTask | Where-Object { $_.TaskPath -like '*MicrosoftWindows*' -or $_.Author -like '**' }
Get-Service
sc.exe query

Use those to flag odd tasks, unusual services, and unknown entries.

• Check and remove Microsoft Defender exclusions with:

$prefs = Get-MpPreference
$prefs.ExclusionPath
$prefs.ExclusionProcess
$prefs.ExclusionExtension
Remove-MpPreference -ExclusionPath "C:path	oad"

Use the removal command with care.

• Look for post-exploit signs: a renamed 7-Zip executable, scheduled tasks created shortly after a suspicious login, Defender exclusion changes, and child processes of browsers that point to process injection.

Operational steps to apply now

1. Turn on ScriptBlockLogging and transcription on the most exposed endpoints first. Check that the logs reach the SIEM.
2. Deploy AppLocker audit rules that block msbuild.exe and 7z.exe from non-system locations. Watch the blocked events.
3. Run a Defender exclusions audit and remove any unexpected entries. Log every change centrally.
4. Search recent ScriptBlockLogging events for hex-encoded strings and common decode calls. Flag any matches for investigation.
5. Train staff with a short triage script: if a page asks them to paste or run code through Win+X, close it, capture the URL, and contact support through the normal channel.

Reference: Computerworld technical advisory on ClickFix campaigns for threat context: https://www.computerworld.com/article/4141964/clickfix-attackers-using-new-tactic-to-evade-detection-says-microsoft-2.html