Computers are People Too

There are those rare times during pen tests, when you are on a client’s network and you don’t have any valid domain credentials but you do have local admin on a windows device joined to the client’s domain. Perhaps you’ve exploited a vulnerability on a system that grants you local admin rights. Or maybe you’re in the situation we recently had, where we joined our windows attack host to the client’s domain but any domain account we used was incredibly restricted due to policies enforced by GPO (Group Policy Object).  However, the computer’s local administrator account was not restricted in any way. Unfortunately, accounts on the local computer system typically don’t have the ability to logon or interact with other systems on the network, including Active Directory. This severely hampers your ability to find additional information (like privileged accounts) and then pivot/escalate access across the network.

As shown to the right, when I use the local administrator account on the “BAD” computer, I get an access denied error in my simple PowerShell query attempting to find the Active Directory domain the computer is a member of, lab.pvt.

The thing is, by being joined to a domain, the computer can interact with Active Directory (AD).  It needs to be able to reach out to AD so it can do things like pull down security policies before users logon.  Therefore, if you can find a way to become the computer, you’ll have whatever rights it does within AD. So, how does one become the computer? The answer is, by gaining SYSTEM privileges.  

We often think about SYSTEM as a way to get total access to everything on a windows computer (typically to harvest passwords or kerberos keys) and it’s easy to overlook the fact that SYSTEM just means “the computer account”.  Admittedly, most computers don’t have any special rights and, therefore, are just members of Everyone and Authenticated Users; but that’s still enough to query AD and browse File Shares that have the default security settings.

As a quick demo, I used a psexec command (psexec -i -s powershell.exe) to open an interactive PowerShell window, with SYSTEM privileges (-i is interactive and -s is with SYSTEM privileges).  At that point, the PowerShell window is the computer, BAD, and not the local administrator account.  The computer can query Active Directory (as shown by number 4) and can browse out to the sysvol file share on a domain controller (number 5).

So the next time you get stuck with local accounts on a windows server, don’t forget that computers are people too, and have the same permissions as a normal user.