How Windows Stores Local Passwords (And Why That Matters)

What You Need to Reset a Windows Password with Linux

Step-by-Step: Creating the Bootable Linux USB and Resetting the Password

Can You Reset a Windows Admin Password Without Logging In?

How to Defend Against Offline Password Reset Attacks

The Ethical Line: When This Is Legitimate and When It Isn't

What This Teaches Us About Local Security in 2026 Last month, a colleague walked into the office on a Monday morning, sat down at his workstation, and blanked. The Windows admin password he'd set three weeks ago? Gone. IT couldn't help for 48 hours. He lost an entire day of work staring at a login screen. This happens way more often than anyone admits. And here's the thing nobody talks about: you can reset a Windows admin password with a bootable Linux USB drive in about ten minutes. No reinstall. No data loss. No calling Microsoft. The technique exploits a fundamental truth about local OS security that every developer should understand. This guide walks through exactly how to reset a Windows admin password using a Linux USB, explains the mechanics of why it works at the SAM file level, and covers the defensive measures that actually stop this attack. Before touching a USB drive, you need to understand what you're actually manipulating. Windows doesn't store your password in plaintext anywhere. Instead, it stores a cryptographic hash in a file called the Security Account Manager, or SAM. According to Microsoft's own documentation, the SAM database handles authentication for both local and remote users and lives at C:\Windows\System32\config\SAM. Here's the critical detail: when Windows is running, the SAM file is locked by the operating system. You can't open it, copy it, or modify it. The OS guards it like a vault. But when Windows isn't running? That file is just sitting on an NTFS partition, wide open. Any OS that can read NTFS can access it. This is the core vulnerability. We're not "cracking" the password. We're not brute-forcing anything. We're booting a different operating system, mounting the Windows drive as a regular disk, and using a utility to blank out the password hash. When Windows boots back up, it sees an empty hash and lets you in. I've used this technique at least a dozen times over my career. Personal machines, lab workstations, even a build server that someone set up and then left the company without documenting the credentials. It works. Every time. The requirements are minimal, which is part of what makes this both powerful and frankly a little alarming from a security perspective: No special hardware. No paid software. Everything here is free and open source. Here's the practical walkthrough. I'm assuming you have a second computer available to create the USB drive. If not, any machine with internet access will do. Creating the USB drive: Download the Ubuntu Desktop ISO. Open Rufus (or your tool of choice), select your USB drive, point it at the ISO, and hit Start. This takes about five minutes depending on your USB speed. When it's done, you have a fully bootable Linux environment on a stick. Booting from the USB: Plug the USB into the locked Windows machine and restart it. You'll need to access the boot menu. Usually F12, F2, or Delete during POST, though it varies by manufacturer. If Secure Boot is enabled in your UEFI settings, you may need to disable it temporarily. Secure Boot is designed to block unauthorized operating systems from loading, and some Linux live distributions get caught by it. You can re-enable it after. Select the USB drive from the boot menu. Choose "Try Ubuntu" (not Install) when prompted. You'll land on a full Ubuntu desktop running entirely from the USB. Mounting the Windows partition and running chntpw: Open a terminal. First, identify the Windows partition. Run lsblk and look for the large NTFS partition, usually something like /dev/sda2 or /dev/nvme0n1p3. Mount it to a temporary directory. Next, install the chntpw utility. This is the tool that does the real work. A quick sudo apt update && sudo apt install chntpw pulls it down. The chntpw project has been around for years and is well-documented on the Arch Wiki. Navigate to the mounted SAM file location (typically under the Windows/System32/config directory on your mounted partition) and run chntpw against the SAM file. The utility gives you an interactive menu. Select the user account you want to reset, choose the option to blank the password, and save your changes. Reboot, pull the USB drive out, and Windows boots normally. The account you targeted will have no password. Log in and set a new one immediately. Chris Titus, a well-known tech YouTuber and system administrator, has a solid video walkthrough of this entire process if you prefer to see it done live: [YOUTUBE:4MEURdC8o8Y|Reset Your Forgotten Windows Password with Freeware] Yes. And that's exactly what makes this technique both useful and dangerous. You never log into Windows at any point during this process. The chntpw utility works entirely offline. It reads and writes to the SAM file while Windows is dormant, meaning Windows never gets a chance to enforce its own security policies. This isn't a bug. It's a fundamental limitation of local OS authentication. Bruce Schneier, one of the most respected voices in security, has repeatedly argued on his blog that physical access to a computer effectively bypasses most OS-level password protections unless the storage is encrypted. The OS can only protect itself while it's running. Boot something else, and the OS is just files on a disk. I've seen this reality surprise even experienced developers. If you're building software that stores sensitive data locally, and you're relying on Windows login as your security boundary, you're building on sand. The Windows login protects the session. It does not protect the disk. Those are different things entirely. This is also why, if you ever work in an environment handling sensitive data — healthcare systems, financial platforms, anything touching PII — the security posture can't stop at "we have strong passwords." Physical access controls and disk encryption are table stakes. Having built systems that handle sensitive user data, I can tell you firsthand that insider threats are a real and growing concern, and physical access exploits are one of the oldest vectors in the book. If a ten-minute USB trick can bypass your Windows login, what actually stops an attacker? There are three layers of defense, and you need all of them. 1. Full-disk encryption is the real lock. Microsoft's BitLocker encrypts the entire Windows partition at rest. When BitLocker is active, booting from a Linux USB shows you an encrypted blob. No SAM file. No NTFS filesystem. Nothing usable. The Cybersecurity and Infrastructure Security Agency (CISA) recommends encryption as a critical layer of data protection for exactly this reason. It's the single most effective countermeasure against offline attacks. If you haven't enabled BitLocker (or an open-source alternative like VeraCrypt), do it today. I'm serious. On Windows Pro and Enterprise, BitLocker is built in and takes about fifteen minutes to set up. On Windows Home, you'll need a third-party solution, but VeraCrypt is free and battle-tested. 2. Secure Boot adds friction. Secure Boot won't stop a determined attacker who has physical access and time — they can just disable it in the BIOS. But it stops casual exploitation. If someone can't easily boot from a USB without entering the BIOS and changing settings, that's a real barrier. Pair it with a BIOS password and you've raised the bar significantly. 3. Physical access control is the foundation. This is one of those things where the boring answer is actually the right one. Server rooms should be locked. Workstations with sensitive data shouldn't be left unattended in public spaces. Laptops should be encrypted and physically secured. In my experience, the companies that get compromised through physical access are almost always the ones that treated physical security as someone else's problem. For developers specifically, this is a reminder that security vulnerabilities come in layers. You can have the strongest application security in the world, but if someone can walk up to a server and boot from a USB, none of it matters. I want to be direct about this. Resetting a password on your own machine, or on a machine you're authorized to administer, is fine. IT departments do this constantly. Sysadmins recovering locked-out workstations is a Tuesday. Using this on a machine you don't own or aren't authorized to access is a crime in most jurisdictions. The Computer Fraud and Abuse Act in the US, and similar laws internationally, don't care that the tool is freely available. Intent and authorization are what matter. Every time I've used this technique professionally, it's been documented and authorized. That's the standard. If you're not sure whether you should be doing this, you shouldn't be doing it until you get written authorization. Full stop. The fact that a free Linux utility can blank any Windows local admin password in minutes tells you something important about local accounts. They were never designed to be your last line of defense. They're an access control mechanism, not a security boundary. With the shift toward cloud-managed identities (Microsoft Entra ID, for example), this attack surface is shrinking for enterprise users. Cloud-authenticated accounts don't store password hashes in the local SAM file in the same way. But millions of machines still run on local accounts. Home PCs, lab machines, small business workstations, developer rigs. If you take one thing from this post: enable full-disk encryption on every machine you own. It costs nothing, it takes fifteen minutes, and it's the difference between a locked front door and no door at all. The password on your Windows login screen is the lock. Encryption is the door. Templates let you quickly answer FAQs or store snippets for re-use. as well , this person and/or - A USB drive (4GB minimum). Anything you have lying around works.

- A Linux ISO. Ubuntu is the easiest choice here. Grab the latest LTS from ubuntu.com.- A tool to create a bootable USB. Rufus on Windows, balenaEtcher on macOS/Linux, or dd if you're comfortable with the command line.- Physical access to the locked machine. This is the crucial part, and we'll come back to it in the security section.