This article is a cross-post from TrimarcSecurity.comOriginal article: https://www.trimarcsecurity.com/single-post/2019/02/12/Mitigating-Exchange-Permission-Paths-to-Domain-Admins-in-Active-Directory The Issue Recently a blog post was published by Dirk-jan Mollema titled “Abusing Exchange: One API call away from Domain Admin ” (https://dirkjanm.io/abusing-exchange-one-api-call-away-from-domain-admin/)which highlighted several issues with …
It’s been almost 1.5 years since the Medium post by Shay Ber was published that explained how to execute a DLL as SYSTEM on a Domain Controller provided the account is a member of DNSAdmins. …
At DerbyCon 8 (2018) over the weekend Will Schroeder (@Harmj0y), Lee Christensen (@Tifkin_), & Matt Nelson (@enigma0x3), spoke about the unintended risks of trusting AD. They cover a number of interesting persistence and privilege escalation …
I just uploaded the slides from my Black Hat & DEF CON talks from the past week in Vegas. They are a bit different with the BH talk more Blue (defensive) and the DC talk …
I recently presented my talk “Active Directory Security: The Journey” at Nolacon in New Orleans, LA. Slides are now posted here. On Sunday, May 19th, 2018, I spoke at NolaCon at 11am. Here’s the talk description: …
There are many ways an attacker can gain Domain Admin rights in Active Directory. This post is meant to describe some of the more popular ones in current use. The techniques described here “assume breach” where an attacker already has a foothold on an internal system and has gained domain user credentials (aka post-exploitation).
The unfortunate reality for most enterprises, is that it often does not take long from an attacker to go from domain user to domain admin. The question on defenders’ minds is “how does this happen?”.
The attack frequently starts with a spear-phishing email to one or more users enabling the attacker to get their code running on a computer inside the target network. Once the attacker has their code running inside the enterprise, the first step is performing reconnaissance to discover useful resources to escalate permissions, persist, and of course, plunder information (often the “crown jewels” of an organization).
While the overall process detail varies, the overall theme remains:
Malware Injection (Spear-Phish, Web Exploits, etc)
Reconnaissance (Internal)
Credential Theft
Exploitation & Privilege Escalation
Data Access & Exfiltration
Persistence (retaining access)
We start with the attacker having a foothold inside the enterprise, since this is often not difficult in modern networks. Furthermore, it is also typically not difficult for the attacker to escalate from having user rights on the workstation to having local administrator rights. This escalation can occur by either exploiting an unpatched privilege escalation vulnerability on the system or more frequently, finding local admin passwords in SYSVOL, such as Group Policy Preferences.
The past couple of years of meeting with customers is enlightening since every environment, though unique, often has the same issues. These issues often boil down to legacy management of the enterprise Microsoft platform going back a decade or more.
While the threats have changed over the past decade, the way systems and networks are managed often have not. We continue with the same operations and support paradigm despite the fact that internal systems are compromised regularly. We must embrace the new reality of “Assume Breach.”
Assume breach means that we must assume that an attacker has control of a computer on the internal network and can access the same resources the users who have recently logged on to that computer has access to. Note that when I describe risks and mitigations of Active Directory,this includes overall enterprise configuration.
Here are some of the biggest AD security issues (as I see them). This list is not complete, but reflects common enterprise issues.
I continue to find many of these issues when I perform Active Directory Security Assessments for organizations.
The Issue Recently a blog post was published by Dirk-jan Mollema titled “Abusing Exchange: One API call away from Domain Admin ” (https://dirkjanm.io/abusing-exchange-one-api-call-away-from-domain-admin/)which highlighted several issues with Exchange permissions and a chained attack which would likely result in a regular user with a mailbox being able to become a Domain Admin in the AD forest. Tools have been released to take advantage of this issue.
He highlights the key components of the issue in the blog post introduction:
This blog combines a few known vulnerabilities and known protocol weaknesses into a new attack. There are 3 components which are combined to escalate from any user with a mailbox to Domain Admin access:
* Exchange Servers have (too) high privileges by default * NTLM authentication is vulnerable to relay attacks * Exchange has a feature which makes it authenticate to an attacker with the computer account of the Exchange server … The main vulnerability here is that Exchange has high privileges in the Active Directory domain. The Exchange Windows Permissions group has WriteDacl access on the Domain object in Active Directory, which enables any member of this group to modify the domain privileges, among which is the privilege to perform DCSync operations. Users or computers with this privilege can perform synchronization operations that are normally used by Domain Controllers to replicate, which allows attackers to synchronize all the hashed passwords of users in the Active Directory.
Exchange Permissions in Active Directory
At the Microsoft Blue Hat in 2017, Sean Metcalf, Trimarc founder and Active Directory Subject Matter Expert (SME) highlighted issues with Exchange permissions. Some slides from this presentation are shown here as representative samples (the full presentation slide deck is in the Presentations section.
More information about this issue has been highlighted in presentations by Andy Robbins (@_wald0) and Will (@Harmj0y), including at Black Hat USA 2017.
The Bloodhound tool written by Andy Robbins, Rohan Vazarkar, and Will can identify attack paths involving Exchange permissions configured in Active Directory.
Microsoft recently published an article (https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV190007) on how to configure EWS throttling which will mitigate the issue(s) that Dirk-jan Mollema raised. The issue with this is that EWS throttling could negatively impact applications like Outlook for Mac and doesn’t resolve the escalation path with Exchange permissions configured in AD.
Some of the Exchange permissions discovered during Trimarc ADSAs:
Organization Management has Full Control (“GenericAll”) rights at the domain root.
Exchange Trusted Subsystem has Full Control (“GenericAll”) rights at the domain root.
Exchange Recipient Administrators has Full Control (“GenericAll”) rights at the domain root.
Exchange Windows Permissions has Modify Permissions (“WriteDACL”) rights at the domain root.
The last permission on the list is one that, if in place in an AD forest, will likely result in AD compromise. This right should not be required, so removing it from the domain root should have no negative impact on day to day operations. We recommend creating a new AD group (something like “Privileged Modify Domain Permissions”) and grant this right to that group. Add the Exchange Windows Permissions group to this new Privileged Modify Domain Permissions group when this right is required (should be rare).
PowerShell command to scan and report on the AD domain permissions (requires the AD PowerShell module):
# This is a sample script provided by Trimarc.
# No warranty or suitability of use is stated or implied.
# This script requires the Active Directory PowerShell module be installed and should be run by a user in the AD forest containing the target domain(s)
$ADDomain = ‘DOMAIN.COM’
$DomainRootPermissionsReportDir = ‘c:\temp’
$DomainRootPermissionsReportName = ‘DomainRootPermissionsReport.csv’
IF (!(Test-Path $DomainRootPermissionsReportDir))
{ new-item -type Directory -path $DomainRootPermissionsReportDir }
$DomainRootPermissionsReportPath = $DomainRootPermissionsReportDir + ‘\’ + $ADDomain + ‘-‘ +$DomainRootPermissionsReportName
$DomainTopLevelObjectDN = (Get-ADDomain $ADDomain).DistinguishedName
$DomainRootPermissions = Get-ADObject -Identity $DomainTopLevelObjectDN -Properties * | select -ExpandProperty nTSecurityDescriptor | select -ExpandProperty Access
$DomainRootPermissions | select IdentityReference,ActiveDirectoryRights,AccessControlType,IsInherited,InheritanceType,ObjectType,InheritedObjectType,ObjectFlags,InheritanceFlags,PropagationFlags `
| export-csv $DomainRootPermissionsReportPath -NoTypeInfo
$DomainRootPermissions | select IdentityReference,ActiveDirectoryRights,AccessControlType,IsInherited | sort ActiveDirectoryRights,IdentityReference
Write-Output ” ”
Write-Output “———————————————————————————————————————————— ”
Write-Output “| $ADDomain Domain Permission Report saved to $DomainRootPermissionsReportPath | ”
Write-Output “———————————————————————————————————————————— ”
Note that this script is provided as a sample and the domain name needs to be changed to correctly gather data.
In more recent versions of Exchange, extensive permissions at the domain level are typically not required.
Furthermore, Exchange permissions persist even when the only Exchange server remaining on-premises is for managing Office 365.
Mitigating The Active Directory Security Issues with Microsoft Exchange Permissions The references noted above highlight issues relating to Exchange permissions and often the mitigations are complicated and difficult to implement.
The goal of this article is to provide a stop gap option that mitigates Exchange permissions that have extensive rights in Active Directory with minimal day-to-day operational impact while organizations can implement a more permanent fix.
For those that are running Exchange on-prem in the Default Shared Permission model and it is not isolated in a dedicated resource forest you need to decide with a fair amount of criticality how you are going to address the permission issue regarding the Exchange Windows Permission group described in https://dirkjanm.io/abusing-exchange-one-api-call-away-from-domain-admin/.
The best method to mitigate the issue with Exchange having elevated AD permissions, and maybe more importantly the way that won’t get the “we don’t support that” answer from Microsoft, is to switch to Active Directory (AD) split permissions (Exchange) or isolate Exchange in its own resource forest (or both). The split permission model (https://docs.microsoft.com/en-us/exchange/understanding-split-permissions-exchange-2013-help) requires AD management tools for creating security principals in AD (such as users and security groups). Implementing the split permission model is not trivial once Exchange has been deployed, but does effectively limit Exchange rights in AD.
Microsoft notes the following functionality changes when enabling Active Directory split permissions:
Creation of mailboxes, mail-enabled users, distribution groups, and other security principals is removed from the Exchange management tools.
Adding and removing distribution group members can’t be done from the Exchange management tools.
All permissions granted to the Exchange Trusted Subsystem and Exchange servers to create security principals are removed.
Exchange servers and the Exchange management tools can only modify the Exchange attributes of existing security principals in Active Directory.
The key change this stop gap option implements is the removal of the Exchange Trusted Subsystem group from the Exchange Windows Permissions Group, with the work around of temporally restoring the default membership to get around any unforeseen issues.
So here’s what that looks like, note that this is just a general overview, this premise will need to be customized based on the nuances of your AD and Exchange environments.
Create a custom RBAC group with the same roles as the Organization Management group removing the requirement for administrators to have permanent membership in Organization Management. Call this group something like “<DOMAIN/FOREST_NAME> Exchange Organization Management” This can be easily be done using the RBAC cmdlets in Exchange Management Shell.
By default, the Organization Management group can modify group membership of the Exchange Trusted Subsystem, Exchange Windows Permissions, and other Exchange privileged groups in Active Directory.
Delegate more appropriate AD rights to the group created in step 2 (“<DOMAIN/FOREST_NAME> Exchange Organization Management”) at the appropriate OU level based on your AD OU design. Reference the link provided in Step 1.
Remove the Exchange Trusted Subsystem group from the Exchange Windows Permissions group and any other groups that are members of Exchange Windows Permissions group. This isolates Exchange from having AD permissions.
Ensure that only Exchange Servers are members in the Exchange Trusted Subsystem group.
Use the reference in step 1 to apply the permissions delegated to the Exchange Windows Permission group by default to the Exchange Trusted Subsystem group but this time at the appropriate OU level versus at the domain root.
Remove any membership from the Organization Management group.
Ensure that monitoring and alerting is configured for membership changes of the following groups: * Exchange Windows Permission * Exchange Trusted Subsystem * Organization Management
When the removed permissions are required, temporarily add the Exchange Trusted Subsystem group to the Exchange Windows Permissions group. Ensure that this group is removed when the required tasks are completed.
Ensure that you use groups instead of adding individual user or computer accounts directly in these permission groups as this should reduce the need to reboot computers and log off and then back on again.
Note that this configuration will break things and add some additional burden to the administration of Exchange but hopefully have little to no impact in the day to day use of Exchange by end users.
For example if you attempt to install a new Exchange Server in the environment you should get an error, but to get around this you can add the admin account that is installing the new Exchange server temporarily to the default Organization Management Group and temporarily add Exchange Trusted Subsystem group to the Exchange Windows Permission Group, this is the work around for anything this new configuration might break which should mostly be related to object creation in the domain partition in AD.
Also, if using the AD split permission model as an example as to what other things this premise might break, using the Add-ADpermission cmdlet to add permissions to a mailbox will probably break as well but should still work for receive connectors because mailbox objects are stored in the domain partition and receive connectors are stored in the configuration partition.
Also should you need to engage Microsoft support its easy enough to put yourself back into the “supported” configuration by simply giving the Exchange Trusted Subsystem group temporary membership to the Exchange Windows Permission Group.
This premise is not been fully tested out to see what all the unintended consequences in every environment might be but can be switched back to the supported configuration temporarily as a work around when something breaks.
It has to be emphasized again that this is only a stop gap meant to give organizations a possible short term option that can be implemented rather quickly while the correct fix or path is put in place for that organization.
UPDATE On February 12, 2019, Microsoft released patches that modifies Exchange Web Services Push Notifications to protect against the issue identified in Dirk-jan Mollema’s blog post and Microsoft also reduces the rights that Exchange has to Active Directory. This requires that the new version of setup.exe /PrepareAD is run.
Conclusion When Exchange was originally installed, it configures and grants itself extensive Active Directory permissions. These permissions provide necessary access that Exchange may ever need. The issue is that these permissions are overly permissive, especially when early versions of Exchange were deployed (since Exchange 2000/2003 added extensive permissions compared to current versions).
The Microsoft Exchange split permission model or deploying an Exchange resource forest are the best methods to mitigate attacks on AD through Exchange permissions, though these are not easy to deploy or configure (or retrofit). Trimarc has identified a method that switches the configuration from a permanent Exchange permissions model to one where the required permissions can be provided on a “when needed” (or just in time) basis.
It’s been almost 1.5 years since the Medium post by Shay Ber was published that explained how to execute a DLL as SYSTEM on a Domain Controller provided the account is a member of DNSAdmins.
I finally got around to posting here since many I speak with aren’t aware of this issue.
Shay describes this issue as follows (bolded text addedby me):
In addition to implementing their own DNS server, Microsoft has also implemented their own management protocol for that server, to allow for easy management and integration with Active Directory domains. By default, domain controllers are also DNS servers; DNS servers need to be reachable and usable by mostly every domain user. This, in turn, exposes quite some attack surface on domain controllers — on one part, the DNS protocol itself and on the other, the management protocol, which is based on RPC.
We will shallowly delve into the protocol’s implementation and detail a cute feature (certainly not a bug!) which allows us, under some circumstances, to run code as SYSTEM on domain controllers, without being a domain admin. Although this is certainly not a security vulnerability (so no panic is needed), as confirmed with Microsoft, it’s still a cute trick which can be useful as an AD privilege escalation in red team engagements.
So, how is this possible?
I will summarize Shay’s excellent technical review of this issue (this assumes DNS runs on Domain Controllers, which is the most common configuration).
At DerbyCon 8 (2018) over the weekend Will Schroeder (@Harmj0y), Lee Christensen (@Tifkin_), & Matt Nelson (@enigma0x3), spoke about the unintended risks of trusting AD. They cover a number of interesting persistence and privilege escalation methods, though one in particular caught my eye.
Overview
Lee figured out and presents a scenario where there’s an account with unconstrained delegation configured (which is fairly common) and the Print Spooler service running on a computer, you can get that computers credentials sent to the system with unconstrained delegation as a user.
I just uploaded the slides from my Black Hat & DEF CON talks from the past week in Vegas. They are a bit different with the BH talk more Blue (defensive) and the DC talk mostly Red (Offensive) in focus. Also note that the only real overlap in content is the MFA & password vault sections and those were updated in my DEF CON talk to focus on the attack aspect.
An important note: The methods I show are real and work well in many real-world customer deployments. The issues with MFA and password vaults I highlight are often deployment issues and not necessarily vendor best practices. With that noted, I have seen enterprise password vaults deployed with poor security so often that I don’t think customers are very familiar with the vendor security best practices.
Black Hat USA 2018 Talk: “From Workstation to Domain Admin: Why Secure Administration isn’t Secure and How to Fix it”
This talk walks the audience through how AD administration has evolved over time with newer, more “secure” methods and the potential ways to exploit modern AD administration. I explore some methods to exploit current implementation weaknesses in many deployments of multi-factor authentication (MFA) and enterprise password vaults. The latter third of the talk dives into the best defenses and how to employ and deploy them appropriately.
[Slides]
Black Hat Talk Agenda:
Current State
Evolution of Administration
Exploiting Typical Administration
Common Methods of Protecting Admins (& bypassing them)
MFA
Enterprise Password Vaults
Admin Forest
Building the Best Defenses
DEF CON 26 Talk: “Exploiting Active Directory Administrator Insecurities”
This talk repeats the slide concepts from my Black Hat talk specific to exploiting current implementation weaknesses in many deployments of multi-factor authentication (MFA) and enterprise password vaults. The talk adds in some challenges in properly discovering AD admins and some additional methods of exploiting current AD environments. I also cover how in many environments it may be possible to compromise a Read-Only Domain Controller to compromise the AD forest. This talk also includes a special, new sneaky AD persistence method which only the DEF CON audience was privy to (not in the slides, at least not directly). I will post a blog article as time allows. 🙂
[Slides]
DEF CON Talk Agenda:
Evolution of Admin Discovery
Exploiting Typical Administration
Multi-Factor Authentication (MFA)
Password Vaults
Admin Forest
Attacking RODCs
Thank you all for your support and your kind words!
– Sean
On Sunday, May 19th, 2018, I spoke at NolaCon at 11am.
Here’s the talk description:
Active Directory is only the beginning. Attackers have set their sights squarely on Active Directory when targeting a company, though this typically isn’t the primary objective. The motivation and end goals range from stealing data to impacting corporate operations. In this regard, gaining control of Active Directory is a means to an end; compromising Active Directory is an easy way to gain access to all critical corporate resources. Effectively protecting Active Directory has become critical in limiting the impact of a breach.
This talk takes the audience on a journey covering the various security milestones and challenges with Active Directory. A variety of AD security posture are highlighted along with the challenges they encounter with securing their systems. Key elements involve how enterprise “”AD aware”” applications can weaken Active Directory security and how leveraging cloud services complicate securing infrastructure. Also explored is what an attacker can do in an environment without having Domain Admin rights.
This talk covers the critical issues affecting organizations today, as well as the biggest challenges; current attack techniques; and the most effective defensive techniques to prevent and mitigate compromise (including limitations to these approaches).
I have been fascinated with Read-Only Domain Controllers (RODCs) since RODC was released as a new DC promotion option with Windows Server 2008. Microsoft customers wanted a DC that wasn’t really a DC. – something that could be deployed in a location that’s not physically secure and still be able to authenticate users.
This post covers a few different scenarios on how to attack Read-Only Domain Controllers in order to escalate privilege. Since RODCs are typically untrusted and viewed as not having the same level of access as writable DCs, it’s possible in many environments to compromise a RODC to escalate privileges. Given certain scenarios, it’s possible to escalate from a Read-Only Domain Controller to a full writable Domain Controller. This post covers these scenarios and enables Red and Blue teams to better understand and check RODC configurations for issues.
The information in this post is not from any one customer environment I have seen, but a combination of several. I have found that many AD domains that have RODCs are configured very similarly: many more accounts, both user and computer, have passwords cached on RODCs than is necessary and the ability to manage RODCs is not limited or secured appropriately. This post shows what is possible given common real world RODC deployment configuration. As part of our Active Directory security review services, we scrutinize RODC configuration and identify potential issues with the configuration. Furthermore, we find that when RODCs are deployed in an environment, they are frequently configured with weak security settings (as noted in “RODCs in the Real World” and “Attacking RODCs” below).
The information here describes what is possible in many Active Directory environments with Read-Only Domain Controllers and doesn’t highlight a misconfiguration, but common configuration issues that could be exploited to escalate privileges in the domain since the RODC is often treated as “just another server” (or worse, as a workstation). Accounts are regularly cached on RODCs (since RODCs that don’t cache passwords aren’t very useful) and once an attacker gains access to it, these passwords are available and may include delegated Active Directory admin accounts which could be compromised.
If you want to simply know how best to “harden Read-Only Domain Controllers”, skip to the end to read the “Securing RODCs Against Attack” section.
Note that throughout this post, I use the Microsoft Active Directory PowerShell cmdlets and some of the attribute names are adjusted in the output from what they are actually named in AD.
Enter the Read-Only Domain Controller
When Microsoft released Windows Server 2008, a new type of Domain Controller was added called the “Read-Only Domain Controller”. The Read-Only Domain Controller (RODC) performs similar services as a writable Domain Controller except they are “read-only”. But what does that really mean?
Many organizations are moving to the cloud and this often requires some level of federation. Federation, put simply, extends authentication from one system (or organization) to another.
One of the key items we covered was protecting Federation Servers, specifically Microsoft Active Directory Federation Servers (ADFS).
Microsoft is currently updating guidance for securing ADFS.
This post describes key ADFS concepts and a short-list of security recommendations on how to properly protect ADFS.
Federation Overview
The federation server typically lives on the internal network with a proxy server in the DMZ. There are certificates installed on the Federation server.
ADFS uses the following certificates:
Service communication
Token-decrypting
Token-signing
ADFS terminology also includes:
Relying party trusts: cloud services and applications
Claim rules: determine what type of access and from where access is allowed.
Key Federation Points:
Federation: trust between organizations leveraging PKI (certificates matter)
Cloud SSO often leverages temporary or persistent browser cookies (cookies provide access)
Several protocols may be supported, though typically SAML. (protocols and versions matter)
Federation server (or proxy) is on public internet via port 443 (HTTPS).
Microsoft provided several Active Directory PowerShell cmdlets with Windows Server 2008 R2 (and newer) which greatly simplify tasks which previously required putting together lengthy lines of code involving ADSI.
Note that with PowerShell version 3 and newer, you don’t need to run the first line since Powershell will identify the necessary module and auto load it.
Once you have the Active Directory PowerShell module loaded, you can do cool stuff like browse AD like a file system
Finding Useful Commands (Cmdlets):
Discover available PowerShell modules: Get-Module -ListAvailable
Discover cmdlets in a PowerShell module: Get-Command -module ActiveDirectory
PowerShell AD Module Cmdlets:
Windows Server 2008 R2: 76 cmdlets
Windows Server 2012: 135 cmdlets
Windows Server 2012 R2: 147 cmdlets
Windows Server 2016: 147 cmdlets
(Get-Command -module ActiveDirectory).count
Finding Active Directory Flexible Master Single Operation (FSMO) Roles:
This post provides information on how Active Directory is typically administered and the associated roles & rights.
Domain Admins is the AD group that most people think of when discussing Active Directory administration. This group has full admin rights by default on all domain-joined servers and workstations, Domain Controllers, and Active Directory. It gains admin rights on domain-joined computers since when these systems are joined to AD, the Domain Admins group is added to the computer’s Administrators group.
Enterprise Admins is a group in the forest root domain that has full AD rights to every domain in the AD forest. It is granted this right through membership in the Administrators group in every domain in the forest.
Administrators in the AD domain, is the group that has default admin rights to Active Directory and Domain Controllers and provides these rights to Domain Admins and Enterprise Admins, as well as any other members.
Schema Admins is a group in the forest root domain that has the ability to modify the Active Directory forest schema.
Since the Administrators group is the domain group that provides full rights to AD and Domain Controllers, it’s important to monitor this group’s membership (including all nested groups). The Active Directory PowerShell cmdlet “Get-ADGroupMember” can provide group membership information.
Default groups in Active Directory often have extensive rights – many more than typically required. For this reason, we don’t recommend using these groups for delegation. Where possible, perform custom delegation to ensure the principle of least privilege is followed. The following groups should have a “DC” prefix added to them since the scope applies to Domain Controllers by default. Furthermore, they have elevated rights on Domain Controllers and should be considered effectively Domain Controller admins.
Backup Operatorsis granted the ability to logon to, shut down, and perform backup/restore operations on Domain Controllers (assigned via the Default Domain Controllers Policy GPO). This group cannot directly modify AD admin groups, though associated privileges provides a path for escalation to AD admin. Backup Operators have the ability to schedule tasks which may provide an escalation path. They also are able to clear the event logs on Domain Controllers.
Print Operators is granted the ability to manage printers and load/unload device drivers on Domain Controllers as well as manage printer objects in Active Directory. By default, this group can logon to Domain Controllers and shut them down. This group cannot directly modify AD admin groups.
Server Operators is granted the ability to logon to, shut down, and perform backup/restore operations on Domain Controllers (assigned via the Default Domain Controllers Policy GPO). This group cannot directly modify AD admin groups, though associated privileges provides a path for escalation to AD admin.
To a lesser extend, we’ll group Remote Desktop Users into this category as well.
Remote Desktop Users is a domain group designed to easily provide remote access to systems. In many AD domains, this group is added to the “Allow log on through Terminal Services” right in the Default Domain Controllers Policy GPO providing potential remote logon capability to DCs.
We also see that many times the following is configured via GPO linked to the Domain Controllers OU:
Remote Desktop Users: often granted “Allow log on through Terminal Services” right via Group Policy linked to the Domain Controllers OU.
Server Operators: granted “Allow log on through Terminal Services” right via Group Policy linked to the Domain Controllers OU.
Server Operators: granted “Log on as a batch job” right via GPO providing the ability to schedule tasks.
Review the GPOs linked to the Domain and the Domain Controllers OU and ensure the GPO settings are appropriate.
We often find that a servers GPO is also linked to the Domain Controllers OU and it adds a “Server Admins” group to the local Administrators group. Since Domain Controllers don’t have a “local” Administrators group, the DC updates the domain Administrators group by adding Server Admins. This scenario makes all members of Server Admins Active Directory admins.
Any group/account granted logon locally rights to Domain Controllers should be scrutinized.
Server Operators & Backup Operators have elevated rights on Domain Controllers and should be monitored. The Active Directory PowerShell cmdlet “Get-ADGroupMember” can provide group membership information.
Active Directory Recon is the new hotness since attackers, Red Teamers, and penetration testers have realized that control of Active Directory provides power over the organization.
This post details how privileged access is delegated in Active Directory and how best to discover who has what rights and permissions in AD. When we perform an Active Directory Security Assessment for customers, we review all of the data points listed in this post, including the privileged groups and the rights associated with them by fully interrogating Active Directory and mapping the associated permissions to rights and associating these rights to the appropriate groups (or accounts).
I have had this post in draft for a while and with Bloodhound now supporting AD ACLs (nice work Will @harmj0y & Andy @_Wald0!), it’s time to get more information out about AD permissions. Examples in this post use the PowerView PowerShell cmdlets.
The key point often missed is that rights to Active Directory and key resources is more than just group membership, it is the combined rights the user has which is made up of:
Active Directory group membership.
AD groups with privileged rights on computers
Delegated rights to AD objects by modifying the default permissions (for security principals, both direct and indirect).
Rights assigned to SIDs in SIDHistory to AD objects.
Delegated rights to Group Policy Objects.
User Rights Assignments configured on workstations, servers, and Domain Controllers via Group Policy (or Local Policy) defines elevated rights and permissions on these systems.
Local group membership on a computer or computers (similar to GPO assigned settings).