Microsoft PowerToys 0.102 Ships CursorHide and Button Lock — What Defenders Need to Know About Utility Software Governance

Microsoft has released PowerToys 0.102, the latest iteration of its open-source Windows utility suite, introducing two new mouse utilities — CursorHide and Button Lock — alongside new command-line tools and refinements to the Command Palette launcher. On its face, this is a productivity update, not a security bulletin. No CVEs are attached to this release, and there's no indication of active exploitation.

But if you've spent any time running a SOC or managing endpoint hygiene at scale, you know that utility software releases are exactly the kind of event that quietly reshapes your attack surface. PowerToys runs with user-level (and in several modules, elevated) privileges, installs shell extensions, registers global hotkeys, injects into the window manager pipeline, and ships with an auto-updater. Every new module is new code executing on your endpoints. Every new CLI tool is a new binary your application control policy needs an opinion about.

This post isn't about panic — it's about treating PowerToys like what it actually is: powerful, Microsoft-signed, frequently updated software that your users love and your detection engineering team probably hasn't written a single rule for.

What's New in PowerToys 0.102

Based on the release details:

• CursorHide — a mouse utility that automatically hides the mouse cursor (useful for presentations, screen recordings, and reducing visual clutter).
• Button Lock — a mouse utility that locks mouse buttons, primarily aimed at drag-and-drop workflows and accessibility scenarios.
• New command-line tools — extending PowerToys' growing CLI surface, allowing scripted invocation of utilities.
• Command Palette improvements — continued investment in PowerToys' launcher, which has increasingly become a central execution point for apps, files, calculations, and system commands.

PowerToys is distributed via the Microsoft Store, GitHub releases, and WinGet, and includes a built-in auto-update mechanism. That last point matters: endpoints can move to 0.102 without any action from your software deployment team.

Why Defenders Should Care (Even Without a CVE)

There's no vulnerability here. There is, however, a recurring operational reality:

1. Shadow update channels bypass your change management. If PowerToys auto-updates but your vulnerability scanner doesn't inventory it, your asset truth drifts. You can't assess exposure on software you don't know is installed.
2. Utility suites are persistence and execution surface. PowerToys registers startup entries, shell extensions, and background processes (PowerToys.exe, PowerToys.*.exe module processes, PowerToys.Settings.exe). Historically, third parties have abused legitimate signed utilities for execution and persistence, and Microsoft-signed binaries routinely bypass naive application whitelisting that trusts the signer alone.
3. Command Palette and launchers are execution chokepoints. Any tool that lets a user (or a script, or an attacker with hands-on-keyboard) launch arbitrary commands from a single interface deserves baseline logging. The new CLI tools in 0.102 extend this further — CLI-invokable utilities can be scripted, which means they can appear in intrusion tooling.
4. Version sprawl creates real patch debt. Machines stuck on older PowerToys builds — whether because auto-update was disabled or the Store is blocked — accumulate whatever bugs older versions carried. Governance means knowing your fleet's version distribution.

None of this means "ban PowerToys." It means: inventory it, version-pin it where feasible, and monitor its execution like any other privileged utility.

Exploitation Status

No CVEs are associated with PowerToys 0.102, no proof-of-concept exploitation has been reported against this release, and there is no CISA KEV entry relevant to this update. This release is not an emergency patch event — it is a governance and visibility event.

Detection & Response

The defensive value here is inventory and behavioral baseline, not IOC matching. The rules and queries below are tuned to answer three questions: Where is PowerToys installed? What version is running? Is anything unusual executing through it?

Sigma

The most useful detections for utility software like PowerToys are (a) installation/update events so you maintain asset truth, and (b) anomalies where PowerToys processes spawn unexpected children — a pattern worth watching for any always-on signed utility. The second rule is deliberately narrow: PowerToys modules spawning script interpreters or shells is rare in normal use.

