Sneaky Active Directory Persistence #16: Computer Accounts & Domain Controller Silver Tickets

The content in this post describes a method by which an attacker could persist administrative access to Active Directory after having Domain Admin level rights for about 5 minutes.

All posts in my Sneaky Active Directory Persistence Tricks series

This post explores how an attacker could leverage computer account credentials to persist in an enterprise and how to mitigate potential security issues.

Computer Accounts

Every computer joined to Active Directory (AD) has an associated computer account in AD. A computer account in AD is a security principal (same as user accounts and security groups) and as such has a number of attributes that are the same as those found on user accounts including a Security IDentifier (SID), memberOf, lastlogondate, passwordlastset, etc. Computer accounts can belong to security groups and often do for a variety of reasons, most commonly for Group Policy filtering so that certain group policies only apply to specific groups of computers (or not).

The computer account password is initially set when the computer joins the domain and is used for authentication in much the same way as a user’s password is. The difference is that a computer’s password doesn’t have to be changed on a regular basis in order for the computer to authenticate to the domain (unlike user accounts). There is a setting that configures how often the computer’s account password *should* be changed and computers in the domain will typically change their computer account password about every 30 days (by default). With that said, this threshold can be changed and the process used to change the computer account password can be disabled entirely.

Computer account password changes are more of a guideline than a rule, and I have posted previously about how a computer account password could be used to wield significant power over that system. However, I didn’t cover the other angles which are explored in this article.

Computer accounts are members of the “Domain Computers” AD group by default, and are often added to Active Directory groups for purposes of group policy management, though there are other reasons for adding computer accounts to AD groups.

Common Examples of Computers in Groups:

  • Domain Controllers are members of the “Domain Controllers” group.
  • Read-Only Domain Controllers (RODCs) are members of the “Read-Only Domain Controllers” group.
  • Exchange servers are often members of different Exchange AD groups such as “Exchange Servers”.

 

Computers as Admins?

The obvious question is ‘what is the impact of a computer in a an admin group?’

When a computer authenticates to the domain, typically via Kerberos, there is a ticket/token created that contains the computer’s SID and all SIDs for security groups the computer is a member of, just like when a user logs on. This means that the authenticated computer has these rights to resources in the domain/forest similar to a user who is a member of the same group. If a computer account is in an admin group, the computer account has admin rights and by extension, any admin on that computer could gain those same rights.

Computer accounts can have elevated rights to resources, including full admin rights to Active Directory.

 

How does the computer leverage these rights or access?

The computer’s System account “owns” the ticket/token containing the SIDs that have these rights (technically “System” isn’t an account, but it works for this description). Anyone who has (local) administrative rights on a computer can change the context of their rights to System  to effectively take ownership of the computer account’s rights in AD. Mimikatz provides the ability to grab all Kerberos tickets and tokens on the system, so it is trivial to reuse these in order to leverage these rights.

Note that there is no functional difference between a computer account having the rights or a service account with the rights that has it’s credentials stored on the system running as a service. Both of these lead to credential exposure if the system is compromised. However, service accounts are managed quite differently than computer accounts and using a service account is better in most cases.

 

Privilege Escalation

An attacker could escalate privileges from gaining administrative rights on a computer to having elevated rights in the domain simply because the computer’s account is joined to an admin group.

For example, if an admin server is joined to a group with backup rights on Domain Controllers, all an attacker needs to do is compromise an admin account with rights to that admin server and then get System rights on that admin server to compromise the domain.

Obviously a few items have to be in place for this to work:

  1. Compromise an account with admin rights to admin server.
  2. Admin server computer account needs rights to Domain Controllers.

Based on my experience, as well as that of others, I have found this to be a scenario that is not only possible, but is reality in a lot of organizations.

Note that there are several other ways to take advantage of this and similar scenarios and this isn’t the only potential attack.

 

Exploitation & Persistence

Domain Controller Silver Ticket

If the attacker has dumped the Active Directory database or gained knowledge of a Domain Controller’s computer account password, the attacker can use Silver Tickets to target the Domain Controller’s services as an admin and persist in Active Directory with full admin rights.

Once the attacker gains knowledge of a Domain Controller’s computer account, this information can be used to create a Silver Ticket providing long-term admin rights to that DC.

Computers host services as well with the most common one being the Windows file share which leverages the “cifs” service. Since the computer itself hosts this service, the password data required to create a Silver Ticket is the associated computer account’s password hash. When a computer is joined to Active Directory, a new computer account object is created and linked to the computer. The password and associated hash is stored on the computer that owns the account and the NTLM password hash is stored in the Active Directory database on the Domain Controllers for the domain.

If an attacker can gain admin rights to the computer (to gain debug access) or be able to run code as local System, the attacker can dump the AD computer account password hash from the system using Mimikatz (the NTLM password hash is used to encrypt RC4 Kerberos tickets): Mimikatz “privilege::debug” “sekurlsa::logonpasswords” exit

Mimikatz-Sekurlsa-LogonPasswords

Create a Silver Ticket for the DC to Connect to PowerShell Remoting on the Domain Controller with Admin Access

Create a Silver Ticket for the “http” service and “wsman” service to gain admin rights to WinRM and/or PowerShell Remoting on the target system.

SilverTicket-DC-HTTP

SilverTicket-DC-WSMAN

