Sticky Keys Binary Hijacking: A Deep Technical Walkthrough

CyberDefender 7 mins0

Sticky Keys binary hijacking is a classic Windows privilege escalation and persistence technique that abuses accessibility features available at the login screen. While widely known in red-team circles, it remains relevant because it exploits design decisions, not software vulnerabilities. This article breaks down how the attack works internally, why it succeeds, its forensic footprint, and modern mitigations—from a defender’s perspective as much as an attacker’s.

Background: Accessibility Before Authentication

On Microsoft Windows, certain accessibility binaries are allowed to execute before user authentication. These programs are intended to assist users who may not be able to log in normally.

Examples include:

  • sethc.exe – Sticky Keys
  • utilman.exe – Utility Manager
  • osk.exe – On-Screen Keyboard
  • magnify.exe – Magnifier

These binaries:

  • Run as NT AUTHORITY\SYSTEM
  • Are callable from the Winlogon desktop
  • Do not require user credentials

This trust boundary is what makes binary hijacking possible.

What Is Sticky Keys Binary Hijacking?

Sticky Keys hijacking involves replacing or redirecting sethc.exe with another executable—commonly cmd.exe or powershell.exe. When triggered at the login screen (by pressing Shift five times), the substituted binary runs as SYSTEM, yielding full control over the machine.

This is not an exploit in the traditional sense—no memory corruption or vulnerability is involved. Instead, it’s an abuse of intended functionality.

Attack Preconditions

For the attack to succeed, the attacker must already have:

  1. Administrative or SYSTEM-level access
  2. Write permissions to: C:\Windows\System32\
  3. Ability to reboot or lock the system

This makes Sticky Keys hijacking a post-compromise privilege persistence or escalation vector, not an initial access method.

Attack Flow (Step-by-Step)

1. Backup the Original Binary

Attackers usually preserve the original file to avoid detection or allow restoration:

copy C:\Windows\System32\sethc.exe C:\Windows\System32\sethc.exe.bak

2. Replace sethc.exe

The binary is overwritten with a SYSTEM-capable shell:

copy C:\Windows\System32\cmd.exe C:\Windows\System32\sethc.exe

3. Trigger at Login Screen

  • Lock or reboot the system
  • Press Shift five times
  • A SYSTEM command prompt appears on the Winlogon desktop

4. Full System Control

From this shell, the attacker can:

  • Reset passwords
  • Add users to the Administrators group
  • Disable security tooling
  • Dump credentials
  • Establish persistence

Why This Works (Under the Hood)

Winlogon Trust Model

The Windows authentication process relies on Winlogon.exe, which:

  • Launches accessibility binaries outside the user session
  • Assigns them SYSTEM privileges
  • Assumes the binaries are trusted and unmodified

There is:

  • No integrity check at execution time
  • No user confirmation
  • No UAC prompt

The trust is placed entirely on filesystem integrity.

Variants and Evolutions

Registry-Based Hijacking

Instead of replacing binaries, attackers may modify:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options

By adding a Debugger value, execution can be redirected without touching the original file—making detection harder.

Alternate Targets

  • utilman.exe (Win + U)
  • osk.exe
  • magnify.exe

These binaries serve the same purpose and may be less monitored.

Detection and Forensics

File Integrity Indicators

  • Modified timestamps on: C:\Windows\System32\sethc.exe
  • Hash mismatch against known-good baselines
  • Missing or altered digital signatures

Event Logs

  • Security.evtx:
    • Event ID 4688 (process creation)
    • Unexpected SYSTEM shells spawned from winlogon.exe

EDR Signals

  • SYSTEM shells launched pre-authentication
  • Accessibility tools spawning non-standard child processes

Mitigation Strategies

1. Enforce File Integrity Monitoring

  • Monitor System32 for changes
  • Alert on accessibility binary modifications

2. Disable Accessibility at Login (High-Security Environments)

Via Group Policy:

Computer Configuration →
 Administrative Templates →
 System →
 Logon

3. Credential Guard & Secure Boot

  • Secure Boot prevents offline binary replacement
  • Credential Guard reduces post-exploitation impact

4. Restrict Offline Access

  • Full-disk encryption (BitLocker)
  • BIOS/UEFI passwords
  • Disable booting from external media

Why This Still Matters in 2025

Sticky Keys hijacking continues to appear in:

  • Red-team tradecraft
  • Incident response cases
  • Ransomware operator playbooks
  • Insider threat scenarios

Its persistence lies in its simplicity and reliability. As long as accessibility features run with SYSTEM privileges and filesystem integrity is compromised, this technique remains viable.

Closing Thoughts

Sticky Keys binary hijacking is a reminder that security is often broken at the seams between usability and trust. No vulnerability, no exploit—just a design assumption leveraged to its logical extreme.

CyberDefender