Blocking ClickFix attacks with layered Intune policies

ClickFix is a social engineering technique that tricks users into running malicious commands on their own machines. It has been around for a while, but the tradecraft keeps evolving.

The latest variant tells the user to press Win+X then I to open Windows Terminal, then paste in an attacker-supplied command. It looks like a normal verification step. It is not.

This is a problem because most traditional controls do not catch it. I built a tool to deploy layered Intune policies that block the attack across multiple surfaces. It deploys in audit mode by default so you can validate the impact before switching to enforcement.

The attack

The ClickFix flow works like this:

User visits a compromised or attacker-controlled page
A fake prompt tells them to “verify” by pressing Win+X → I
Windows Terminal opens as a standard user
The user pastes attacker-supplied PowerShell or cmd commands
The commands execute in a legitimate-looking environment

The reason this works is that wt.exe is launched via the system power-user menu, not the Run dialog. Older detections that watch for Win+R paste-and-execute do not fire.

Why a single policy is not enough

You might think blocking powershell.exe or cmd.exe with a single policy covers it. It does not, for a few reasons.

DisallowRun does not work here. The “Don’t run specified Windows applications” policy only intercepts processes spawned by explorer.exe. When the user opens Windows Terminal via Win+X → I, the process chain is:

ShellExperienceHost → wt.exe → powershell.exe

explorer.exe is not the parent, so DisallowRun never fires.

AppLocker is unreliable on Pro. AppLocker only enforces on Windows Enterprise and Education. On Windows Pro, policies are accepted silently but never enforced. Intune will show the profile as “Applied” while providing zero protection.

That is why I went with a layered approach using three policy types that actually enforce across all supported editions.

Defence architecture

The tool deploys three layers. Each covers a different part of the attack surface.

1) Settings Catalog - block CMD and Registry Editor

This is a user-scope ADMX policy delivered through Intune. It blocks:

CMD prompt (including batch files)
Registry Editor

This covers the simple cases where an attacker tells a user to open cmd via the Run dialog or tries to import a .reg file.

2) ASR rules - defence in depth against scripts

Attack Surface Reduction rules add a second layer. The tool deploys four rules:

Block obfuscated scripts
Block untrusted executables based on prevalence and age
Block executable content from email and webmail
Block process creation from PSExec and WMI

These do not directly block the Win+X → I path, but they catch adjacent tradecraft that often accompanies ClickFix campaigns.

Note: ASR rules require Microsoft Defender for Endpoint.

3) WDAC - kernel-level executable blocking

This is the most important layer. App Control for Business (WDAC) operates at the kernel level as a code integrity policy. It blocks executables regardless of how they were launched.

The tool blocks:

powershell.exe
pwsh.exe
wt.exe (Windows Terminal)
mshta.exe
cscript.exe
wscript.exe

cmd.exe is not included in the WDAC deny list because it is already blocked by the Settings Catalog layer. Doubling up adds complexity without adding protection.

WDAC uses OriginalFileName from PE headers for deny rules. Renaming the executable does not bypass it.

Why WDAC over AppLocker? WDAC enforces on Pro, Enterprise, and Education editions (since Windows 10 1903). AppLocker only enforces on Enterprise and Education, making it useless for mixed estates with Pro devices.

WDAC is device-scoped. Unlike AppLocker, WDAC does not have per-user rules. It applies to all users on the device. Admin exemption is handled by targeting the policy at specific device groups in Intune, not by user-level exclusions.

Prerequisites

Before deploying, you need:

PowerShell 7+ (Windows PowerShell 5.1 is not supported)
Microsoft Intune licensing (included in M365 E3/E5, Business Premium)
Microsoft Defender for Endpoint (for ASR rules)
Windows 10 1903+ or Windows 11 on target devices
Global Administrator or Intune Administrator role
Target devices enrolled in Intune via MDM

Important: Devices must be enrolled in Intune (MDM) for these policies to take effect. Entra ID registered devices (BYOD/workplace join) without MDM enrolment will not receive Intune configuration policies.

How to deploy

Before you start

Confirm you have the right licence and admin role
Understand that the script deploys in audit mode by default. Use the -Enforce flag when you are ready to switch to blocking
Ensure admins have an alternative management path (Azure Cloud Shell, remote PS, or a PAW not in the target group)
Test on a small number of devices before broad rollout

