# The Tool Your Devs Love and Your Security Team Ignores: PowerToys Just Got More Powerful
Microsoft's PowerToys utility suite quietly shipped another capability last week — Alt+Tab-style window switching scoped to a single application's instances. For developers and power users juggling dozens of open windows, it's a genuinely useful workflow improvement. For enterprise security teams, it's a reminder that a tool running on hundreds of their endpoints with broad system access is still largely invisible to their monitoring stack.
That gap deserves attention.
## What PowerToys Actually Is
If your mental model of PowerToys is the 1990s toy that shipped with Windows 95, update it. The modern PowerToys is an open-source suite of system utilities maintained by Microsoft itself, installable via the Microsoft Store or GitHub, and running at a privilege level that gives it deep hooks into keyboard input, window management, screen rendering, and file system operations.
The new window-switching module follows a familiar PowerToys pattern: take something Windows does adequately, and do it significantly better. In this case, the standard Alt+Tab switcher shows every open window across every application. The new behavior lets users cycle through only the windows belonging to a specific app — the same paradigm macOS has offered for years. Useful, obviously.
But the feature itself is almost beside the point for anyone thinking about enterprise risk.
## The Attack Surface You're Probably Not Modeling
PowerToys modules are not lightweight widgets. FancyZones — the window layout manager — hooks into the Windows shell. The Run launcher intercepts keystrokes system-wide. File LockSmith interacts with file handles and process lists. Color Picker reads pixel data from anywhere on screen. These are exactly the primitives a sophisticated attacker wants access to after initial compromise.
The legitimate use of these primitives is what makes them dangerous. When defenders build detection rules, they typically focus on known-bad binaries and behaviors. A process using SetWindowsHookEx to capture keystrokes is suspicious — unless it's PowerToys, which has been user-installed, is signed by Microsoft, and appears in add/remove programs. The same API call, same result, different detection outcome.
This is the LOLBins problem applied to first-party utilities. Living Off the Land Binaries refers to the attacker technique of using tools already present in the environment — certutil.exe, mshta.exe, rundll32.exe — to avoid introducing new malicious binaries. PowerToys isn't a traditional LOLBin (it's not a Windows system component), but it occupies a similar trust tier in practice. If it's already installed and signed by Microsoft, defenders who haven't explicitly modeled it are flying blind.
## Three Modules Worth Watching
Not all PowerToys modules carry equal risk. These three deserve explicit review in your threat model:
Run (the application launcher): Extends beyond app launching into plugin execution. Third-party plugins — from the PowerToys community and GitHub — can be added and execute with the same trust context as PowerToys itself. Plugin vetting is the user's responsibility. In an enterprise, that means an employee can extend a Microsoft-signed utility with arbitrary code from GitHub.
File LockSmith: Surfaces which processes have locked a given file and can force-unlock them. In the wrong hands post-compromise, this is a clean way to release file locks that would otherwise block ransomware's encryption pass. Most ransomware operators are already doing this with their own tools, but using a trusted Microsoft-distributed binary reduces detection likelihood considerably.
Always on Top: Keeps any window pinned above others and communicates with the Windows compositor directly. Not high-risk on its own, but it's another hook that maintains persistent process presence with legitimate cover.
## The Supply Chain Angle Nobody Is Discussing
PowerToys' plugin ecosystem is informal and growing. The official plugin directory is community-driven. There's no meaningful vetting process — contributors submit plugins, they get listed, users install them. The trust chain here is: user trusts Microsoft's PowerToys → Microsoft-signed PowerToys loads community plugin → plugin runs with PowerToys' access level.
That's a supply chain concern worth naming explicitly, especially as the tooling matures and the plugin catalog grows. We've seen this exact pattern play out with VS Code extensions, browser extensions, and npm packages. The attack surface expands in direct proportion to ecosystem growth, and ecosystem growth is exactly what Microsoft is optimizing for.
The new window-switching feature is part of a broader project roadmap that's clearly trying to expand PowerToys' usefulness — and therefore its adoption. More adoption means more endpoints. More endpoints means a larger installed base for any future compromise of the build pipeline, signing infrastructure, or plugin ecosystem.
## What Defenders Should Actually Do
If your endpoint fleet has PowerToys installed and you haven't explicitly catalogued it, start there. A quick query in your EDR for PowerToys.exe parent processes and child processes will tell you what's running and what it's spawning.
More importantly, assess your plugin exposure. If users can install Run plugins without IT approval, you have an unmanaged code execution vector on signed-binary rails. Locking plugin installation via AppLocker or similar policy isn't difficult and removes the most realistic exploitation path.
For SOC teams building detection content: PowerToys behavior is largely predictable and documentable. Model the legitimate baseline — what processes does it spawn, what registry keys does it touch, what network connections does it make (spoiler: almost none in normal use). Any deviation from that baseline is worth querying.
Finally, watch the update channel. PowerToys auto-updates by default. That's good for patching, but it also means any compromise of the PowerToys release pipeline propagates automatically to every endpoint with it installed. This isn't hypothetical — Microsoft's own build infrastructure has been targeted before, and a signed auto-updating utility is exactly what an adversary would want to weaponize.
---
## HackWire Analysis
The PowerToys story lands in a recurring blind spot: enterprise security teams model threats from external adversaries but consistently underestimate the attack surface presented by legitimate, Microsoft-distributed tooling that IT didn't explicitly provision.
PowerToys sits in an awkward tier. It's not an OS component, so it doesn't get the same scrutiny as lsass.exe or the Windows Task Scheduler. It's not a third-party ISV product, so it doesn't go through formal vendor security review. It's a Microsoft open-source project, distributed through the Store, signed with Microsoft's certificate, and functionally invisible to most security programs.
The new window-switching module is inconsequential on its own. But it's a good hook for a conversation that enterprise security teams should already be having. As PowerToys capabilities expand and its plugin ecosystem grows, the installed base will follow. We're watching the early innings of a LOLBin-adjacent problem develop in slow motion.
The comparison to VS Code extensions is apt and underappreciated. VS Code went from developer curiosity to near-universal enterprise deployment in roughly five years, and its extension ecosystem is now a serious supply chain risk vector that most organizations still haven't fully addressed. PowerToys is on a similar trajectory at smaller scale — but the system access its modules require is, in some ways, more invasive than anything a VS Code extension touches.
The time for security teams to model this threat is before an incident, not after. The playbook isn't complicated: inventory it, baseline it, restrict plugin installation, and build detection around its known-good behavior. The teams that do this now will have a significant advantage when (not if) someone weaponizes a PowerToys module or plugin.
— HackWire Editorial
---
## Related Coverage