Yesterday, Lifehacker posted an article called How to Break Into a Windows PC (And Prevent it from Happening to You). Some people weren’t happy that they posted a tutorial on how to hack into Windows systems.
Let me tell you why every sysadmin needs to know how to hack into Windows systems, given physical access. I can give you three scenarios that I’ve run into.
Scenario 1: Old backups. This is the most likely scenario. You may have to build a server using an old system image, or restore a server using a very old backup. And part of that image or backup could be an old username and/or password, used by a predecessor, that’s no longer documented anywhere, whether by accident or by policy.
This build or restore can result in a system that nobody knows how to log into. That leaves you no choice but to hack in.
Scenario 2: Old servers. Sometimes you may find yourself facing an old server, built by one of your predecessors. At some point, you’ll probably have to log on using the local administrator account. There could be several reasons for this. Perhaps the machine has been powered down long enough that the DCs kicked it out of the domain. Perhaps another issue with its computer account knocked it off the domain. It’s rare, but not unheard of.
And like the first scenario, those local accounts could potentially be mis-documented or undocumented.
Your job as a sysadmin is to get in by any means necessary, change that username and password to comply with current policy, and then get that system back up and running.
Scenario 3: The rogue sysadmin and the rogue server. This actually happened to me, less than six months into my career during my first sysadmin gig. I noticed a server running in the corner, something I’d never seen before. It had a certain colleague’s name written all over it. So I asked him what that server was for. He gave me an evasive look. “Oh, stuff,” he said.
Sounds completely innocent, huh?
A pattern of erratic behavior emerged in the days that followed. I won’t go into the details, but not long after that, I came back for lunch one day and found out this coworker no longer had a job.
At that point, we had to secure the network. Mostly that was easy. But what about that mystery server that I’d asked him about?
It wasn’t on the domain. I hacked in by using an emergency recovery disk from a server with known usernames and passwords to replace the accounts on that server. We didn’t have a copy of ERD Commander or whatever it was called in 1997, so that was the fastest way to do the job. There are obviously better ways to do it now.
Once we got in, we didn’t find anything. I have my ideas about what that server had been, but maybe he cleaned things up after I asked about it.
This should be a rare occurence, but like any HR issue, it isn’t completely avoidable.
Finally, there’s an even easier method that involves using Sticky Keys.
Now, when it comes to your own PCs, wanting to keep other people out of them is certainly understandable. But there is no way to keep people completely out. If I can touch the system with my hands, I can get in one way or another. Encrypting your data is the only way to keep me from getting at it.
But be aware that encryption has its own pitfalls. If your disk experiences a physical failure, it makes it more difficult and complicated for a company like Ontrack to recover. They can do it, but it will cost more. And the encryption included in Windows has its own drawbacks, including circumstances under which you can lose access to your own files.
This doesn’t mean you shouldn’t encrypt your data, but it means it’s not something you should do just because it sounds cool. It does mean that if you do, you need to be even more vigilant about making backups of your critical data.
So that’s how you hack into Windows systems, and why you need to know how.