---
title: PowerToys Installation or Update Execution
id: 3f7c2a91-8b4d-4e6a-b2f1-9d5e6a7c8b9d
status: experimental
description: Detects installation or update of Microsoft PowerToys via WinGet, Store deployment, or the standalone installer to support endpoint software inventory and change management.
references:
  - https://www.bleepingcomputer.com/news/microsoft/microsoft-powertoys-adds-cursorhide-button-lock-mouse-tools/
  - https://github.com/microsoft/PowerToys
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.execution
logsource:
  category: process_creation
  product: windows
detection:
  selection_winget:
    Image|endswith: '\winget.exe'
    CommandLine|contains:
      - 'PowerToys'
      - 'Microsoft.PowerToys'
  selection_installer:
    CommandLine|contains:
      - 'PowerToysSetup'
      - 'PowerToysUserSetup'
  condition: 1 of selection_*
falsepositives:
  - Legitimate user or administrator installation of PowerToys
level: informational
---
title: PowerToys Process Spawning Script Interpreter or Shell
id: 8e1d4b62-3c5a-4f7e-a1d2-6b9c8e5f2a3d
status: experimental
description: Detects PowerToys module processes spawning command shells or script interpreters. PowerToys utilities do not normally launch cmd, PowerShell, or WScript; this pattern may indicate abuse of the signed utility suite or malicious configuration.
references:
  - https://attack.mitre.org/techniques/T1059/
  - https://github.com/microsoft/PowerToys
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.execution
  - attack.t1059
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|contains:
      - '\PowerToys\'
    ParentImage|endswith:
      - '\PowerToys.exe'
      - '\PowerToys.PowerLauncher.exe'
      - '\PowerToys.Settings.exe'
  selection_child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\mshta.exe'
  condition: selection_parent and selection_child
falsepositives:
  - PowerToys developer tools or community plugins invoking shells for legitimate automation
level: medium

KQL — Microsoft Sentinel / Defender

This query builds your fleet inventory: it reports distinct devices, installed version evidence via process execution paths, and flags anything not on the current release so your endpoint team can reconcile drift.

// PowerToys fleet inventory and version drift analysis
let CurrentVersion = "0.102";
DeviceProcessEvents
| where TimeGenerated > ago(30d)
| where FileName startswith "PowerToys" or ProcessCommandLine contains "PowerToys"
| extend Version = extract(@"PowerToys[\\/](\d+\.\d+\.\d+\.\d+|\d+\.\d+)", 1, FolderPath + ProcessCommandLine)
| summarize LastSeen = max(TimeGenerated),
            DistinctProcesses = dcount(FileName),
            Processes = make_set(FileName, 20),
            ObservedVersion = any(Version)
    by DeviceName, FolderPath
| extend Drift = iff(ObservedVersion contains CurrentVersion, "Current", "Review Required")
| project DeviceName, ObservedVersion, Drift, LastSeen, DistinctProcesses, FolderPath
| sort by LastSeen desc

A companion hunting query for the child-process anomaly:

// PowerToys modules spawning shells or script interpreters
DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where InitiatingProcessFolderPath contains "PowerToys"
| where FileName in~ ("cmd.exe", "powershell.exe", "pwsh.exe", "wscript.exe", "cscript.exe", "mshta.exe")
| project TimeGenerated, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine,
          FileName, ProcessCommandLine, AccountName, SHA256
| sort by TimeGenerated desc

Velociraptor VQL

Use this artifact during threat hunts or IR scoping to enumerate PowerToys installations and running module processes across endpoints — including version extraction from the install path, which follows a versioned directory layout under both per-user and machine-wide installs.

-- PowerToys fleet inventory: running modules and install paths
LET procs = SELECT Pid, Name, CommandLine, Exe, Username
FROM pslist()
WHERE Exe =~ '(?i)PowerToys'

SELECT Pid,
       Name,
       Username,
       Exe,
       CommandLine,
       regex_replace(source=Exe, re='(?i).*PowerToys[\\\\/]([0-9.]+)[\\\\].*', replace='$1') AS InstalledVersion
