Typically, while configuring Active Directories, system admins overlook the harm caused by allowing a local administrator account on a system assigned to a specific user. Consequently, companies label this setup as a “necessary evil,” arguing that enabling users to handle tasks like new tool installations in large enterprises reduces pressure on the IT team, even if it introduces risk. In this article, we will demonstrate how an attacker who compromises a system with an active local administrator account and a computer account in the domain admins group can dump hashes in the domain. Furthermore, we will explain how attackers use machine accounts to maintain domain persistence.

Table of content

• Attack Methodology
• Computer Accounts vs User Accounts
• Domain Escalation using Mimikatz
• Domain Persistence using powermad
  • userAccountControl attribute
• Conclusion

Attack Methodology

The methodology proceeds through the following steps:

• First, the attacker compromises a user account with local admin access.
• Then, the attacker uses Mimikatz to dump the NTLM hash of an account named “Harshit,” which belongs to the domain admins group.
• Next, the attacker executes a PTH attack to browse files on the domain controller.
• After that, the attacker adds a new machine account using admin privileges.
• Subsequently, the attacker modifies the userAccountControl parameter to promote this machine account to Domain Controller.
• Finally, the attacker achieves persistence in the domain.

To clarify, the victim we compromised possesses an associated computer account named “Harshit” (a machine account), which belongs to the domain admins group. Moreover, the victim maintains an active local administrator account that we have already accessed.

Computer Accounts vs User Accounts

For a detailed guide on users and computer accounts please refer to Microsoft’s docs here and here.

Machine Accounts aka Computer Accounts are similar to User Accounts from the AD’s point of view. Major difference is as follows:

• The system randomly generates and resets a computer account password every 30 days.
• Creating a user account also generates an associated computer account.
• A user, if granted rights, can create multiple computer accounts. Default value is 10.

System admins widely use computer accounts to categorize and manage Active Directory forests efficiently. For instance, the most common use is organizing security groups using these accounts. Nevertheless, that topic falls outside the scope of this article.

You can easily identify machine accounts or computer accounts by checking for the “$” symbol at the end of the account name.

Domain Escalation using Mimikatz

At this point, the attacker has successfully compromised an account with local administrator access. Upon further investigation, we discovered that a computer account—also known as a machine account—had been created and added to the Domain Admins group.

To enumerate all the domain admins present in the Active Directory, one can use the command net group “domain admins” /domain. Likewise, in PowerShell, running net localgroup administrators /domain reveals the same information. In this case, we identified that the account “Harshit” was part of the domain admins group. To confirm this, we used the following command:

net user Harshit

As expected, the computer account “Harshit” was indeed listed under domain admins.

An attacker can leverage the availability of local administrator access to run mimikatz and dump the NTLM hash of the computer account “Harshit”

privilege::debug
sekurlsa::logonPasswords

As you can see, we have obtained an NTLM hash for the computer account Harshit.

An attacker can use this NTLM hash to conduct a PassTheHash attack to escalate privileges to Domain Admin.

sekurlsa::pth /user:harshit /domain:ignite.local /ntlm:64fbae31cc352fc26af97cbdef151e03

This new command prompt window which opens can now be used to access Domain Controller’s file system like so

dir \\dc1.ignite.local\c$\Users\Administrator

There are a number of ways to fully compromise the DC now. An attacker can upload an exe here and gain a reverse shell or simply dump the SAM file. We won’t cover that now. Let’s put our focus on how we can maintain persistence on this domain using a computer account now.

Domain Persistence using powermad

The aim is to utilize this newly obtained administrator command prompt to add a new computer account and make it a domain controller so that we can maintain persistence on the domain now.

Upon a little googling, I found a great powershell script that would allow us to add a computer/machine account called powermad. You can use powershell and IWR to bring this into the system and utilize using the Admin prompt we have opened.

A user can create computer accounts. Default value is 10. A system admin can modify this to restrict a user from being able to create computer accounts.

Win+r -> adsiedit.msc

 

This opens up AD service interface editor. You can select the forest and go to its properties.

You can view the attribute editor (which is a collection of objects editable through powershell and manually through GUI) and see the attribute “ms-DS-MachineAccountQuota.” As you can see, the value is set at 10, so my user can create 10 machine accounts without a problem.

This can be checked using powermad too. Now, we would import powermad psm1 module and create a new machine account called “noob”

powershell -ep bypass
Import-Module .\Powermad.psm1
New-MachineAccount -MachineAccount noob -Domain ignite.local -DomainController dc1.ignite.local

As simple as that!  A new machine account has been added now

This can be verified on the AD by running the get-ADComputer command and * as a filter.

As you can see noob has been added (Note SamAccountName noob$ indicating this is a computer/machine account)

Under the AD, we can now see that noob has been added in the “Domain Computers” group.

userAccountControl attribute

Just like we have the MachineAccountQuota attribute, we have another attribute called userAccountControl which can be viewed from the AD server manager->tools->AD users and groups->computers->noob

You need to select view->advanced features first

And then you would be able to see attribute editor. Under this large list, we can see the userAccountControl parameter set to 4096.

This value 4096 is the ASCII equivalent of the hex value 0x1000 which categorizes this machine/computer account as a workstation trust account.

To make this newly added computer/machine account noob as the domain admin, we need to change this attribute to 8096 (0x2000 in hex).

This can be done using our escalated Powershell prompt.

To view this attribute with the help of powershell we can do this:

Get-ADComputer noob -pro name,primarygroupid, useraccountcontrol

This tells us the value 4096 is set currently.

We can change this value with the Set-ADComputer command:

Set-ADComputer noob -replace @{“useraccountcontrol” = 8192}
Get-ADComputer noob -pro name, primarygroupid, useraccountcontrol

You can now see that this computer account has been added to Domain Controller’s group and the value changed to 8192

This can be observed via AD too. Note that 0x2000 (hex of 8192) has made it from a WORKSTATION_TRUST_ACCOUNT to SERVER_TRUST_ACCOUNT.

We can confirm that noob has become a domain controller now by going to a member of tab

Additionally, an attacker can perform a number of attacks now that this account has become a Domain Controller. Furthermore, the attacker has established persistence. He can dump this new account’s hash (DCSync attack) and conduct PTH attacks or generate a golden ticket now.

Conclusion

Machine or computer accounts have existed for decades, perhaps even longer. However, organizations have not widely discussed their security implications. Through this article, we have tried to spread the word about one such method through which an attacker can conduct domain escalation and then persistence by using machine accounts. System admins should not let any user create machine accounts to avoid such threats. Thanks for reading. Hope you liked the article.

Author: Harshit Rajpal is an InfoSec researcher and a left and right brain thinker. Contact here