> ## Content Index
> Fetch the complete content index at: https://marshsecurity.org/llms.txt
> Use this file to discover other available public pages before exploring further.

# Protecting against ClickFix with the Microsoft Stack
- URL: https://marshsecurity.org/protecting-against-clickfix-with-the-microsoft-stack/
- Published: 2025-10-10T11:17:22.000Z
- Updated: 2026-05-24T17:07:29.000Z
- Author: Philip Marsh
- Tags: Identity, Microsoft Security, Guides

### Introduction

With the growing rise of cyber attacks, and the increased detections and awareness on the back of this, cyber attacks are constantly looking for creative ways to execute code on endpoints without triggering obvious detections. One such technique - known as **ClickFix -** has gained attention for its ability to abuse Windows shortcuts and keyboard functions to execute malicious commands stealthily, often tricking the user into completing what might seem like an ordinary task. 

Unlike traditional malware, ClickFix doesn’t rely on dropping executables or exploiting vulnerabilities. Instead, it **abuses legitimate Windows functionality** such as `.lnk` files, administrative tools, and keyboard shortcuts to perform malicious actions.

In this blog, we’ll explore what ClickFix is, why it’s effective, and (most importantly) how to **protect your environment using Microsoft-native security tooling**, including Intune, Windows Defender Application Control (WDAC), AppLocker, and Microsoft Defender XDR’s advanced hunting capabilities.

### What ***IS*** ClickFix?

ClickFix is a technique to attempt to execute malicious commands on a victim's device, relying on social engineering techniques. Attackers will attempt to convince the user to copy a long command (in the vast majority of cases - a PowerShell script) and paste into into the system's **Run** box, which would ultimately lead to system compromise. 

Ordinarily, the attack begins with a pop-up window which simulates a notification about a minor technical problem. To fix the issue, the user needs to perform a few simple steps, which boils down to copying a command and executing it through the Run application. 

#### Examples of ClickFix

