We've all heard that physical security is important, right? Well a lot of people don't
get just how important it is. I'm going to show you how an entire Windows domain can be hacked in just
a couple of minutes if you leave even a single server physically accessible. Then I'll show you
how to prevent it, because realistically somebody somewhere is going to have access to a server.
Welcome back to The Pro Tech Show - the place for tech, tips, and advice for IT pros and decision-
makers. There's a saying that goes something along the lines of "If someone can get physical access
to your computer, it's no longer your computer." I'm going to expand on that and say if someone can get
physical access to one of your servers, it's no longer your business. I think people generally
get this. Most server rooms have locks on the door. You can't just randomly wander into datacentres.
But despite this there are often gaps - little chinks in the security that can be easily
exploited. Here are some examples that I see fairly often. Non-IT staff who have access to a server
room. This could be a cleaner; maybe it doubles as a storage room for secure documents; maybe there
are no onsite IT staff and somebody else has access to swap the backups or reboot the router.
What about your remote sites? I'll often go to a head office and they'll have a server
room that looks like a bank vault, then I ask them about that little office out in
the middle of nowhere with like five people in it and they're "Uh... I don't know... Do they have a server?
Maybe just the one... Does it really matter for five people?" Yes! That one server in that remote
office in the middle of nowhere can backdoor your entire network in seconds. Or how about a rogue
admin in your company? Or for that matter let's say you use a highly secure collocation facility.
What if there's a bad apple on their staff? They have access to your servers, don't they?
So how big a deal is this, really? I've put together a little Windows network to show you.
It's a really simple one with two domain controllers. If you know anything about Windows
networks you'll know that the domain controller contains the crown jewels. It manages all of the
user accounts and security on the network. Domain controllers operate on a multi-master
model with changes from one replicating out to all others; so if we can take control of a single
domain controller then we get everything. It's also a common physical vulnerability
because you'll often deliberately locate domain controllers at remote locations in order to
improve local performance. Let's see how easy it is to abuse one of these domain controllers
without having any kind of login credentials. To do this I'm going to use a very specialised tool... the
Windows install media. You were expecting something more "hacker", weren't you? There are more specialised
tools, but I want you to see just how easy this is so I'm going to use a windows setup disc. Another
reason to use a Windows setup disc is that if an administrator has enabled secure boot then it
isn't going to help because the Windows installer is signed and trusted. Here are two virtual
machines that represent our network. I've logged into DC2 on the right. You can see there's nothing
special here - it's just the default set of accounts you get after installing Active Directory. On the
left we have the domain controller that we're going to pretend is physically unsecured. With
this one I'm playing the attacker so I don't have any account to log in with but I have been able
to walk up and insert the Windows install media and I can press the power button to reboot it.
OK, we've booted off the Windows install media. I'll select my language, click "Repair
your computer", "Troubleshoot", "Command Prompt", and here's where it gets interesting. With Windows
itself offline i can poke about in the hard drive here and there's no authentication to stop me.
That in itself is quite dangerous because I can steal the file that contains everyone's
password hashes and start trying to crack them. If I've got that file I
can start the server back up as normal and crack the file somewhere else at my leisure.
The administrators of this network wouldn't know anything other than a server rebooted unexpectedly.
I'm going to do something even quicker than that, though. Something that will give me immediate
access. The file utilman.exe is used to provide accessibility tools to help if you're visually
impaired. I'm going to rename it, then I'm going to make a copy of cmd.exe and call it utilman.exe.
Cmd.exe is the command prompt that you're looking at here. Well, actually it's the shell behind it.
Link up here and in the description if you want to learn the difference between terminals and shells.
That's basically the network hacked. Let me show you what that simple change has done for us.
Let's reboot the server back to Windows before someone comes to investigate.
OK, here we are back at the logon screen. We still don't have a password, though. Doesn't matter.
We don't need one. You see this little icon in the bottom-right? That's the button to open our
accessibility options. That's the button that runs the file I replaced with a command prompt. Look
what happens when I click it. Uh oh! I shouldn't be able to use this without logging in, now should I?
It's worse than that. Whose user account is it running as, because nobody's actually logged in?
That, my friends, is what I believe the kids are calling a "big oof". This command prompt
is running as the Windows "system" account. The Windows "system" account on a domain controller!
On a running domain controller that account has more access than any of the actual administrators
on the network. I could use it to create a new user account with a terrible password.
I can use it to add that account to a highly privileged security group.
If I switch over to my other domain controller and refresh, you'll see that account has
appeared in Active Directory. It has replicated across the network and it's a domain admin.
If I close the command prompt I can even log on to the domain controller with it. At this point I
own the network. If I control that system account I can give myself permission to anything I want.
Are you starting to worry about that site with five people out in the middle of nowhere yet?
If that caught your attention, chuck me a like for the video and leave a message in the comments.
If you're convinced all of your domain controllers are physically secured, here are a few more things
to worry about. On a typical business network servers are often virtualised. In the demo I gave
you I wasn't plugging physical media into a server. I was connecting virtual media to a virtual server.
I did that because it's faster and easier for me to show you and record it without using a capture
card, but that's also how most actual servers are configured. Most don't have a physical console
because they're virtual. This means you have to consider the security of the hypervisor because if
that can be breached then it is the equivalent of getting physical access to the domain controller
and you can do what I just did. The same goes for any underlying storage such as a SAN.
If you can access the storage you can do the same thing. If you do have a physical server,
whether that be the domain controller itself or the hypervisor that hosts it,
don't forget about remote access tools. A lot of servers have lights-out management devices
such as an iLO or an iDRAC that can be used to access the physical console of the server remotely.
This is particularly useful for those remote sites in the middle of nowhere so it staff
don't need to attend site if there's a problem. If the security on those devices isn't up to scratch
then an attacker can do the same thing I just did from anywhere on the network. Finally, it's not
just about domain controllers. If I can log on to member server using the same technique it's only a
matter of time before I can escalate my privileges. All I have to do is to break something and then
wait for an admin to log on to fix it, and dump their password from memory. It doesn't even need to
be a server. I could start the same process from a laptop. It might just take a few more extra hops to
get all the way up to domain admin. So OK, I've got you worried. I'm not going to leave you there.
Here are a few ways to protect yourself. Firstly, the obvious one: do a physical security audit and
make sure physical access to servers is properly controlled. Make sure you've secured not just your
servers but anything that can be used to access your servers. This includes hypervisors, storage,
and remote access tools. Another thing you can do is treat your server like a laptop. Let me show you.
I'm going to try the same trick I used against DC1, but this time against DC2. Boot to the Window setup,
click my way to the command prompt, and... oh! That's different. I'll skip that and try to access the C
drive. No luck. What I've done here is I've enabled BitLocker and encrypted the server's hard drive.
This is something you probably do with laptops to protect their data in case they get stolen. If you
don't, you really should! People rarely do this with servers because they're a lot more difficult to
just slip in your backpack and walk off with, but it's a very effective way to block this sort of
attack. If they can't decrypt the hard drive they can't manipulate it or steal any password files.
If you have servers in locations where you cannot rely on adequate physical security
then encrypting them is quite a sensible idea. Word to the wise, though; if you're doing this at one
of those remote sites then make sure you've got some kind of remote console access in place. A Dell
iDRAC, HP iLO, even an IP-KVM. Just something that lets you access a console before Windows boots.
At some point that server is going to stop during power-up and ask for a recovery key to continue.
When it happens you'll be much happier if you can send the keystrokes over the network instead
of having to jump in a car and drive six hours just to type in a code and then come back again.
Another thing you can do with remote sites is to deploy read-only domain controllers.
These are domain controllers, but more limited. They can process some requests locally and
pass the rest on to full-fat domain controllers elsewhere. If you have a site with five people
you could configure a read-only domain controller to only cache the passwords of those five people.
That way if it gets breached and the password stolen the impact is limited to those five people
instead of the entire business. The other way they protect you is that as the name suggests they're
read-only. They can replicate updates from other full-fat domain controllers,
but they can't push out their own updates. If I try to create myself an admin user account
after hacking a read-only domain controller it won't go anywhere. By the way, it's not "either/or".
You can do both. If you BitLocker a read-only domain controller then it protects even those
five local accounts from an offline attack. If on the other hand an online attack succeeds
over the network, maybe by exploiting an unpatched vulnerability, it being read-only will still help
limit the damage. The final thing you can do about this sort of shenanigans
is monitoring. If random accounts start appearing and then getting added to the domain admins group
I bet you'd like to know about it, wouldn't you? When it's all said and done, no defence
is impenetrable; so you need to stay vigilant. "Assume breach" is the mindset. If you always
act under the assumption that you've already been breached then the focus becomes detection.
Should the unfortunate happen you will then be in a much better place to detect it quickly and
shut it down, limiting the damage. Alright, this has been a relatively short one, I think. I don't
really know. I'll find out when I edit it; but it feels shorter than usual. If you found this useful
then hit the like button, subscribe if you haven't, and have a look over here to see if any of these
videos look interesting as well. It's been great having you. Thanks for watching. See you next time!