Table of Contents
The Microsoft Best Practices for Securing Active Directory" is very clear and unambiguous about the risks of populating the built-in highly-privileged groups in AD (Enterprise Admins, Domain Admins, Built-in Administrators, Backup Operators, Server Operators, Account Operators, etc).
"Membership in the Enterprise Admins, Domain Admins, or Administrators groups in Active Directory is required only temporarily and infrequently in an environment that implements least-privilege approaches to daily administration."
"... a member of any of the three groups [EA, DA, BA] can manipulate the directory to gain membership in any of the other groups. In some cases, it is trivial to obtain membership in the other groups, while in others it is more difficult, but from the perspective of potential privilege, all three groups [EA, DA, BA] should be considered effectively equivalent."
"In a properly designed and implemented delegation model, Domain Admins membership should be required only in “break glass” scenarios (such as situations in which an account with high levels of privilege on every computer in the domain is needed)."
"EA membership is required only when first constructing the forest or when making certain forest-wide changes such as establishing an outbound forest trust."
However, there's a dearth of clear information on exactly how members of privileged groups can self-elevate, so as a thought experiment, here are the easiest methods I can think of for groups to self-elevate (or elevate others) using native always-available commands (default Windows Server 2012R2 forest/domain). That is, there's no downloading external scripts/executables/modules. And this covers elevation only; service disruption is a given, since almost all the privileged groups have rights to shut down domain controllers.
Windows 2016 default built-in admin groups:
Built-In Administrators (BA) elevate to Domain Admins (DA)
Note that Domain Admins get almost all rights by being members of the Built-In Administrators group. A member of the BA group simply adds the desired user to DA. Absolutely trivial.
Built-In Administrators (BA) elevate to Enterprise Admins (EA)
Note that Enterprise Admins get almost all rights by being members of the Built-In Administrators group, nested via membership in each domain's Domain Admins group
Server Operators elevate to EA/DA/BA
Server Operators can modify the properties of certain services. The Computer Browser ("browser") service is disabled by default and can easily be changed to run a command as System, which on DC's has permissions to modify the built-in administrative groups.
Here we see that Server Operators ("SO") can write all properties ("WP") for the browser service. Change the browser service properties to call "net group" instead.
Success: user added to "Enterprise Admins"
There are a number of other services that run as SYSTEM on DCs, that can be modified by the Server Operators, and Disabled are easiest to play with:
Like the Computer Browser service, try the NtFrs service (eg., run here as user "soonly" – a member of just the Server Operators group):
Account Operators elevate to privileged group via nested group
Account Operators have no permissions to modify the EA/DA/BA groups. However, if someone has been reckless enough to nest a group in a privileged group, Account Operators can still modify the nested group (by default). Suppose someone added the "HR" group as a member of the BA
Succeeds. The user is now a member of "HR" and by inclusion a member of BA.
In a stock Windows 2016 domain, Account Operators have no permissions to modify BA/DA/EA/SO/BO, but they do have permissions to modify, among others, the DNS Administrators group.
Backup Operators elevate to Administrators
The sole purpose of the BO group is to back up and restore domain controllers (or any part thereof), so that's what we'll do. Get the SID of the target user account:
As member of Backup Operators group, copy the Default Domain (or other applicable) GPO to a temporary location (e.g. your Desktop):
Edit or add the Restricted Groups values, adding the SID of your account to the desired group (e.g. "S-1-5-32-544" == "Built-In Administrators"):
Back the file up.
Restore the file and redirect it to the real SYSVOL location, overwriting the existing GPO.
Wait for GP refresh. Success.
I don't see an obvious way for a member of Print Operators to elevate on a native system, even considering they're allowed to load and unload device drivers. Who installs print drivers on domain controllers anyway???
The most reckless privilege escalation problem, of course, is allowing members of any of the privileged groups to browse the Internet under those accounts -- you're risking allowing the random Internet to trivially manipulate/hijack/destroy your AD.
"Users who log on to computers with accounts that are members of the local Administrators group on the computer, or members of privileged groups in Active Directory, and who then browse the Internet (or a compromised intranet) expose the local computer and the directory to
"If the user has administrative rights in the directory by membership in the Enterprise Admins, Domain Admins, or Administrators groups in Active Directory, the attacker can extract the domain credentials and use them to compromise the entire AD DS domain or forest, without needing to compromise any other computer in the forest."