![](https://marshsecurity.org/content/images/2025/10/image-4.png)

![](https://marshsecurity.org/content/images/2025/10/image-3.png)

## Blocking Administrative tools using InTune

There are many reasons why administrators may want to block administrative tools on their endpoints, with **ClickFix** only being one of these reasons. There are many ways that we can go about this. 

Please ensure that you explore the options below to see which works best for your requirements. MarshSecurity is ****not** responsible for any loss of productivity.

**To deploy this:**

1. Log into Intune and navigate to Windows > Devices > Configuration Profile
2. Create a new profile named appropriately (for example `Windows - D - Disable Admin Tools` )
3. In the **Administrative Templates**, set the following settings:
- **Prevent access to registry editing tools (user): E**nabled
- Prevent access to the command prompt (user): Enabled
- Don't run specified windows applications (user) – List of disallowed applications (user):  
  - Powershell.exe
  - regedit.exe
  - cmd.exe
  - WindowsTerminal.exe
  - mhsta.exe
  - OpenConsole.exe

## Disabling the run box

We can use the Registry Editor to entirely disable the Windows Run box, which is often abused to run the malicious code required for a ClickFix attack. 

### **To do this:**

**Intune Settings**

1. Log into Intune and create a new Windows Configuration Policy.
2. Name this appropriately, such as `Win - D - Remove Run Menu`
3. In the settings catalog, search for `Remove Run menu from Start Menu`
4. Configure this to enabled.
5. Deploy your policy to the selected user group as required.

**Registry:**

1. Open `RegEdit`
2. Navigate to `HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer`
3. Right-click on the right pane and select New > DWORD (32-Bit).
4. Name this new key `NoRun` and set the value to `1`
5. Restart your computer or log off to apply the changes.

Personally, I prefer to avoid this fix as this also breaks **UNC** paths, and therefore can cause an issue with applications that reference the path, such as: 

`\\yourshare\share1\files\`

## Restricting keyboard shortcuts

Since ClickFix attacks often ask a user to press Windows + R, or Windows +X, we can potentially limit the impact of these attacks by disabling these shortcuts outright. For example, you might wish to disable them for a standard user but allow for an administrative user. 

**To do this:**

1. In regedit, navigate to `HKCU:\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced`
2. Create a new key called **DisabledHotKeys** (Reg\_SZ)
3. In the value, set `REX` to block `Win + R`, `Win + E` and `Win + X` respectively.

Note that you can deliver this as a Powershell script via Intune to make life easier - I have an example script here: [https://github.com/Marshyp/Security-Scripts/blob/main/Intune/Hardening/Disable-WindowsHotkeys.ps1](https://github.com/Marshyp/Security-Scripts/blob/main/Intune/Hardening/Disable-WindowsHotkeys.ps1?ref=marshsecurity.org)

## App Locker

AppLocker provides a simpler approach to application control and is especially useful for smaller environments or pilot deployments.

#### Example AppLocker Rule:

- **Deny** execution of `powershell.exe` and `pwsh.exe` for standard users.
- **Allow** execution only for approved admin groups.

These rules can be deployed via Intune or Group Policy. 

💡

Remember to block Terminal for Windows 11 - This is often missed, and can be used to evade protections!

## WDAC - An easy win?

WDAC allows you to enforce strict **code integrity** policies, ensuring only trusted binaries and scripts can run.

#### Steps:

1. Create a WDAC policy with PowerShell restrictions, for example:
  - Allow PowerShell only in **Constrained Language Mode**.
  - Block execution of unsigned or unapproved scripts.
2. Deploy in **Audit Mode** first to monitor impact.
3. Transition to **Enforced Mode** once validated.

**HINT:** Did you know that deploying a WDAC policy, even in **Audit** mode actually blocks **MSHTA** \- Which is a binary that a lot of ClickFix attacks often abuse? Deploying a simple audit policy today could actually **significantly** improve your protections, for very little initial effort!

## Attack Surface Reduction

As always, you **absolutely** should have ASR rules in place, however if not then I would strongly advise that you enable: 

1. Blocking executable content from emails
2. Block Office processes from spawning child processes.

### MSHTA

Most ClickFix Threat Actors use **MSHTA** to conduct their attack. You can significantly reduce your attack surface by disabling this in your environment. Note that as above, a WDAC policy can do this for you. 

I would strongly recommend blocking this using a software restriction policy and then backing this up with a detection (and remediation) in Microsoft Defender for Endpoint. **It is NOT** enough to rename this file - It can (and will) be dropped again and abused. 

See: [https://learn.microsoft.com/en-us/defender-endpoint/migrating-asr-rules#block-mshta-from-launching-certain-child-processes](https://learn.microsoft.com/en-us/defender-endpoint/migrating-asr-rules?ref=marshsecurity.org#block-mshta-from-launching-certain-child-processes)

If you're interested in a deep-dive on how MSHTA is used in ClickFix attacks, there is a **really** good write-up by **Runtime.err0r** on Medium here: [https://medium.com/@djordje.brankovic/inside-a-fake-captcha-phishing-attack-how-attackers-use-mshta-exe-and-powershell-to-deliver-xworm-cc7cdfda95ce](https://medium.com/@djordje.brankovic/inside-a-fake-captcha-phishing-attack-how-attackers-use-mshta-exe-and-powershell-to-deliver-xworm-cc7cdfda95ce?ref=marshsecurity.org)

## Detecting potential ClickFix activity

#### Suspicious .lnk creation from Powershell or CMD

```
DeviceFileEvents
| where FileName endswith ".lnk"
| where InitiatingProcessFileName in ("powershell.exe", "cmd.exe", "explorer.exe")
| project Timestamp, DeviceName, FileName, FolderPath, InitiatingProcessFileName, InitiatingProcessCommandLine

```

#### Suspicious PowerShell Launches via Explorer

```
DeviceProcessEvents
| where InitiatingProcessFileName == "explorer.exe"
| where FileName in ("powershell.exe", "pwsh.exe")
| project Timestamp, DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine

```

#### Shortcut-Triggered Privilege Escalation Attempts

```
DeviceProcessEvents
| where FileName in ("cmd.exe", "powershell.exe")
| where InitiatingProcessFileName == "explorer.exe"
| where ProcessCommandLine contains "runas"
| project Timestamp, DeviceName, FileName, ProcessCommandLine

```

## Summary and recommendations

ClickFix exemplifies the new wave of **living-off-the-land (LOL)** techniques: simple, effective, and designed to blend in with legitimate activity whilst leveraging a natural human instinct to be helpful. 

To defend effectively:

- **Educate users:** Awareness of shortcut abuse and unexpected prompts can prevent initial execution.
- **Reduce attack surface:** Block administrative tools via Intune and restrict shortcut abuse via registry configuration.
- **Enforce application control:** Use WDAC or AppLocker to constrain PowerShell and unapproved binaries.
- **Increase visibility:** Leverage Defender XDR’s advanced hunting to detect suspicious `.lnk` and PowerShell behaviour, or modifications to sensitive registry keys.
- **Adopt least privilege:** Limit local admin rights and use Endpoint Privilege Management (EPM) for on-demand elevation.

With these layers combined, organizations can dramatically reduce their exposure to ClickFix-style attacks and other forms of shortcut-based exploitation.