Using builtin groups is a practice often used by organizations using Microsoft's Active Directory. One of these groups, the Account Operators, is commonly used for basic user administration. As an organization grows the dangers of using this group grows. If the use of the account operators continues without review and governance, security gaps are added to the organization.
Upon completion of Active Directory Gap Analyses, I've notice businesses often use Account Operators as the easy way to delegate the management of users and groups. When there is a need for a non technical person to manage groups, the person often gets added to this group. Once added to the group he or she then has access to manage users and groups across the domain.
I'm going to demonstrate a few scenarios where attackers exploit permissions once they gain control of an account that's a member of this group.
The Account Operators group has extensive permissions across the domain. The group has every right described in my other post, "Who needs an administrator account?". They also have access to all the users, groups, permissions outlined here (schema post)
I'll journey through a few of the permissions listed in the previous articles. I'll demonstrate just how quick, and simple it is for an attacker to jump through the directory once they control this group. It's important to note that attackers aren't always after full Domain Administrative control, and sometimes are only after information on servers or workstations.
Scenario 1: Privilege escalation through "change user passwords."
This is the typical scenario Microsoft described with the lateral movement attacks. The attacker steps consist of:
- Dump acl and computer permissions on a domain. (Bloodhound or acldump)
- Find a workstation or server to target for an attack.
- Change password of a user with access to the targeted computer.
- Rdp to be computer with the new compromised account
- Dump credentials on computer.
- Continue further lateral movement
Scenario 2: Self escalation of privileges
- Find computer to target.
- Find the administrative group that can administer the computer.
- Add self to administrator group identified.
- Account now has admin access to rdp or smb or any other Administrative function in the computer
Scenario 3: Change owner on a Group - Persistent attack:
- Attacker finds a target group.
- The attacker changes the security on the group so that their account is the "owner."
- The attacker sits and waits.
- When the opportune time comes, Saturday 2:45a.m., the attacker escalates privileges on their account by adding their account to the group.
- The attacker gets the information they want
- Attacker removes their account from the group
- The attacker again sits and waits to remain hidden.
Lesser known paths
Scenario 4: LAPS exploitation and full ownership of all computers.
I.e. full local admin access to all machines on the domain
- Account Operators has control of all attributes on "user" class objects
- "Computer" class object is a sub class of user - see account operators and classes post
- Laps attribute is mapped onto computer objects.
- Attacker has inherited rights to LAPS and all computers on the domain
Scenario 5: Allow log on locally to domain controllers. i.e. a default AD GPO configuration
- Attacker finds a hypervisor admin account
- Attacker logs into hypervisor
- Attacker locates a domain controller running on a hypervisor.
- Attacker uses the compromised account operator account to log into the domain controller.
Sean Metcalf has a fantasic presentation on the GPO exploitation. This video starts at 30:15, right where the Account Operators and GPO permissions are listed.
These five scenarios demonstrate why the Microsoft recommendation for Account Operators is to "Leave it empty." I've written a script, Github Account Operators Cleanup, to empty the account operators group and the full guide will be available shortly.
For the full ESAE series, please begin with: What is Microsoft ESAE
For further reading on the admin account series, please visit the following links:
Privileged Group Posts:
Microsoft documentation on Account operators:
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 those of users, local groups, and global groups, and members can log in locally to domain controllers.
Members of the Account Operators group cannot 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 cannot modify user rights.
The Account Operators group applies to versions of the Windows Server operating system listed in the Active Directory Default Security Groups table.
Note By default, this built-in group has no members, and it can create and manage users and groups in the domain, including its own membership and that of the Server Operators group. This group is considered a service administrator group because it can modify Server Operators, which in turn can modify domain controller settings. As a best practice, leave the membership of this group empty, and do not use it for any delegated administration. This group cannot be renamed, deleted, or moved.
This security group has not changed since Windows Server 2008.
CN=BuiltIn, DC=<domain>, DC=
Default member of
Protected by ADMINSDHOLDER?
Safe to move out of default container?
Cannot be moved
Safe to delegate management of this group to non-Service admins?
Default User Rights
Allow log on locally: SeInteractiveLogonRight
Microsoft documentation #2 https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-b--privileged-accounts-and-groups-in-active-directory
Members can administer domain user and group accounts.