Recently I forgot my password to a laptop I didn’t use much. It was bitlocker encrypted, but I had saved the keys. So I booted into a live Linux system mounted the bitlocker partition with dislocker and then dumped the Sam hashes with impacket’s secretsdump. Then I used hashcat to try and crack my own password since I thought I remembered parts of it. Ended up working!
You can do the same thing without using a boot drive at all.
* Press F11 while booting
* open cmd in the rescue menu
* navigate to windows system32 folder
* rename sethc.exe to sethc.exe.backup
* copy cmd.exe to sethc.exe
* reboot and press at login 5 times shift
* add admin user
* profit
Thing that is missing is password edit of online only accounts or convert to local account
I spent my high school years with chntpw (http://www.chntpw.com/download/) on a bootable floppy in my backpack (later, a bootable USB), for those times when a certain machine needed to be "liberated" from restrictive school policies. A particularly fond memory is of enabling a bunch of teens to play StarCraft on the machines in a computer lab after-hours...
I'd heard about teens jailbreaking Chromebooks and the like recently, so it's nice to see the spirit of rebellion is still alive and well in the new generation :)
It requires physical access to the machine, which is always 95% of the game. Plus, Bitlocker would prevent this from working, so if you're using a recent computer and have Pro/Enterprise and enable it, you don't have to worry about this attack vector.
The limitations of this tool are obvious from the author's documentation. Plus, a door lock would prevent this from working, so if you're living in a recent house and have thick door and lock the door, you don't have to worry about this attack vector. It's strongly suggested to also hot glue your USB ports shut for added security.
> It's strongly suggested to also hot glue your USB ports shut for added security.
I don't see any reason to stop at my USB ports. Take a hot glue gun with you where ever you go, and glue them all shut as soon as you find them. Help make the world a better place.
> It's strongly suggested to also hot glue your USB ports shut for added security.
I'll just unplug your mouse / keyboard / wifi dongle and get to the USB port that it's using. Unless you are suggesting that modern computers should ship with zero USB ports.
All the cards should be hot glued into place, and any extra connectors hotglued as well. The solution to not enough hotglue is simply more hotglue!
> I'll just unplug your mouse / keyboard / wifi dongle and get to the USB port that it's using. Unless you are suggesting that modern computers should ship with zero USB ports.
PS/2 is still available for mouse/keyboard (and secure). Wifi dongles are abomination. Worst case, hotglue those into the port.
Neat, but replacing Utilman.exe with cmd.exe using most Linux ISOs is easy, and I've already got the drives needed. The amount of customers that get locked out of their servers...
A trick I used that still worked after this Defender update (tested some months ago) is replacing Magnify.exe with ftp.exe. This does not make Defender suspicipus, but one can open Magnify.exe from the lock screen and one can execute commands from within the ftp.exe shell by prefixing them with !. This is great, because ftp.exe binary is signed by Microsoft and is a completely legit binary (:
How strange, shouldn't windows be checking if the binary is signed? Isn't that part of what secureboot and deviceguard do? Or does it just run like any addon?
Secure Boot only verifies the NT kernel loader; that in turn will verify that the kernel is signed by Microsoft, and then the kernel will verify any device drivers it loads. Userland (e.g. explorer.exe) is free to be run without any signatures whatsoever; this includes the login screen.
Still possible, as presented at BlueHat IL 2023, the goal is to eventually have everything signed, based on how UWP sandboxing is working, now extended to Win32 as well.
First set of changes already in flight for the next Windows 11 stable release.
its a shame they need to lean on defender for this. it wouldnt be too long of a stretch to expect windows to verify the binaries it ships with, and not accept unsigned ones for those windows / MS binaries in the windows directory :(. it does no justice to all the good that could be done via secure boot
We don't expect Linux to do this, do we? Just use full disk encryption, preferably with pre-boot authentication. TPM if you must, but this will only make the attack somewhat more expensive. Other than that, the hardware is compromised as soon as somebody gets their hands on it. Checking the integrity of a few binaries is mostly security theater.
Besides manipulating executables, the adversary could simply modify or read the user database in C:\Windows\System32\config\SAM. [1]
Alternatively, patch routines directly in memory [2]
secureboot could be leveraged for such things but as with most great features, only the bare minimum implementation is provided in 'modern secure operating systems'
Hm, it says to press Shift 5 times on the Windows login screen. By default this will enable sticky keys. Is that the intention or is that a conflicting keybind?
Unshackle is a simple tool that deletes windows password logins (Linux support coming soon) using a bootable USB Drive, and makes you enter the system without any passwords, based on Alpine Linux.
Only for the record, until it lasted (seemingly noone has been interested in finding and updating the patterns to be patched or maybe some other security measure was implemented in later Windows 10) the "best" way (IMHO) was to patch a file.
Booting from USB with grub4dos, patching the .dll then continuing booting and you could login as the original user but without (or with "any") password:
Yep, but medicat lists (among other tools) the PEPassPass (which is a derivative of PassPass), all those tools need to boot into an Operating System (a PE or a Linux), change something, then reboot to the "normal" OS.
What is (was) elegant in the grub4dos PassPass is (was) that you booted to grub4dos, ran the batch and then continue booting to the "normal" OS.
There is also "Device Encryption"[1] that is separate from BitLocker and works in any version of Windows 10/11 as long TPM is available (and AFAIK is also turned on by default). BitLocker is only available in the Pro versions.
Windows Bitlocker is the FDE product that Microsoft uses. It’s not enabled by default. It is possible to have Bitlocker disabled and password auth enabled.
At least on my corporate Windows laptop, the Bitlocker password is restricted to numeric digits only. Coupled with natural human laziness, and brute forcing looks fairly feasible.
Even if the PIN was only 4 digits you would be very unlikely to successfully bruteforce it. The TPM will throttle you after a few tries and lock you out for an increasing amount of time after each further attempt.
An attacker might get 10 good tries before continuing becomes pointless, so unless the PIN is one of 1234 4321 0000 1111 2222 you're probably safe.
Note: TPM2.0 allows alphanumerical PINs but I think you need a group policy for Windows to allow it.
On a simlliar note:
Has anyone succefully installed yubikey windows 10(home) login for local accounts?
They rereleased it for windows 10 I think(version 2+), but it never worked for me (apperently they relased a new version 2.11 recently for 11 & 10(22h2 fix), which I haven't tried)
Which is a little strange -- since you have physical access and are capable of booting from a USB stick, the procedure is to tell the bootloader to use sh as the init, mount the root filesystem r/w, change the root password (copying the hash for later if you want to restore it), make sure it's written to disk and reboot into the normal system -- only now you have root.
If you have access to the bootloader's kernel command line, you don't need the USB stick, either.
What this doesn't do is get you access to an encrypted filesystem, unless the encryption password happens to be written somewhere in the unencrypted partition. That happens unsurprisingly often.