FROM procs

Verification & Hardening Script

This PowerShell script inventories PowerToys installations across local machine contexts (per-user and machine-wide), reports versions, and optionally disables the auto-updater in managed environments where updates should flow through your own software distribution pipeline (Intune, ConfigMgr, WSUS-adjacent tooling) rather than self-update.

# PowerToys inventory and governance verification
# Run elevated for machine-wide visibility; works per-user otherwise.

$report = @()

# Check machine-wide install (Program Files)
$machinePaths = @(
    "$env:ProgramFiles\PowerToys",
    "${env:ProgramFiles(x86)}\PowerToys"
)
foreach ($p in $machinePaths) {
    if (Test-Path $p) {
        $verDir = Get-ChildItem $p -Directory -ErrorAction SilentlyContinue |
                  Where-Object { $_.Name -match '^\d+\.\d+' } |
                  Sort-Object Name -Descending | Select-Object -First 1
        $report += [PSCustomObject]@{
            Scope   = 'Machine'
            Path    = $p
            Version = if ($verDir) { $verDir.Name } else { 'Unknown' }
        }
    }
}

# Check per-user installs (LocalAppData)
Get-ChildItem 'C:\Users' -Directory -ErrorAction SilentlyContinue | ForEach-Object {
    $userPath = Join-Path $_.FullName 'AppData\Local\PowerToys'
    if (Test-Path $userPath) {
        $verDir = Get-ChildItem $userPath -Directory -ErrorAction SilentlyContinue |
                  Where-Object { $_.Name -match '^\d+\.\d+' } |
                  Sort-Object Name -Descending | Select-Object -First 1
        $report += [PSCustomObject]@{
            Scope   = "User: $($_.Name)"
            Path    = $userPath
            Version = if ($verDir) { $verDir.Name } else { 'Unknown' }
        }
    }
}

$report | Format-Table -AutoSize

# Flag anything not on 0.102
$report | Where-Object { $_.Version -notlike '0.102*' } |
    ForEach-Object { Write-Warning "[$($_.Scope)] PowerToys version $($_.Version) is not current (0.102). Update via your managed channel." }

# Query currently running PowerToys processes
Get-Process | Where-Object { $_.Name -like 'PowerToys*' } |
    Select-Object Name, Id, Path | Format-Table -AutoSize

Remediation & Governance Recommendations

There's no vulnerability to patch, but there is work to do:

1. Establish inventory truth. Run the KQL inventory query or the PowerShell script against your fleet this week. If your EDR/software inventory doesn't already track PowerToys, add it — it's one of the most commonly self-installed Microsoft utilities in enterprise environments.
2. Decide your update channel policy. Either let PowerToys auto-update and accept the cadence, or disable auto-update and push versions centrally via WinGet/Intune (winget install Microsoft.PowerToys / winget upgrade Microsoft.PowerToys). The worst option is the unmanaged middle: some machines current, some months behind.
3. Update your application control policy. If you run WDAC or AppLocker, ensure your rules account for the new 0.102 binaries and the new CLI tools. Microsoft-signed alone should not be your only trust anchor for utility suites with scripting surfaces.
4. Review module enablement. PowerToys settings allow per-module toggles. In high-control environments, standardize which modules are permitted (and consider whether settings sync via OneDrive is acceptable for your data governance posture).
5. Baseline the child-process detection. Deploy the second Sigma rule in monitoring mode for two weeks. If your developers legitimately drive shells through PowerToys workflows, tune by ParentImage module name rather than disabling the rule.
6. Track the upstream project. PowerToys releases ship roughly monthly via github.com/microsoft/PowerToys. Subscribe to release notifications so 0.103 doesn't surprise you — release notes occasionally include security-relevant fixes buried among feature work.

Utility software governance is unglamorous, but it's the difference between a fleet you understand and a fleet you assume you understand. PowerToys 0.102 is a fine, legitimate release — make sure it's your release decision, not just your users'.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub