Click here to monitor SSC
  • Av rating:
  • Total votes: 29
  • Total comments: 18
Wesley David

Game-over! Gaining Physical access to a computer

15 March 2011

Security requires defense in depth. The cleverest intrusion detection system, combined with the best antivirus, won’t help you if a malicious person can gain physical access to your PC or server. A routine job, helping  to remove a malware infection, brings it home to Wesley just how easy it is to get a command prompt with SYSTEM access on any PC, and inspires him to give a warning about the consequences.

Because we are so aware of the sophistication of some of the 'Data-raids' and identity-thefts by cyber-criminals and malign hackers over the internet, we can sometimes forget that anyone who is able to gain physical access to a Windows machine can then access just about anything on the machine that the administrator can get to, unless it is encrypted. Even the term ‘Physical access’ is getting to be rather a blurred concept, since something like physical access can be gained from thousands of miles away with such wonders as KVMoIP (most servers have DRAC or ILO or something similar) and even the advent of the more advanced Intel vPro/AMT chipsets give standard desktop and laptop PCs lights-out management.

There is a difference between knowing how insecure a password system is, and experiencing it. I was recently given a family member’s laptop to scrape clean of a rather nasty malware infection. After making a complete image of the hard drive for safekeeping, I booted into Windows and then stared at the login screen when I realized that I didn’t know their password. Could I call them? Were they busy? I hate asking for people’s passwords anyway.

My first thought was to look for one of my boot disks which have a few tools which allege to be able to overwrite / reset the NTLM hashes. In my experience, results with those are a bit ‘hit and miss’. I could possibly brute force the hashes with Cain and Abel. I doubt this person’s password would make Bruce Schneier very proud: Meh... that just seemed too complicated. Then, in the darker recesses of my memory came the remembrance of an old stand-by method for getting into a password protected Windows machine. I tried it and it worked beautifully. It was also ridiculously simple. I’d like to share it with you since it has been public, published, knowledge for a long time, but before I do let me make note of a few important points.

First, you need physical access to the PC. This is not some super-secret “haxor” method to recover passwords across a network. You need to be able to touch the PC and also have some kind of boot disc that allows you to have access to the PC’s file system. For the record, it’s game over for any PC that you have physical access to, so don’t feel too proud about successfully pulling this method off.

Second, this will not recover a password. This resets the password. You will not be able to find what the unknown password is; you will only be able to overwrite the existing password with the password of your choice. This is very important because resetting the password will render all EFS encrypted files and folders unrecoverable unless you reset the password back to what is was prior. You have been warned.

Third, this method is specifically to reset a local Windows account and not a domain account.

Fourth, this is not new, I did not discover this, this is not original research and you can find plenty of other tutorials on the internet about exactly this method. I decided to add my own contribution to the subject for two reasons. First to help other technologists out by adding more quality content to Google (these instructions can be found on some rather dicey websites). Second, to directly impact many of my colleagues who expressed that they had never heard of any such "accessibility tools exploit". This method is already well-known to all the villains.

Lastly, please use this information for good and not evil. Of course, if you perform a corporate or governmental caper with this knowledge, I am unlikely be obliged to respond to any court summonses that your defense team sends to me.

The Overview

Have you ever looked in the lower right corner of the Windows login screen and seen a little button that looks like this:

Pressing that icon allows you to launch various accessibility tools. The vulnerability that exists centers on Windows’ behavior of launching the accessibility tools as the SYSTEM user. For example, if you launch the On Screen Keyboard, osk.exe is launched as the SYSTEM user and thus has total administrative authority. The magnifier is the same way:

Further compounding the problem over how Windows launches administrative tools is that it is purely based on the filename and not some form of the file’s hash value. The login screen merely searches the System32 folder for a file called "magnify.exe" (or whatever other accessibility tool you choose) and launches it. The trick is to replace magnify.exe with a more useful tool for our password resetting purposes. A tool like... oh... cmd.exe.

Let's begin.

The “Hack”

Step 1:

Acquire offline access to the filesystem of the PC that needs a password reset. This can mean booting from a live CD of some kind or physically extracting the hard drive of the PC in question and slaving it to another PC. You can use virtually any Windows installation disc to perform this operation on virtually any other version of Windows. You could also use a simple Linux live CD or an old-school bootable floppy.

Assuming that you now have offline access to the filesystem, we can progress forward.

Step 2:

Navigate to the %systemdrive%\WINDOWS\System32 folder and rename one of the accessibility tools to get it out of the way. I typically rename magnify.exe to something like magnify.exe.bak.

Next, make a copy of cmd.exe and name it magnifiy.exe. The command sequence would be something like this if you’re using a Windows command prompt:

Ren c:\windows\system32\magnify.exe c:\windows\system32\magnify.exe.bak

Copy c:\windows\system32\cmd.exe c:\windows\system32\magnify.exe

Step 3:

Boot the PC up and wait for the login screen to appear.

Step 4:

At the login screen, click the accessibility icon and choose the accessibility tool that you renamed and replaced with cmd.exe. In my case, it’s the magnifier.

A command prompt will pop up running as the SYSTEM user so you pretty much own the OS from stem to stern at this point.

Step 5:

Now you can change the password with NET USER [username] *

Step 6:

Log in with the newly chosen password!

That’s all there is to it. If done swiftly with the right boot medium (a minimalist Linux shell, for example), it shouldn’t take more than three minutes to change any password on a Windows PC. But remember, as Uncle Stan Lee said “With great power, there must also come – great responsibility!” Use your knowledge for good.

The Evil Within

I did this for the best of reasons, and pretty well all IT people will be in the same boat. However, if someone who doesn’t have your best interests at heart uses the same technique, what then?

Sure, you can now reset the password for an administrator account. Of course, the better option for nefarious purposes would be to create a new account so as not to arouse suspicion when someone inevitably notices that a known local account has had a password change. However, what if someone is bent on doing long term damage? What could be done from here to gain a deep foothold in that server and by consequence the network that it is on?

The most obvious option would be for someone to install a rootkit on the server. Antivirus currently installed? Oh please. Remember, there is no account more powerful than SYSTEM, so any files that a rootkit would need to touch will bow in obeisance to the wishes of your command prompt. (This is also ignoring the fact that if you have physical access, you could conceivably boot up from media intended to infect the offline file system, making the need to use a SYSTEM command prompt extraneous).

Any rootkit worth its weight in stolen credit card numbers will sufficiently cover its tracks and obscure the true malignant processes running underneath everything. From there, any amount of destruction can be wrought.

A complication of Installing a rootkit is that you would have to  acquire a rootkit, and that acquisition might not be so easy for certain classes of would-be attackers. For those attackers that don’t have deep roots in the malware underground, plenty of other tools abound! For example, just about every Windows admin knows about the Sysinternals Suite, written by Mark Russinovich. One of the tools that could be used would be PsExec. This handy scrap of code allows for the execution of a program on a remote PC. Knowing the credentials of an administrative user account on the attacked server, the remote attacker could easily launch a basic Windows command prompt running on the remote machine. As an aside, setting up an SSH server on a Windows machine is easy to do as well.

Another option would be redirect all network traffic to a remote PC. Certainly there’s quite a stream of valuable 1s and 0s traversing your network cards, be they LAN networks or SANs. Imagine a constanly flowing mirror of your data being collected and reassembled in real time on a remote machine. Or don’t imagine it; you might not sleep tonight.

Perhaps an attacker doesn’t have any outside tools to install. Not to worry, for Windows has quite a number of inbuilt opportunities for mischief. An attacker could simply enable WinRM and have PowerShell at his remote beck and call. If it’s an older operating system that doesn’t support WinRM, that’s almost better! An attacker could install a Windows component using the add/remove programs control panel that has a known vulnerability. From there, he could quietly slip away and remotely use an exploit database (Metasploit, for example) to deliver a poisoned payload and insert any arbitrary code that he wishes. Installing a Windows server 2000 or 2003 version of the FTP service could result in a full VNC server being installed due to a buffer overflow attack allowing for arbitrary code execution.

This is all assuming that the attacker wants continued access to the server. Perhaps they just want some simple data. How about some juicy SQL Server databases? Certainly an attacker who had physical access could merely keep the server booted into a live CD long enough to copy the databases of. But perhaps the databases are rather large, like many are, and the server being down that long would arouse enough suspicion to cause a server-room inspection. By executing this accessibility tools exploit, the server should only be down for a few minutes.

Now with either a command prompt or some form of remote tool installed, it’s trivial to start a virtually unnoticed copy procedure. With admin rights, one might be able to gain privileges to the SQL Server depending on the authentication method in place. Then a backup or replication procedure could be started so that data is copied while the server can still process transactions. If you can’t get to SQL Server’s own backup commands, then you could check for any third party backup tools and attempt to swashbuckle that system into handing you a copy of the data. Lastly, if you can’t get a backup or replication going, then you’ll have to take your chances with bringing the service down and copying the MDF and LDF files right out of the SQL Server directory.

Encryption of sensitive files is an essential defense that would mitigate some possible attack vectors. You can even encrypt all of your live database files with a product like, oh... say SQL Storage Compress. But I digress...

What else can one say? Evil is as evil does, and evil loves some physical access to your servers. In the end, protect your servers physically, and that includes KVMoIP access, as if you were guarding crates of nitro glycerin balanced on a Jenga tower made of golf balls (don’t ask me how that works).

A video by Wesley describing this technique is available here: Screencast: How to Reset a Windows Password Through a Backdoor

Wesley David

Author profile:

Wesley David is an IT consultant that deals with systems many and varied. Windows or Linux, servers or clients, front-facing or back-end, it matters not. If it plugs into a socket, he will likely be responsible for it. He blogs about systems administration and other technology topics at his personal blog The Nubby Admin

Search for other articles by Wesley David

Rate this article:   Avg rating: from a total of 29 votes.


Poor

OK

Good

Great

Must read
Have Your Say
Do you have an opinion on this article? Then add your comment below:
You must be logged in to post to this forum

Click here to log in.


Subject: Great article
Posted by: timothyawiseman@gmail.com (view profile)
Posted on: Tuesday, March 15, 2011 at 5:53 PM
Message: Fantastic article, thank you for providing it.

One other point that all too often gets overlooked is that with physical access to the PC for just a little longer, it is generally easy to just walk away with the harddrive.

While this does not present the ability to get deeply into the system in the ways you discuss for long term control (and it is almost certain to be detected, unlike a good rootkit....), it certainly hands over all the data that is currently on there but not thoroughly encrypted.

Subject: Excellent Point
Posted by: WesleyDavid (view profile)
Posted on: Tuesday, March 15, 2011 at 10:09 PM
Message: Yes, excellent point! Some servers are easier to physically tamper with than others and a person could easily shuffle away a few drives like a greedy squirrel at a picnic.

Subject: http://linuxbasiccommand.blogspot.com
Posted by: linuxbasiccommand (not signed in)
Posted on: Tuesday, March 15, 2011 at 10:42 PM
Message: Thanks! I looking it

Subject: Keystroke logging
Posted by: Phil Factor (view profile)
Posted on: Wednesday, March 16, 2011 at 2:14 AM
Message: If you are still using uid/ passwords for security, then just read the keystroke logging entry on wikipedia. You can get loggers that send you a daily report of what was typed via email! A software version would be easily installed if you had admin. You can get loggers that can be embedded in any keyboard, and they can be inserted in laptops very quickly.

