Why every sysadmin needs to know how to hack into Windows systems

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. And more frequently, this problem manifests itself as shadow IT today.

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.

2 thoughts on “Why every sysadmin needs to know how to hack into Windows systems

  • October 28, 2010 at 10:46 pm
    Permalink

    I get this call about once a month. Server Admin is experiencing “problems” (use your imagination). To troubleshoot problem, Server Admin removes the server from the domain, hoping that rejoining it to the domain will solve the problem. Server Admin then discovers that the local administrator name and/or password is not what s/he thought it was.

    I once had to recover a machine password after a person passed away. Apparently, among other things, the latest copy of his will was stored on there … behind a password that nobody knew. I guess some things you CAN take to the grave.

  • October 29, 2010 at 8:48 pm
    Permalink

    Robohara, before my mother passed away in 1996, she had her will amended to add in a couple of grandkids, while on her deathbed. Her lawyer visited her in the hospital, went home, wrote the amended will up, saved in on his computer and had a heart attack. He ended up two rooms down from my mother, and died the following day. My mother did two days after that. Retrieving the will from his password protected Mac was reportedly a lot of hassle, but it _was_ accomplished. The lesson was to always print out the will and put it in a safe place, something which a computer is decidedly not.

Comments are closed.

%d bloggers like this:
WordPress Appliance - Powered by TurnKey Linux