Phase 1: Clone and configure

Step 1. Clone the repo.

git clone https://github.com/benwildman/Click-Fix-Intune-Helper.git
cd Click-Fix-Intune-Helper

Step 2. Open and review the config file.

notepad .\config\policy-config.json

All policy settings are externalised here. You can change display names, toggle individual layers on or off, and switch WDAC between Enforce and Audit mode.

Phase 2: Deploy in audit mode

Step 3. Run the deploy script. An interactive browser login prompt will appear for Microsoft Graph authentication. The script deploys in audit mode by default.

.\Deploy-ClickFixProtection.ps1 -CreateGroup

This creates all three policy layers in Intune and the Entra ID security group. WDAC deploys with Enabled:Audit Mode, so blocked executables are logged but still allowed to run. ASR rules deploy in audit mode too.

Step 4. (Optional) Dry run first to validate without creating anything.

.\Deploy-ClickFixProtection.ps1 -WhatIf

Step 5. (Optional) Deploy without creating the security group.

.\Deploy-ClickFixProtection.ps1

Phase 3: Validate in audit mode

Step 6. Add one or two test devices to the target group. Navigate to Entra ID → Groups → ClickFix-Protection-Devices and add device objects (not users). WDAC is device-scoped, so the group must contain device memberships.

Step 7. Verify the policies in Intune. Check two locations:

Settings Catalog and ASR: Intune → Devices → Configuration profiles
WDAC: Intune → Endpoint Security → Application Control

Confirm all created policies show “Assigned”.

Step 8. On the test device, attempt the actions you want to block (open PowerShell, Windows Terminal, run scripts) and check the event logs:

Layer	Event log	Event ID	What to look for
WDAC	Microsoft-Windows-CodeIntegrity/Operational	3076	Each blocked executable should appear
ASR	Microsoft-Windows-Windows Defender/Operational	1122	Triggered ASR rule GUIDs

Check that audit events appear for the executables in your deny list and that no unexpected entries show up for system-critical binaries or legitimate applications.

Step 9. Leave audit mode running for at least a few days across representative devices. Check for edge cases like scheduled tasks, login scripts, or third-party tools that may invoke the blocked executables.

Phase 4: Switch to enforce mode

Once the audit logs confirm everything looks right, redeploy with the -Enforce flag:

# Remove audit-mode policies
.\Remove-ClickFixProtection.ps1 -Force

# Redeploy in enforce mode
.\Deploy-ClickFixProtection.ps1 -Enforce -CreateGroup

After enforcement:

Win+R → cmd should show “disabled by administrator”
Win+R → regedit should be blocked
Win+X → I should be blocked by WDAC
Direct powershell.exe launch should be blocked
WDAC events change from Event ID 3076 (audit) to 3077 (enforce)
Devices not in the target group should be unaffected

You can also switch the WDAC policy from audit to enforce directly in Intune without redeploying. Navigate to Endpoint Security → Application Control, open the WDAC policy, edit the SiPolicy XML, and remove the Enabled:Audit Mode rule block.

Graph permissions

The tool uses Microsoft Graph PowerShell, which is a first-party Microsoft enterprise application. It requests two delegated scopes:

DeviceManagementConfiguration.ReadWrite.All for creating, assigning, and deleting Intune policies
Group.ReadWrite.All for creating and managing the Entra ID security group (only when -CreateGroup is used)

These are delegated permissions. They run in the context of the signed-in user and are limited by that user’s Entra ID role. No application-level permissions are used.

Rollback

A dedicated rollback script is included:

# Interactive removal with confirmation
.\Remove-ClickFixProtection.ps1

# Dry run
.\Remove-ClickFixProtection.ps1 -WhatIf

# Skip confirmation prompts
.\Remove-ClickFixProtection.ps1 -Force

# Also remove the Entra ID security group
.\Remove-ClickFixProtection.ps1 -IncludeGroup

The script discovers all ClickFix policies by matching display names from the config file and handles all three layers. Policies are removed from devices on the next Intune sync cycle.

Final thought

ClickFix works because it abuses trust in the operating system’s own UI. Traditional controls like DisallowRun and AppLocker do not cover the Win+X → I launch path, and on Pro devices, AppLocker does nothing at all.

Deploy in audit mode first. Validate the logs. Then enforce. It takes longer, but it means you will not accidentally break something in production.