Subject: It worked. Need one additional step
Posted by: Sitaram(http://techibee.com) (not signed in)
Posted on: Wednesday, March 16, 2011 at 3:20 AM
Message: It worked and I am able to login to the computer with SYSTEM account using this method.

David,

I guess you missed to add one step here. While renaming magnify.exe, it is giving me access denied error. After a close look, I noticed that only trustedinstaller account has modify permission on this file and administrators are having just readonly. I made myself as owner of the file and changed the permissions to allow admins to modify the file. After that, I am able to rename it without any issues. I did this on windows 7, not sure vista(you depicted case) also has similar restrictions.


Subject: Re: Gaining Physical Access to a computer
Posted by: lordspartner@gmail.com (not signed in)
Posted on: Wednesday, March 16, 2011 at 4:42 AM
Message: The methods described here is only meant for those who have mastered remote hacking techniques. A lame attacker even whilst sitted in front of a computer may not know what to do.

Subject: Re: Gaining Physical Access to a computer
Posted by: lordspartner@gmail.com (not signed in)
Posted on: Wednesday, March 16, 2011 at 4:44 AM
Message: The methods described here is only meant for those who have mastered remote hacking techniques. A lame attacker even whilst sitted in front of a computer may not know what to do.

Subject: Simply enable WinRM and have PowerShell at his remote beck and call
Posted by: Chad Miller (not signed in)
Posted on: Wednesday, March 16, 2011 at 7:47 AM
Message: I disagree with your assertion that you can simply enable WinRM. Using WinRM requires a valid Windows credential which by default must be a member of local administrators to enable or use. In addition WinRM works within a domain environment by default. Furthermore WinRM/PowerShell remoting requires firewall settings. You can also enforce WinRM/PowerShell remoting settings via GPO.

Subject: Trusted Installed Permissions
Posted by: WesleyDavid (view profile)
Posted on: Wednesday, March 16, 2011 at 12:02 PM
Message: @Sitaram

When are you getting the access denied error? Renaming magnify.exe via a boot disk should not give this error. Are you trying to rename the file while Windows is still running?

Subject: WinRM
Posted by: WesleyDavid (view profile)
Posted on: Wednesday, March 16, 2011 at 12:11 PM
Message: @Chad Miller

Since WinRM needs a valid Windows credential, the attack shown will work great since you can simply add an administrator account or reset the password of an existing account.

As for WinRM in a domain, it can also work in a workgroup. Firewall settings will be able to be defeated via the local admin account. If the server is part of a domain and receiving GPO settings, there are some privilege escalation attacks that could be used to gain domain admin privileges. One merely needs local admin privileges to begin.

Subject: Magnify vs Magnifier executables
Posted by: Andy Dent (not signed in)
Posted on: Monday, March 21, 2011 at 2:22 AM
Message: You refer to magnify.exe a few times and magnifier.exe the rest of the time. Which is it?

Subject: Why go the long way round?
Posted by: Peter Crowther (not signed in)
Posted on: Monday, March 21, 2011 at 9:16 AM
Message: Just burn a copy of the free boot disk at http://pogostick.net/~pnh/ntpasswd/ and do the whole password reset from Linux, typically in under two minutes and with only one reboot.

I keep that disk in my set of "emergency fix" disks, along with Ghost, Windows XP driver disks for the more common SATA chipsets, a USB floppy drive...

Subject: security conundrum
Posted by: Anonymous (not signed in)
Posted on: Monday, March 21, 2011 at 1:01 PM
Message: It is a problem that the more secure you make it, the more difficult (or impossible) for a legitimate person to get into it when something goes wrong or a password is lost (and, alas, cryptic passwords are almost impossible for most people to remember).

Years ago cars were easier to steal, but legitimate owners could still (with help) get access. Now with all the interlocks and encryption, lost keys may require towing and replacement of the central computer (at the potential cost a couple thousand). Pretty scary risk.

It gets down to which risk is greater greater in each particular circumstances; attack by an outsider, or lost access to the machine by a legitimate user.

Subject: security conundrum
Posted by: Anonymous (not signed in)
Posted on: Monday, March 21, 2011 at 1:16 PM
Message: It is a problem that the more secure you make it, the more difficult (or impossible) for a legitimate person to get into it when something goes wrong or a password is lost (and, alas, cryptic passwords are almost impossible for most people to remember).

Years ago cars were easier to steal, but legitimate owners could still (with help) get access. Now with all the interlocks and encryption, lost keys may require towing and replacement of the central computer (at the potential cost a couple thousand). Pretty scary risk.

It gets down to which risk is greater greater in each particular circumstances; attack by an outsider, or lost access to the machine by a legitimate user.

Subject: Great read but...
Posted by: Shamu F.D (not signed in)
Posted on: Monday, March 21, 2011 at 5:12 PM
Message: I would have to agree with Peter Crowther. I find the mentioned tool very handy in emergency situations needing password reset. In most cases you accept the defaults and you have an accessible machine in no time at all.

Subject: Hackers
Posted by: Rick (view profile)
Posted on: Tuesday, March 29, 2011 at 6:38 PM
Message: I've know a few real hackers and have been amazed at how they gain access to things. They might call an office and gain information over the phone or actually set foot on site and get the information. They know how to act and what to say to gain whatever access they want.

I've noticed that people often will write down their passwords when things get too secure. At one client, I noticed they have the password on a post it note on the monitor.

Subject: Not even on disk encryption is guaranteed to save you
Posted by: Theo Spears (not signed in)
Posted on: Wednesday, March 30, 2011 at 6:30 AM
Message: It makes life more difficult, but an attacker with local access for long enough can potentially steal the encryption keys from your ram. See: http://www.youtube.com/watch?v=JDaicPIgn9U

Subject: Thanks for the correction!
Posted by: WesleyDavid (view profile)
Posted on: Wednesday, April 06, 2011 at 4:07 PM
Message: @Andy Dent

The correct executable is magnify.exe. The correction has been made. Thanks for the heads-up!

 

Top Rated

Migrating to Microsoft BPOS - Part II
 In his last article, Johan gave us a crystal clear guide to preparing to migrate from an on-premises... Read more...

Emulating the Exchange 2003 RUS for Out-of-Band Mailbox Provisioning in Exchange 2007
 Exchange's Recipient Update Service was important in Exchange 2000 or 2003 in order to complete the... Read more...

The Postmasters
 The Exchange Team introduces themselves, and keeps you up-to-date Read more...

For this Exchange Server Archiver, “Transparency” Fits
 Sometimes, it is a great relief when a user of your software gives it a tough test and then reports... Read more...

Hunting in Packs, Seamless-ness and Happy Holidays
 I attended DevConnections (Exchange) last month and was blown away by the technical talks. Speakers... Read more...

Most Viewed

Upgrade Exchange 2003 to Exchange 2010
  In this article, the first of two in which Jaap describes how to move from Exchange Server 2003... Read more...

Upgrade Exchange 2003 to Exchange 2010 - Part II
 In Jaap's second article on upgrading straight from Exchange Server 2003 to 2010, he explains how to... Read more...

Goodbye Exchange ExMerge, Hello Export-Mailbox
 ExMerge was a great way of exporting a mailbox to an Exchange PST file, or for removing all occurences... Read more...

Exchange E-mail Addresses and the Outlook Address Cache
 Because Exchange auto-complete cache uses X.500 addresses for e-mail sent to addresses within the... Read more...

Using Exchange 2007 for Resource Booking
 The process of booking various resources to go with a meeting room just got a whole lot easier with... Read more...

Why Join

Over 400,000 Microsoft professionals subscribe to the Simple-Talk technical journal. Join today, it's fast, simple, free and secure.