How to get into an admin account on a Windows computer | Hacker News Reader

How to get into an admin account on a Windows computer

m.imgur.com

262 pointsjoewee100 comments

Wow this takes me back to busting into Windows 98 via the Help > Print > something > Explorer method.

Actually, someone linked to something like it in the comments: https://i.imgur.com/n9Th4q5.jpg

I can't imagine how difficult it must be to secure a login system with so much added surface due to accessibility and dumb users.

It's been a little while (obviously) but, if memory serves, all you had to do on Windows 98 was click "Cancel" at the logon screen.

It's very simple really; just don't run any external programs. Better still would be to limit the permissions of each specific executable (like iOS does), but that's not how Windows was designed...

This is one reason why we use BitLocker with TPM unlock on all of our student PCs. If the system is booted in an usual way like this, the disk won't unlock. We had issues our first year with a student who booted a Linux DVD and reset the local administrator password and another instance where the student removed the hard drive to do the same (after we'd locked our BIOS settings). Encrypting the drives has 100% prevented these problems, and makes us feel better about sending failed drives to vendors without wiping them.

If you have physical access to the harddrive and can turn it on or off legitimately, then can you not just image the harddrive to a backup (While its running) then modify whatever files you want and restore the new modified backup back to the harddrive? Sounds to me like you would be off to the races then.

Bottom line is, if you let people have physical access to the machine, they can always own it.

> an you not just image the harddrive to a backup (While its running)

The disk contents are fully encrypted, and Windows will only boot when the system is in an untampered state (via TPM unlock). A student would have to compromise Windows in a way that escalates their privileges. From there they could turn BitLocker off if they liked. This is far from impossible, but we also use AppLocker to prevent students from running any software that has not be explicitly approved--so they would have to compromise some software which is already installed. I won't delude myself and say it's impossible to compromise all of this, but for my goal of keeping 13-18 year-olds from resetting the local admin password it is quite sufficient.

TPM is a chip on the motherboard that stores the keys for the encrypted hard-drive. You can't move the hard disk to another machine or use a backup to go elsewhere because it won't have the correct key on the TPM to decrypt the hard drive.

If you have physical access, just reset the bios and reinstall windows on the box from scratch. If the bios cannot be reset ( is such a thing possible ) then remove, clip, or melt the tpm chip in order to force the system to forget it's tpm info?

It's not that the TPM chip is "enforcing" the encryption, it actually contains the "password" to it. So if you remove, clip, or melt the TPM chip the hard drives' data is forever lost, as that key is now destroyed.

The discussion was whether students could force the machine ( a laptop they could take home with them ) into a state where they could use it to cheat during tests.

TPM chips generally provide the following: 1. An encrypted store that can only be accessed by an authorized portion of code ( such as booting an encrypted drive ). Checks are done to ensure the code being run is signed. 2. Secure RNG ( random number generation ) 3. Various other public/private key stuff

Typically you can enable/disable TPM from the BIOS. ( whether it is a physically removeable TPM chip or not )

Obviously removing/destroying the TPM chip will cause a loss of data, but that is irrelevant if you don't care about that data and are willing to reinstall the OS.

It isn't hard to install a clean OS on a wiped drive. Even supposing somehow you couldn't reset the BIOS to shut off the TPM and force a normal clean drive boot process, I was speculating if removing/destroying the TPM would revert to booting normally.

Note there was a lot of anger when TPMs were initially introduced, because they could effectively be used to force a system to only ever boot a signed OS. ( removing the ability to run Linux ) This is my curiosity; if on normal systems this can be forced or not.

>If you have physical access to the harddrive and can turn it on or off legitimately, then can you not just image the harddrive to a backup (While its running)

How would one complete an image level backup of an encrypted hard drive without admin rights?

If your students can physically remove the hard drive, you should consider physical security rather than software security.

What exactly are you suggesting? Those dumb case keys everyone now has? Or security screws? CCTV likely won't help as you cannot realistically get 100% coverage of every lab on site. So while it might stop someone walking out with a tower (or ID them), it wouldn't stop anyone doing this...

Honestly software security is the optimal solution. It solves a whole host of threat models (alternative boot media, repair tool, HDD removal, stolen machines, HDD warranty data leaks, lost laptops, etc). All physical security does with that in place is stop someone stealing your internal components, but it is expensive to do well and relatively easy to defeat with just a screwdriver or paperclip (and "unlimited" time).

These are laptops that the students take home with them. The lab computers are physically secured.

If the student knows enough to boot Linux and remove admin passwords why don't you just let them have admin access?

Because they use it to circumvent restrictions on our network and devices. Our early years we had some students do this. They used proxy software, installed games, cheated on tests, etc. It was a giant mess and made staff question the effectiveness of our laptop program. I don't doubt that some students would use admin access responsibly, it's the other 90% of kids that won't that are the problem.

If you have physical access to the PC, why not just boot up Ubuntu, and replace the files that need replacing? No need to rely on a feature in Windows that can be disabled.

If full-disk encryption isn't used, there's really not much the underlying OS can do to prevent this.

Lots of work/school computer has a password locked BIOS which prevents you from booting from anything else. If they also have a physical lock on the computer, or if it's a laptop that you can't open or doesn't have a bios reset functionality, or you're worried about getting caught opening the computer, you're effectively locked out.

This exploit does actually open possibilities where there were few/none before. Also I imagine it's easier for some people to execute.

This password locking is worthless - most (if not all) BIOSes have backdoor password that allows anyone to bypass password lock.

Here's one of the pages that lists some of them: http://www.uktsupport.co.uk/reference/biosp.htm

Some devices make this very difficult. Well, not very difficult - just more time consuming. I was trying to unlock a BIOS password on a Toshiba Satellite maybe 3 years ago, none of the default or "backdoor" passwords would work. However, you were able to reset it by using a jumper to complete a specific part of the circuit.. Not for the faint hearted, however if a thief steals the laptop, they'll have no problem opening it up in their own time.

I'm glad they've made this harder, as most thieves are deterred by the technical aspects of breaking in to wipe a computer.

Don't even get me started on the passwords to unlock HDD's, the ones you set on the BIOS... One day I will write how I unlocked the Toshiba(TSSTCorp) HDD I had forgotten the password for on my laptop. I had to buy a new HDD, because I didn't have a spare one at the time, but I did it in less than 5 minutes, unscrewing and screwing the laptop covers and HDD's included. They weren't even the same brand. I bought a Samsung to unlock the Hitachi.

Also you could probably reset the bios in a couple minutes.

I refuse to use lab computers on this basis. I assume they're owned and have keyloggers. I'd sooner use someone else's toothbrush.

I don't understand why more labs don't use dumb terminals to hook back into a VM that gets blown out the airlock after each and every use.

It's not very hard to build a keylogger using basic pic chips and install them into a keyboard. The same could be done against a dumb terminal. For bonus points, put a bluetooth module / picoduino inside so that you can read out people's keystrokes without touching it again.

Cost and complexity of administration most likely.

Also time, our university did something like this on their library computers. It meant waiting 5min after someone logged out for it to do a system restore before the next person could log in. Which seemed like forever when you're rushing to print a paper.

Physical-access always means "game over" unless full-disk encryption is used.

In this case FDE won't help, right? As the OS already can read the hard drive during the repair phase (or otherwise can't get that far).

It looks like you can only launch the repair once you have decrypted the hard drive [1].

[1] http://answers.microsoft.com/en-us/windows/forum/windows_7-s...

You can do a entire dump of the HD while its turned on and save it to a backup. Then you can restore the backup back to the initial HD

Could you link some kind of a guide about what should be changed from a Live CD/USB?

According to step 7 and 8, you only need to create a copy of the cmd binary and name it sethc.

Here's a 'guide' from 2012 http://carnal0wnage.attackresearch.com/2012/04/privilege-esc...

And here's a 'fix' from microsoft: https://social.technet.microsoft.com/Forums/windows/en-US/a3...

It doesn't need fixing, it is working as intended.

If you can alter one system file then you can alter all system files. So even if this got "fixed," then another program would be replaced, a service, or the login screen itself.

The only actual fix is to protect the Windows installation itself, this can be accomplished through full disk encryption (e.g. Bitlocker) in combination with uEFI secure boot.

To be honest I roll my eyes when people post "exploits" like this. It just shows that people have no core understanding of computer security from the ground on up.

As an aside this exact exploit would work perfectly on a Linux (e.g. Ubunutu) system that didn't implement full disk encryption.

The clever part is getting the startup repair command prompt with no additional tools. Its similar to the old windows login bypasses (https://i.imgur.com/fqjnKh.jpg) in that it gives on more tool to use for pentesting.

http://pogostick.net/~pnh/ntpasswd/

This trick is widely used by hackers to maintain persistent access to large enterprise networks. You can RDP around and press Shift 5 times to pop up the cmd.exe on machines you've modified. No malware needed.

Performing this modification DOES NOT require rebooting the computer into startup repair if you have admin access (which is typical after you get hacked). There is a process that watches system32 for modifications and resets them, but if you script it and change the files fast enough it won't notice.

The utility of this trick is really insane. Would you realize that a hacker had backdoor access to your computer via RDP if the only thing that was modified was cmd.exe and sethc.exe swapping places?

Surely the thing you'd notice so you could lock them out is admin passwords being changed? Not that this fixes the root of the problem, it would just make you aware that you had a problem.

Or you can boot from kon-boot.

That makes any password work for login, but only once, and it's undetectable after a reboot.

http://piotrbania.com/all/kon-boot/index2.html is the free version, which can be installed with http://www.pendrivelinux.com/yumi-multiboot-usb-creator/. That only works on 32-bit systems and up to Windows 7.

If you want the paid version, you can either buy it from http://www.piotrbania.com/all/kon-boot/, or get it from http://kickass.so/kon-boot-v2-4-remedy-for-lost-password-mum... or your usual source.

Publicly advertizing warez is probably a bad idea.

I'm pretty sure everyone interested on here is able to find the "usual sources".

Publicising warez of a cracking tool will bring him problems?

What constitues as "cracking tool" in your opinion?

Ahould the tools locksmith's use also be considered illegal and therefore you can steal them?

Of course not. There are many valid usecases for tools like this. Especially for people working as sysadmins.

I found out about this method last week and it's my new favorite after having to fix up a couple of weird situations caused by someone joining their laptop to the school domain, and someone locking themself out of their only admin account.

I was quite surprised to find that the command shell ran with admin privs from before the login process, since I was unable to elevate in any other way (including by trying system restore back before joining, or trying to get into safe mode).

Make sure to set it back when you're done! If you don't, then an unauthenticated RDP session can use this trick to login to the machine you fixed.

As Raymond Chen would say: "it rather involves being on the other side of this airtight hatchway".

This is the de facto standard for local lost-admin-password resets since Windows NT was released, although back in the day the trick was to change the login screen saver to the command interpreter. The imgur album is a nice touch, I guess, but if you do a web search for "windows lost admin password" (or similar), you'll get some variation on these instructions.

I had to do this once to change the password of a machine's account (the machine's previous user had left the company). Of course, I used an Ubuntu live DVD to do the file renaming. It's the cleanest method, since it allows you to use Window's own routines to change the password, instead of an external program which might miss updating something.

But the interesting part of this post is the trick to do the file renaming without having to boot from any external media. This bypasses any security preventing the use of external media. Even if a user has access only to the keyboard, mouse, and power button (or can cut the power by pulling the cable), he can use this trick to do the file renaming and gain local admin access.

It isn't exactly novel. Using the Windows Recovery Environment (however you get there) is exactly how this has been accomplished since the introduction of WinRE in Vista.

Physical access and all bets are off. This is not a vulnerability.

No, but it is interesting to know methods like this.

You can achieve admin on an OS X machine by adding a new one like so:

1. Enter single user mode via cmd + s during startup.

2. Mount the hard drive via /sbin/mount/ -uw /

3. Delete the setupdone check via rm /var/db/.applesetupdone

4. Reboot, and now you are presented with the wizard for adding a new admin account.

I remember someone (not me, oh no...) used one for NT4 with inadequate policies to get Admin access.

Create a batch file with the content:

net localgroup administrators NewUser /add

...then stick this into the 'StartUp' directory for All Users. Break something. Call support. They log in as Administrator, running your batch file in the process.

NewUser would be created with Admin rights. You wouldn't promote your own login, of course.

Of course this is only possible if FileVault is disabled, otherwise you would not be able to mount the hard drive without user's password.

BIOS password lock, and physical lock on computer and/or an environment where it is hard to open the computer without being detected (work/school) makes other options hard.

This exploit you could even pull off on a school lab computer while the teacher is in the room. If he comes over while you're working, inconspicuously power off the machine.

What? It absolutely is a vulnerability, insofar that it allows unintended access to a computer system.

That's like saying, "Car door was open, therefore not theft."

In which case, why bother with user passwords at all?

To ward off the dummy 99%.

You can't stop a guy who knows what he's doing, but you can stop Josie from the next desk snooping around in HR's file. Also, it causes a breach, which depending on where you live might be needed to show intent.

You do not want that binary that you have downloaded to be able to do a privilege escalation without your consent.

Also, some people may feel like changing your wallpaper to something inappropriate, but they may not be motivated enough to hack your pc.

Same reason we put locks on our doors. If someone is really serious, he or she can (destructively) break in. But a locked door will prevent someone from casually getting in.

