Defending Local Admin Against Physical Attacks

In my previous blog entry, I wrote about some of the issues with having a shared password for the local administrator account on Windows desktops. This is a common problem that we encounter during penetration tests, and one that often leads to easy lateral movement throughout the organization and privilege escalation up to a domain administrator account.

Specifically, I discussed two protection measures to help protect local administrator accounts while a workstation is booted. First, do not allow users to be administrators on their desktops. Second, create unique passwords for each local administrator account. It's not hard to understand the benefits of the first recommendation, but how does having unique local administrator passwords hold up to physical attacks against a local machine?

It's an interesting question because, as we all know, if you have physical access to a computer, then you own it. However, in this situation, you would still only own that one workstation because that local administrator password is not used anywhere else. It prevents quick movement to other hosts, however, that one foothold may be all that's needed to pivot, attack, and escalate.

Without Autorun disabled and a non-admin logged in, a patient attacker would need to reboot the workstation, install malware, and wait for a privileged domain account to log in so he could impersonate the account and move to other systems. Or, as we did in a penetration test last week, he could leverage the unprivileged account to scour the network file shares to find passwords that eventually lead to root access of all Linux servers ... but that's for another post.

So how do we protect those systems from physical attacks? The usual approach is to disable the ability for the computer to boot from alternative media, such as a CD/DVD drive or USB flash drive. Traditionally, a password for the BIOS will prevent an attacker from being able to change the boot sequence from the hard drive to an alternate device, like a USB flash drive or optical media. While this approach generally still holds true, it is not foolproof since a lot of today's desktops and laptops support PXE network booting prior to booting the hard drive.

PXE boot support? Who cares, right? You should. Instead of walking over to a target machine, sticking in a DVD or USB flash drive, rebooting it, and stealing the local password hashes or planting a Trojan, PXE boot attacks allow an attacker to do essentially the same thing without ever physically touching the target workstation. Support for PXE boot attacks were added to Metasploit a couple of years ago with pxesploit. For more details about pxesploit, check out this blog entry I wrote when it was first released at DefCon in 2011.

If you aren't using PXE booting for rapidly deploying systems, then disable it on all of your systems in addition to locking down the BIOS. Or enable it only during the time you're doing the deployment, and then immediately disable it.

The last protection I want to mention is full disk encryption. Even with BIOS protections, a determined attacker could remove the drive, plant malware or steal password hashes, and put the drive back in. Full disk encryption would prevent this and provides protection against data loss and exposure if the system were lost or stolen. A silver bullet? No, of course not, but it's another layer in a layered approach to protecting endpoints.

There are also physical security protections, but that's beyond today's scope. No need for unnecessary scope-creep, right?

That's it for now. On Friday, I will be posting the final blog entry about this topic and will be covering tools to help with keeping all those local Windows administrator accounts unique. For any questions or comment, please leave a comment below or send me a message via email or Twitter.

John Sawyer is a Senior Security Analyst with InGuardians, Inc. The views and opinions expressed in this blog are his own and do not represent those of his employer. He can be reached at [email protected] and found on Twitter @johnhsawyer.