After injecting the two Silver Tickets, http & wsman, we can use PowerShell Remoting (or WinRM) to open a a shell to the target system (assuming it’s configured with PowerShell Remoting and/or WinRM). New-PSSession is the PowerShell cmdlet for creating a session to a remote system using PowerShell and Enter-PSSession opens the remote shell.

PowerShell-Remoting-Connect-To-ADSDC02

SilverTicket-DC-PSRemotingExploit2


Create a  Silver Ticket for the DC to Connect to LDAP on the Domain Controller with Admin Access and Run DCSYNC.

Create a Silver Ticket for the “ldap” service to gain admin rights to LDAP services on the target system (including Active Directory).

SilverTicket-DC-LDAP

Leveraging the LDAP Silver Ticket, we can use Mimikatz and run DCSync to “replicate” credentials from the DC.

SilverTicket-DC-LDAP-Exploit-DCSync

Persistence via Computer Account

Assuming that an attacker is able to compromise the domain, a sneaky way to maintain elevated domain rights is to add a computer account (or group containing computers) to have rights to areas of Active Directory useful for persisting.

This method is two-pronged:

  1. Compromise the computer account password on an admin or backup server in the environment which enables access to that system (disable computer account password updates to ensure continued access).
  2. Delegate rights to that server’s computer account (or a group containing it) to critical AD components.

Another way to leverage a computer account for AD persistence is to place the computer account in a privileged group that has other accounts. Here’s a common example: There’s a group called “AD Backups” which has a service account as a member called “svc-backup.”

When enumerating the group membership of the domain Administrators group (which has full AD admin rights as well as full admin rights to Domain Controllers in the domain), we see that the “AD Backups” group is included. This is an all to common configuration, though being a member of Domain Admins would be worse. Ideally, the backups group or service account should only be a member of “Backup Operators” in the domain in order to backup AD domain data.

SneakyADPersistence-ADBackupsGroup-in-Administrators

The attacker adds the compromised computer account to the “AD Backups” group and does nothing else. The ADSAP01 computer account now provides the attacker with full admin rights to the domain and all Domain Controllers and is able to run Mimikatz’s DCSync at will to pull password data for any account.

SneakyADPersistence-ADBackupsGroup-in-Administrators-2

 

Mitigation

The simplest way to mitigate this issue is to ensure that no computer accounts are members of admin groups. Make this policy and enforce it by regularly checking admin groups for computer accounts.
Scanning for this with PowerShell is pretty simple since all that needs to be done is to search for all groups with “admin” in the name (or similar customized to the environment) and flag any member that is objecttype = ‘computer’.

Here’s a quick PowerShell script (requires the Active Directory PowerShell module) that will look for “admin” groups and identify the groups with computer accounts as members.

Import-Module ActiveDirectory

$AdminGroupsWithComputersAsMembersCountHashTable  = @{}

[array]$DomAdminGroups = get-adgroup -filter {Name -like “*admin*”}
[int]$DomAdminGroupsCount = $DomAdminGroups.Count
Write-Output “Scanning the $DomAdminGroupsCount Admin Groups in $ForestDomainItem for computer accounts as members”

ForEach ($DomAdminGroupsItem in $DomAdminGroups)
{
[array]$GroupContainsComputerMembers = Get-ADGroupMember $DomAdminGroupsItem.DistinguishedName -Recursive | Where {$_.objectClass -eq ‘computer’} $AdminGroupsWithComputersAsMembersCountHashTable.Set_Item($DomAdminGroupsItem.DistinguishedName,$GroupContainsComputerMembers.Count)
[int]$DomainAdminGroupsWithComputersCount = $DomainAdminGroupsWithComputersCount + $GroupContainsComputerMembersCount
}

Write-Output “$DomainAdminGroupsWithComputersCount Forest Admin groups contain computer accounts”
$AdminGroupsWithComputersAsMembersCountHashTable

As always, this script is provided “as is.”

PowerView, now integrated into PowerSploit, includes capability to help identify computers in admin groups:

Get-NetGroup -AdminCount | Get-NetGroupMember -Recurse | ?{$_.MemberName -like ‘*$’}

 

The other mitigation is to ensure that all computer account passwords change every 30 – 60 days, especially servers (Domain Controllers!).

 

Resources

 

 

 

(Visited 27,690 times, 6 visits today)

4 comments

Skip to comment form

    • jd on March 10, 2016 at 5:07 am

    In the topmost image of the article the computer account has NTLM hash set to 595d……bdd2 but in the second and third image you use hash f793……f28f in order to create silver tickets… Why the difference ?

    1. The silver tickets weren’t all generated in a single session, so the hash changed. I’ll update the post. Thanks!

    • BDJ on March 14, 2016 at 1:47 pm

    Seems like a savvy attacker would grant themselves persistent access using direct, discrete ACLs instead of latching on to an obvious admin group (or even a less obvious nested group). Defenders are more likely to manually or automatically audit admin group memberships than audit the ACLs on individual objects. With a prepared script, setting up the discrete ACLs wouldn’t take any longer.

    1. One would think that admin groups are properly monitored, though this isn’t always the case. Additionally, computer accounts in an admin group aren’t scrutinized at the same level as user accounts. You are correct that direct, discrete ACLs are a solid method for an attacker to retain persistence and I have covered some of this before: Sneaky Active Directory Persistence #15: AdminSDHolder (https://adsecurity.org/?p=1906).

Comments have been disabled.