I can't remember it correctly but there is a saying along these lines:

most people would open your door if there was no lock on it. Eventhough it's useless.

encrypting helps no? maybe not all bets are off in that case.

Try doing that with my phone. I think (hope?) you wouldn't succeed.

You can do this with a phone or tablet (Android). That's essentially how many root exploits are accomplished, boot into the default recovery (typically hold volume up during power on), run a script, and recovery replaces key files which are used later to provide you with root.

This is less common NOW, but back in the Android 2.xx days it was the defacto way of getting root.

This is a vulnerability. This attack does not require physical access. Do you really think that startup repair mode is required to swap the position of cmd.exe and sethc.exe?

No, it's not, because sethc.exe resides in %systemroot%\system32 - an area that is protected by ACLs, only allowing regular users read access. Going into startup repair mode grants system-level access to files there. Without repair mode, users cannot swap these files.

The Repair Tool requires unrestricted physical access, it is running as administrator. The same way that a Live CD could.

> Do you really think that startup repair mode is required to swap the position of cmd.exe and sethc.exe?

A Live CD/DVD would work just as well. As would a USB-based OS. You could also (although it would require more work) use network boot to run your own code.

There's no vulnerability, this is unfixable, you just have to secure the system using full disk encryption and secure boot.

I did exactly this over the holidays to get into a deceased family member's computer.

If booting from a CD or USB is allowed, you can just change the password using the Pogostick [1] live cd - or any linux live cd.

[1] http://pogostick.net/~pnh/ntpasswd/

And then you can't set it back (since you don't know what it is), so the owner of the machine would immediately know you were there. They wouldn't be able to log in.

Actually you can, by exporting/importing the right registry keys. Or at least you could on XP.

ntpasswd isn't a pentesting tool; it's a recovery tool.

If they use BitLocker, you can't get to the startup repair without the recovery key...

Startup repair is not necessary to use the sethc trick.

I think it's now two decades since I first found how to overwrite BIOS passwords from MS-DOS QBasic in order to break into school computers. Somehow reassuring that kids are still doing the same thing.

The comments about bitlocker and TPM are a good reminder that he who controls the boot sequence controls the computer / phone / car / IoT toaster.

You can of course also make quite convincing BIOS password prompts with QBasic.

that's how I got in trouble for hacking in high school; used our pascal IDE (in DOS) to make a perfect replica of our fancy ASCII login. It would capture your username and password, and then spit you back out to the real prompt. I only got caught because I kept all my stolen logins in my home dir, in passwords.txt.

I talked the teacher into canceling all of my detentions in return for showing him how to secure his bootdisks. Man, kids today would just get expelled or go to jail. I'm glad I grew up when I did.

