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

# Reset a Windows Password with the Sticky Keys Trick (sethc.exe)
- URL: https://blog.sudowl.com/windows-password-reset-sticky-keys-sethc/
- Published: 2026-05-13T10:00:00.000Z
- Updated: 2026-10-11T10:16:27.000Z
- Description: Alternative to the Utilman trick — replace sethc.exe to get SYSTEM-level cmd at the Windows lockscreen. When to use it, how to harden against it.
- Author: Lukas
- Tags: Windows Server, Security

The [Utilman trick](/reset-forgotten-windows-admin-password-utilman/) is the classic one, but if a sysadmin already disabled the accessibility-button on the lockscreen, Utilman won't fire. Sticky Keys is the backup — same idea, different binary, different keystroke trigger. Five Shift presses, SYSTEM cmd, password reset.

**TL;DR:**

```cmd
copy d:\windows\system32\cmd.exe d:\windows\system32\sethc.exe.bak
copy /y d:\windows\system32\cmd.exe d:\windows\system32\sethc.exe

```

Boot, lockscreen, hit Shift five times, you get a SYSTEM cmd, run `net user Administrator NewPass123!`, reboot, log in.

This is the same dual-use technique as Utilman — a recovery tool when you're locked out of your own machine, an attack when someone has physical access to a machine that isn't theirs. Don't use it on hardware you don't own.

## When this beats Utilman

- Some hardening guides specifically remove or replace `utilman.exe`. They almost never touch `sethc.exe`.
- Sticky Keys triggers without a click — useful if the mouse is dead at the lockscreen, or if you're working over a remote KVM that's keyboard-only.
- If `utilman.exe` is signed-and-checked by an EDR baseline, the file-modification alert fires immediately. `sethc.exe` is rarely on the baseline.

The Utilman post is the better starting point for "I forgot my admin password" because it works on every default install. This post is the fallback.

## The procedure

You need a Windows install / recovery USB. WinPE on a Ventoy stick works. Boot from it, hit Shift+F10 at the language picker to get a cmd.

Find the Windows drive (it's not always C: in the recovery environment):

```cmd
diskpart
list volume
exit

```

Look for the volume with `Windows` in the label. It's commonly `D:` in recovery, sometimes `C:` or `E:`.

Then the swap:

```cmd
copy d:\windows\system32\sethc.exe d:\windows\system32\sethc.exe.bak
copy /y d:\windows\system32\cmd.exe d:\windows\system32\sethc.exe

```

`copy /y` skips the prompt. The backup matters — restoring the original is the cleanup step, and you don't want to forget which file you replaced.

Reboot into Windows. At the lockscreen, mash Shift five times. A cmd window opens running as `NT AUTHORITY\SYSTEM`.

Reset:

```cmd
net user Administrator NewPass123!

```

Or create a new admin:

```cmd
net user backup-admin StrongPass123! /add
net localgroup Administrators backup-admin /add

```

Same `net user` patterns as in [creating Windows users from cmd](/create-windows-user-cmd-net-user/).

Log in with the new credentials.

## Cleanup — restore sethc.exe

This is the step everyone forgets. Boot the recovery USB again:

```cmd
copy /y d:\windows\system32\sethc.exe.bak d:\windows\system32\sethc.exe
del d:\windows\system32\sethc.exe.bak

```

If you skip it, every Windows host with that drive plugged in gets a SYSTEM shell on Shift-mashing. Not subtle, but easy to miss in a hand-off.

## What to do after — Windows Server hardening

If this was a recovery on a server you own, after you're back in:

1. Enable BitLocker on the OS volume. Once the disk is encrypted at rest, the recovery-USB attack stops working — there's no plaintext `sethc.exe` to swap.
2. Set a BIOS/UEFI password and disable USB boot in firmware.
3. Audit account passwords — anyone who reused the old one is at risk.
4. Check `eventvwr` for unexpected logins around the time you regained access.

Broader baseline: [Windows Server initial setup checklist](/windows-server-initial-setup-checklist/) and [enable RDP from PowerShell or cmd](/enable-rdp-windows-server-powershell-cmd/) once you're back in.

## Hardening against this technique

If you want to stop both Utilman and Sticky Keys swaps in one go:

```powershell
# Block accessibility tool execution from lockscreen via Image File Execution Options
$paths = @("utilman.exe","sethc.exe","osk.exe","narrator.exe","magnify.exe","displayswitch.exe")
foreach ($p in $paths) {
  $key = "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\$p"
  New-Item -Path $key -Force | Out-Null
  Set-ItemProperty -Path $key -Name "Debugger" -Value "C:\Windows\System32\msg.exe"
}

```

Each accessibility binary now redirects to `msg.exe`, which does effectively nothing useful at the lockscreen. The recovery-USB swap still copies `cmd.exe` over `sethc.exe`, but the IFEO key intercepts execution before the swapped binary runs — the cmd never opens.

This breaks legitimate accessibility tools too. On a server, fine. On a workstation that any user might use, weigh that.

The real fix is BitLocker. Without disk encryption, an attacker with physical access wins eventually — IFEO is a speed bump, not a wall.

## When this won't work

- BitLocker is on. The recovery-USB cmd can't see the encrypted volume contents without the recovery key. (This is the point of BitLocker.)
- Secure Boot + signed-binary policy is enforcing. Rare on consumer Windows, common on locked-down enterprise. The swapped `sethc.exe` won't load — wrong signature.
- It's a domain account, not a local account. `net user` on the host doesn't touch AD. For domain accounts, you need to be at a Domain Controller and reset there. See [joining a server to AD](/join-windows-server-ad-domain-powershell/) for context.

## The two failure modes

**Shift mash does nothing.** Check from the recovery cmd:

```cmd
dir d:\windows\system32\sethc.exe

```

The file size of `cmd.exe` is around 280 KB. Original `sethc.exe` is around 100 KB. If your `sethc.exe` is still 100 KB, the copy didn't happen — wrong drive letter, almost always.

**You're locked out again after reboot.** Auto-login was enabled with old credentials, and Windows tries them, fails, freezes. Boot back to recovery, edit `HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\AutoAdminLogon` to `0`, reboot. Or just reset the password to whatever was stored.

For the original Utilman walkthrough, see [reset a forgotten Windows admin password with Utilman](/reset-forgotten-windows-admin-password-utilman/). Same family of trick, slightly different lever.

---

### Related posts

- [RDP Hardening on Windows Server — NLA, IP Allowlist, and Audit](https://blog.diengdoh.com/rdp-hardening-windows-server-nla-firewall/?ref=blog.sudowl.com)
- [Windows Server Hardening — Kill SMBv1, LLMNR, and NTLMv1](https://blog.diengdoh.com/windows-server-disable-smbv1-llmnr-ntlmv1/?ref=blog.sudowl.com)
- [BitLocker on Windows Server — Encrypting the OS Volume Without Locking Yourself Out](https://blog.diengdoh.com/bitlocker-windows-server-os-volume/?ref=blog.sudowl.com)