The Security Risks of Local Admin Access

May 25, 2016


In today’s Whiteboard Wednesday, Leon Johnson, Penetration Tester at Rapid7, will discuss local administrator privileges and how it can become a security risk at your organization.

Leon will go over a common attack scenario and will explain how exploiting somebody with local admin privileges makes it much easier for an attacker to become a domain admin with unrestricted access to your network.

Leon will also go over four different ways to help you limit this vulnerability.


Video Transcript

Welcome to today's Whiteboard Wednesday. I'm your host, Leon Johnson. Today we're going to talk about how local administrators leads to the domain admin. Happens all the time. Every day, all day. This is what we do. 

Show more Show less

As pen testers, as hackers. This is the taxing error that is happening on your network whenever your domain administrator is compromised, whenever you have a pen test, or heaven forbid your network is compromised by some unnamed threat actor. So, there's a lot of ways this can play out. Essentially what happens is though, if I can get local administrator on one box, then the probability of me exploiting the entire network is extremely high. And this is why.

There's a lot of things that happened that allowed me to get local administrator. Things like null sessions. If you're on the network and null sessions are enabled, you can query a domain controller and say, "Hey, give me a list of all the users." The domain controller will say, "Here, buddy. Here's a list of every single user in our network," which might be significant.

At that point, I say, "Hey, does anybody have a password of the name of the company Bain?" Most often they do. If not, winter 2016 or whatever the year is and the date is at that time. It's almost guaranteed to get you at least one password. But let's say we're not even worried about that. We're just a regular user and I happen to be local administrator. 

So if I come in to your company, you give me local administrator, which you would never want to do, but this is what happens. Say, I guess Adam's password. Adam's password is at company Acme, is Acme Bain. So now I log in to Adam's box because Adam has local administrator. You might be thinking, "Well, how do I find that?" 

Okay, so let's say there was no sessions in place. I got a list of all the users. In the user list we have Adam, Molly, and a domain admin who'll remain nameless for this attack because we don't want to embarrass him, even though it's not his fault. 

So we get a list of all these users and I say, "Okay, I have 1,000 users. Let's try password one on all the users." And I get a hit and it turns out to be Adam. So, I know Adam's password is password one. But I don't know where Adam's computer is. But guess what? 

You can scan the network for all the IPs. So now I have a list of all the IPs and I just say, "Try to log in with Adam password one on every single computer. Bink, bink, bink, bink, bink, bink, bink, bink, boom. It a hit because he's local administrator. Great. Now I'm on this box. 

What happens with that? Well, let me explain something. Network administrators usually are responsible for building out networks. And how that happens is usually they build an image. They build some type of default image, they put a local administrator password on there and they push it out throughout the network. 

So all these computers were built by the same person and they probably all have the same local administrator. And if not, it's probably because they are segmented. So maybe these three were built by this local administrator, and these built by another team or this company was merged somehow. But for some reason, these green computers have a local administrator password of X and these purple computers have a password of Y. So now I have Adam's local administrator password. 

I log in his box. Because he's local administrator I can get the actual local administrator off the computer, which allows me to log in to this box. And I log in to this box and I look around, and I see a user name who doesn't have local administrator. So I don't care. I move on. I log in to this box and I see Molly. 

And so now I have Adam's password. I have some user that I don't know that I don't care about, and I have Molly's password. What do I do again? I take that username and passwords and I try to log in to every single box on the network. And guess what? I get two hits from Molly. She's logged in to this computer, which I already happened to have the local administrator password for. 

But, she also can log in to this computer. And guess what? The local administrator password is different. Like, "Ooh, goody." So what do I do again? I pass that local administrator against the whole network again and I get three more hits. 

And guess what happens? I find this guy and he happens to be a domain administrator. So I log in to his box, I steal his hashes, and guess what? I'm domain admin too, and I'm dancing all over the network. So that's kind of how that plays out. There's a lot of scenarios where this can kind of be different, but ultimately that's how the scenario plays out. 

So, how to limit this. How do I prevent this from happening? There's a lot of ways. The most ideal way in my opinion, and this is just my viewpoint, is you have different local administrators on every box. I've seen it done in a few networks. It's very rare. There's software, enterprise software, that'll allow you to do this.

It essentially equates to some type of password safe for a network. Ideal, but hard to implement, especially if you're a large conglomerate or you're constantly merging. And there's a lot of situations where it's not necessarily practical. Okay. Network segmentation is next best in my opinion, because if I have this person's password, and for some reason this network is segmented from that network, I can't log in to it. 

Or even better, domain admin should be segmented from the entire network so even though I have all this credentials and all this access, I can't reach that computer to log in to it. And that prevents you from escalating your privileges. Or if for some reason Adam happens to work in finance and Molly happens to work in HR, they should probably not be talking to each other. So there should be some type of firewall at some point depending on where this user lies in those departments that prevents traffic going from here to here. 

There's no reason for it. So why do it? When you think about a company, everybody sitting in different departments, and there's usually a hallway that you go through. And if you're a riskier building you have badges to get to those other departments. You should do the same with your network. We do a lot of things for physical controls, but for some reason we don't do those on networks. 

I don't know why that is. Least privilege model for domain users. Why is Adam a domain user? Why does he have local administrator access? He probably shouldn't have that. You might argue, "He needs to install software." Well, there's other ways that you can create users to do certain things on the network. Always go with the least privilege model. If he doesn't need to have local administrator access, he probably shouldn't because that also prevents the attack from happening. 

And monitor successful and failed logins, because most people monitor failed logins because they're worried about the network. If Adam tries to login he gets locked out. If a bunch of people fail logins then you know it's some type of brute forcing happening. But if there's 100 successful logins in a span of a second, then some type of alarm should go off as well. And people aren't looking for those on most networks. So you should probably look in to that as well. We also have products that help you do that

That's it for this week's Whiteboard Wednesday. We'll talk to you next week.