This post explores how an attacker could leverage computer account credentials to persist in an enterprise and how to mitigate potential security issues.<\/p>\n
<\/p>\n
Computer Accounts<\/b><\/h3>\n
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).<\/p>\n
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<\/a> and the process used to change the computer account password can be disabled entirely<\/a>.<\/p>\n 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<\/a>. However, I didn’t cover the other angles which are explored in this article.<\/p>\n 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.<\/p>\n Common Examples of Computers in Groups:<\/p>\n <\/p>\n The obvious question is ‘what is the impact of a computer in a an admin group?’<\/p>\n 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.<\/p>\n <\/p>\n 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<\/a>\u00a0 to effectively take ownership of the computer account’s rights in AD. Mimikatz <\/a>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.<\/p>\n 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.<\/p>\n <\/p>\n 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.<\/p>\n 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.<\/p>\n Obviously a few items have to be in place for this to work:<\/p>\n 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.<\/p>\n Note that there are several other ways to take advantage of this and similar scenarios and this isn’t the only potential attack.<\/i><\/p>\n <\/p>\n If the attacker has dumped the Active Directory database or gained knowledge of a Domain Controller\u2019s 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<\/a>.<\/p>\n 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.<\/p>\n Computers host services as well with the most common one being the Windows file share which leverages the \u201ccifs\u201d service. Since the computer itself hosts this service, the password data required to create a Silver Ticket is the associated computer account\u2019s 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.<\/p>\n 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 \u201cprivilege::debug\u201d \u201csekurlsa::logonpasswords\u201d exit<\/a><\/em><\/p>\n Create a Silver Ticket for the DC to Connect to PowerShell Remoting on the Domain Controller with Admin Access<\/strong><\/p>\n Create a Silver Ticket for the \u201chttp<\/a>\u201d service and \u201cwsman<\/a>\u201d service to gain admin rights to WinRM and\/or PowerShell Remoting on the target system.<\/p>\n After injecting the two Silver Tickets, http <\/a>& wsman<\/a>, we can use PowerShell Remoting (or WinRM) to open a a shell to the target system (assuming it\u2019s 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.<\/p>\n Create a Silver Ticket for the \u201cldap<\/a>\u201d service to gain admin rights to LDAP services on the target system (including Active Directory).<\/p>\n Leveraging the LDAP Silver Ticket, we can use Mimikatz and run DCSync <\/a>to \u201creplicate\u201d credentials from the DC.<\/p>\n 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<\/a>.<\/p>\n This method is two-pronged:<\/p>\n 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.”<\/p>\n 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.<\/p>\n 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<\/a>.<\/p>\n <\/p>\n 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. 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.<\/p>\n Import-Module ActiveDirectory<\/p>\n $AdminGroupsWithComputersAsMembersCountHashTable\u00a0 = @{}<\/p>\n [array]$DomAdminGroups = get-adgroup -filter {Name -like “*admin*”} ForEach ($DomAdminGroupsItem in $DomAdminGroups) Write-Output “$DomainAdminGroupsWithComputersCount Forest Admin groups contain computer accounts” As always, this script is provided “as is.”<\/em><\/p>\n PowerView<\/a>, now integrated into PowerSploit<\/a>, includes capability to help identify computers in admin groups:<\/p>\n Get-NetGroup -AdminCount | Get-NetGroupMember -Recurse | ?{$_.MemberName -like ‘*$’}<\/em><\/p><\/blockquote>\n <\/p>\n The other mitigation is to ensure that all computer account passwords change every 30 \u2013 60 days, especially servers (Domain Controllers!).<\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n","protected":false},"excerpt":{"rendered":" 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 … <\/p>\n\n
Computers as Admins?<\/b><\/h3>\n
Computer accounts can have elevated rights to resources, including full admin rights to Active Directory.<\/i><\/h4>\n
How does the computer leverage these rights or access?<\/b><\/h3>\n
Privilege Escalation<\/b><\/h3>\n
\n
Exploitation & Persistence<\/b><\/h3>\n
Domain Controller Silver Ticket<\/strong><\/h4>\n
![\"Mimikatz-Sekurlsa-LogonPasswords\"](\"https:\/\/adsecurity.org\/wp-content\/uploads\/2015\/11\/Mimikatz-Sekurlsa-LogonPasswords1.png\")
<\/p>\n![\"SilverTicket-DC-HTTP\"](\"https:\/\/adsecurity.org\/wp-content\/uploads\/2015\/11\/SilverTicket-DC-HTTP.png\")
<\/a><\/p>\n![\"SilverTicket-DC-WSMAN\"](\"https:\/\/adsecurity.org\/wp-content\/uploads\/2015\/11\/SilverTicket-DC-WSMAN.png\")
<\/a><\/p>\n![\"PowerShell-Remoting-Connect-To-ADSDC02\"](\"https:\/\/adsecurity.org\/wp-content\/uploads\/2015\/11\/PowerShell-Remoting-Connect-To-ADSDC02.jpg\")
<\/a><\/p>\n![\"SilverTicket-DC-PSRemotingExploit2\"](\"https:\/\/adsecurity.org\/wp-content\/uploads\/2015\/11\/SilverTicket-DC-PSRemotingExploit2.png\")
<\/a><\/p>\n
\nCreate a\u00a0 Silver Ticket for the DC to Connect to LDAP on the Domain Controller with Admin Access and Run DCSYNC.
\n<\/strong><\/p>\n![\"SilverTicket-DC-LDAP\"](\"https:\/\/adsecurity.org\/wp-content\/uploads\/2015\/11\/SilverTicket-DC-LDAP.png\")
<\/a><\/p>\n![\"SilverTicket-DC-LDAP-Exploit-DCSync\"](\"https:\/\/adsecurity.org\/wp-content\/uploads\/2015\/11\/SilverTicket-DC-LDAP-Exploit-DCSync.png\")
<\/a><\/p>\nPersistence via Computer Account<\/strong><\/h4>\n
\n
![\"SneakyADPersistence-ADBackupsGroup-in-Administrators\"](\"https:\/\/adsecurity.org\/wp-content\/uploads\/2016\/03\/SneakyADPersistence-ADBackupsGroup-in-Administrators.jpg\")
<\/a><\/p>\n![\"SneakyADPersistence-ADBackupsGroup-in-Administrators-2\"](\"https:\/\/adsecurity.org\/wp-content\/uploads\/2016\/03\/SneakyADPersistence-ADBackupsGroup-in-Administrators-2.jpg\")
<\/a><\/p>\nMitigation<\/b><\/h3>\n
\nScanning 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’.<\/p>\n
\n[int]$DomAdminGroupsCount = $DomAdminGroups.Count
\nWrite-Output “Scanning the $DomAdminGroupsCount Admin Groups in $ForestDomainItem for computer accounts as members”<\/p>\n
\n{
\n[array]$GroupContainsComputerMembers = Get-ADGroupMember $DomAdminGroupsItem.DistinguishedName -Recursive | Where {$_.objectClass -eq ‘computer’} $AdminGroupsWithComputersAsMembersCountHashTable.Set_Item($DomAdminGroupsItem.DistinguishedName,$GroupContainsComputerMembers.Count)
\n[int]$DomainAdminGroupsWithComputersCount = $DomainAdminGroupsWithComputersCount + $GroupContainsComputerMembersCount
\n}<\/p>\n
\n$AdminGroupsWithComputersAsMembersCountHashTable<\/p><\/blockquote>\nResources<\/b><\/h3>\n
\n