I graduated from HS 9 years ago and I almost got suspended from all computer access, ended up getting some detentions, and various other punishments just for using Firefox. (Would have hated to see what the naive principal would have dished out if I wasn't one of the top students in my class)

That's the truth. I went to s particularly safe middle school, so when we had a random weapons sweep with metal detectors, only 3 students got caught. I was one of them; I had my little 1" swiss army knife, one girl had a steel nail file with a sharp point, and a mexican kid had a 3" folding buck knife.

Me and the girl were white honor students, and we were let off with a stern warning, and our "weapons" were handed to our parents. The mexican kid with poor english skills got sent to an alternative school (the kind for disciplinary risk kids).

user comment on imgur: "As a network manager, disable startup repair via group policy. Fixed."

Does this fix it?

Yes because the recovery menu won't be accessible than (which is needed to replace the sticky key executable)

The settings can be changed with bcdedit:

    bcdedit /set {default} recoveryenabled No 

    bcdedit /set {default} bootstatuspolicy ignoreallfailures

Additionally booting from USB/... should be disabled in the BIOS/UEFI options and also access to that should be password secured.

Further more because the person has physical access, the computer should be locked away so that the harddrive can't be accessed. Also all cables should be secured so that no sniffer can be plugged in between. This also especially includes the USB ports on the monitor if those are enabled.

Note: Make sure to run bcdedit commands with elevated privileges. I am currently working on adding this into my ansible test AD replacement.

Just this one method, yeah. But unless you encrypt your harddrive you're not going to really get security when someone has physical access to your device.

There are other things you can do though. FDE, encrypted bootloader, BIOS passwords (on boot if important enough), removal of DVD Drive/USB ports as an option. Security isn't binary, it's about layers and compromises based on use case.

NOT TESTED: I imagine that as long as you don't have a startup disk, it would. If you have a startup disk, you could likely kick off the repair from the disk.

To paraphrase another comment from imgur: If the hacker has physical access to the machine, it's now their machine.

No, if I exploit your computer and have admin rights, I can use this technique to enable persistent access to it over RDP. This is a common technique that hackers use in enterprise networks.

Meh. If someone has admin on a machine then they can re-establish access in a number of ways (e.g. their own VNC service, their own Powershell instance bound to a port, malware, etc).

Binding sticky keys to CMD is one of the worst ways as it can be detected easily (either via people trying to use Magnifier and getting CMD, hitting shift 5x times, etc), it can be fixed by Windows updates even by accident (and will be fixed via SFC), and could allow other competing "hackers" to access the machine.

I've never seen anyone use this trick in reality and I've certainly never read about "hackers" using it. They typically like to use a tiny single-file VNC server with a hardcoded user/password.

If the trick is to modify the contents of the file system, then surely booting from a Linux stick or likewise could suffice too.

Why is this on here and not flagged?

Similarly, on any UNIX OS, you can boot into single-user mode and obtain root access.

These are ancient techniques.

The obligatory response every. single. time this is brought up: Local access? All bets are off. (With certain caveats, of course).

Is there a good software (preferably open) to remotely kill/erase your data on a Windows machine. Not all versions have bitlocker. Truecrypt's future is unpredictable.

Any "secure eraser" - those programs that rewrite the contents of a file before deletion - does the job. Despite what is claimed (even by those programs and their developers), just 1 pass zeroing out the data is enough to securely delete information from a HDD.

Usually they reference a government document that says that physical destruction of the media is the only correct method to erase TOP SECRET (and above) data, but that is mostly paranoid burocracy.

If you're using a SDD however, you have to deal with firmware wear-leveling, garbage collection and the drive having a lot of GBs hidden from everyone, even the OS. There are some proposed techniques to force an unavailable block back into the available pool and then reading long-deleted data. Afaik, there's little you can do in this scenario, even full disk encryption might not help you with the old data blocks that are still waiting to be zeroed by the GC.

Then again, like you said, FDE is probably the easiest way. TrueCrypt was vulnerable to some on-memory-key attacks, but for data killing its more than enough. There are some projects that have forked TCs code, and there also the old version available thats still fully functional.

It's worth mentioning that there are ATA commands for secure erase these days.

https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase

If you have a linux box handy, you can probe your ATA-compatible drives with:

    root# hdparm -I /dev/X

look for:

    Security: 
        Master password revision code = 65534
                supported
                enabled
        not     locked
        not     frozen
        not     expired: security count
                supported: enhanced erase
        Security level high
        2min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT.

"Enhanced Security Erase Unit" should get all of the sectors that have been previously used even on a SSD with wear leveling.

Of course, you still have to trust that the vendor has correctly implemented it. I have no idea what best practices are in that regard. If anybody here has a better idea, I'd love to hear (Is FIPS certification a good sign? If the drive implements encryption and can therefore do a secure erase by dropping the keys can it be trusted? Can drive vendors generally trusted to not use ECB mode? etc.)

Windows post-Vista will write zeroes to the entire partition if you format without the quick option. [1]

[1] https://support.microsoft.com/kb/941961

I refer to it as the sticky-keys hack. Been using it since before I left High School. (admittedly only 5 years ago)

Anyone who hates annoyance will already have disabled the stickykeys shortcut.

A more reliable way if you're somewhat prepared is to just use a live linux system and NTPasswd. Any distro that can be installed to a flash drive should have it available.

The question is, however, if disabling it for your own account also disables it on the Login screen...

Yes, it's a system-wide permission (needs admin rights) IIRC.

They did turn it off by default in the Win10 previews (or at least it was for my release)

Remembers me of the ol' winnuke days (windows 95)

this is nothing new.

why go through all the trouble? just take the disk out and mount it elsewhere.

that's why one has to encrypt drives.

Wouldn't this give you access to EFS files?

Wow, it took 5 days for this to get reposted on HN? It's kinda cool watching the web go round.

(https://imgur.com/gallery/H8obU/comment/356517825)

Had to do something similar at work a couple months ago when a Windows computer somehow ended up without a single account with administrator privileges but I replaced magnifier.exe with cmd (for some reason I even switched them around) and then opened the supercharged "magnifier" on the login screen. I also didn't use "Startup repair" but a Ubuntu Live CD.

I then got called away from the computer before I could switch magnifier and cmd back to normal and somebody started using the computer again, with hilarious consequences

(Note: I'm not the IT guy in this company xD)

Reply on news.ycombinator.com