A Sticky Keys exploit is a Windows logon attack that replaces the accessibility utility with a command shell, allowing a user to gain access before normal authentication. Technically, it abuses pre-login privilege and local file replacement to launch SYSTEM-level commands from the sign-in screen, often for persistence or credential access.
What the Sticky Keys exploit does
The Sticky Keys exploit abuses the Windows sign-in flow by swapping an accessibility binary for a command shell, so an attacker can run commands before normal authentication completes. Because the code executes at the logon screen, it can expose the system to local privilege abuse rather than a standard user-session boundary.
This matters because the attack does not need to wait for a successful login. It turns a pre-authentication convenience feature into an execution path that can be used for persistence, tampering, or further access on the same host.
How pre-logon replacement becomes SYSTEM-level access
The core weakness is trust in a file that Windows expects to be present and usable during logon. If an attacker can replace that utility, the sign-in screen can invoke attacker-controlled code with elevated context, which is why this technique is often associated with physical access, local admin abuse, or an already-compromised machine.
The mechanism is simple but powerful: the replacement happens on disk, and the trigger happens before the normal desktop is available. That makes the exploit useful in recovery-mode abuse, hands-on-keyboard intrusion, and post-compromise persistence scenarios.
For a broader view of how this fits into persistence tradecraft, see Persistence Techniques Guide, which covers logon autostart abuse, binary replacement, and related Windows persistence paths.
Exposure, detection, and verification
Organisations should treat this as both an endpoint integrity issue and a recovery-path abuse issue. Exposure increases when users or attackers can write to system locations that affect logon behavior, when recovery access is weakly controlled, or when local administrative rights are too broad for the device population.
Detection usually depends on confirming whether the expected accessibility binary and related logon artifacts still match the vendor baseline. A post-incident review should also check for nearby signs of persistence, because the same access that enables this technique often leaves behind additional changes such as scheduled tasks, services, or registry-based startup hooks.
For incident and compromise context, The State of NHI & AI Agent Breach Report 2026 is useful for understanding how stolen credentials, lateral movement, and persistence can follow an initial foothold.
Prevention and recovery discipline
The best defense is to make pre-logon system files hard to replace, limit who can obtain local administrative control, and monitor the device states where sign-in utilities live. Hardening recovery workflows matters too, because attackers often rely on repair modes, offline access, or maintenance windows to make the swap stick.
When a suspected exploit is found, remove the unauthorized replacement, restore the original file from trusted media, and review the host for any follow-on changes that would preserve access after reboot. If the machine handled sensitive credentials or logged-in sessions, treat it as a compromise review case, not just a file-repair task.
For operational prioritisation, the Vulnerability Management Guide and Zero-Day and Exploited Vulnerabilities Guide help frame exposure triage, verification, and post-patch hunting when a weakness is actively being abused.
Risk and Threat Considerations
Sticky Keys abuse is dangerous because it can bypass the normal login boundary and turn a local, low-friction file swap into pre-authenticated command execution. That makes it attractive for persistence, hands-on-keyboard compromise, and any attack path that depends on operating before the user desktop is protected.
Failure mechanism: An attacker replaces the expected accessibility utility or a related logon component, then triggers it from the sign-in screen to obtain elevated execution and preserve access across reboots.
Impact: The result can include SYSTEM-level command execution, credential theft opportunities, tampering with security tools, and a durable foothold on the host.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack surface, CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1546.008 — Accessibility Features | Models Sticky Keys as logon-time accessibility hijacking for execution and persistence. |
| Recommendation — Map sign-in screen utility abuse to T1546.008 and hunt for persistence or post-exploit command execution. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Sticky Keys abuse depends on insecure local configuration and writable system paths. |
| Recommendation — Harden logon utilities and system paths so accessibility binaries cannot be replaced. | ||
| NIST SP 800-53 Rev 5 | CM-5 — Access Restrictions for Change | This attack succeeds when unauthorized users can alter protected system files. |
| SI-7 — Software, Firmware, and Information Integrity | Integrity controls are needed to detect replacement of trusted logon binaries. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Post-compromise review depends on reviewing evidence of file replacement and follow-on actions. | |
| Recommendation — Enforce change restrictions on logon components and verify only approved modifications occur. Use integrity monitoring to detect replacement of accessibility executables and related system files. Review audit data for logon-time tampering and subsequent privilege abuse on the host. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | The exploit abuses insecure configuration and altered trusted system files. |
| Recommendation — Protect baseline system configurations and validate that logon utilities remain trusted. | ||
Practitioner Guidance
Why practitioners should care: This technique is a reminder that “pre-login” is not a safe zone unless the underlying binaries, permissions, and recovery paths are controlled. If a device can be altered offline or by a local admin, the logon screen can become an attack surface rather than a barrier.
What to watch for: Investigate unexpected changes to accessibility executables, logon-related binaries, or recovery-environment access, especially on systems that handle privileged sessions or store reusable secrets. A suspicious replacement should always trigger a broader host review, not a single-file fix.
Related resources from NHI Mgmt Group
- Why do privileged off-chain keys increase exploit risk in DeFi systems?
- How do you detect accessibility feature backdoors such as sticky keys on Windows?
- What is the difference between workload identity and API keys for AI agents?
- How should security teams govern API keys used for generative AI access?