Group Managed Service Accounts (GMSAs) User accounts created to be used as service accounts rarely have their password changed. Group Managed Service Accounts (GMSAs) provide a better approach (starting in the Windows 2012 timeframe). The …
At BSides Northern Virginia (BSides NoVa) in October 2025, I presented a talk on how to improve Entra ID security quickly. This post captures the key information from my talk slides. This article describes the …
My BSides NoVA talk on Saturday, October 11, 2025 was titled “10 Ways to Improve Entra ID Security Quickly“. I focused on the areas that tend to be missed in Entra ID.Talk slides are now …
Review the membership of groups for accounts and groups from another Active Directory forest (technically another domain, but using forest here). These are called “Foreign Security Principals” (FSPs) like the ones highlighted in the image. …
A critical part of Active Directory security is regularly reviewing your AD admins. The simplest way to do this is to recursively enumerate the membership of the domain Administrators group (that group’s members and all member group members).
Check the AD Admins output for the following:
Are all the admin accounts associated with people expected?
Are there service accounts that shouldn’t require AD admin rights (VMware, Exchange, LDAP, VPN, Sharepoint, etc.)?
Are the associated passwords current?
Are they as expected with no outliers (all within 2 years but one has a password that’s 10 years old)?
Has the default domain Administrator account logged on recently?
Is that expected/known?
Are all accounts enabled?
Disabled accounts should be removed from being an AD Admin.
Do all accounts require Kerberos preauthentication?
They must if they are AD admins.
Do any use Kerberos DES?
If so fix that.
Are any set to never expire their password?
Is that expected?
Accounts with this set rarely change their password.
Are there any passwords in Active Directory user attributes (commonly description notes/info, Exchange custom attributes, etc.)?
Practically all of the attributes are visible to users.
This article was originally posted on the Trimarc Content Hub on August 6, 2020. Updated here with authentication PowerShell code on August 18, 2025. ADSecurity.org is the new home for this article and all updates will occur here.
I have had the idea for a post describing how to best create a honeypot (or honeytoken) account for many years and only recently gained enough clarity around how to format and structure such an article for it to be useful. Shout-out to Carlos Perez (@Carlos_Perez) for a recent chat about Kerberoasting and the Detecting Kerberoast article I posted a while back which got me thinking enough about this to start writing.
This article covers how to create accounts used as honeypots (or honeytokens) that look like they provide something an attacker wants (access), but ultimately provides something the defender wants (detection). The focus is making honeypot accounts look normal and “real” in Active Directory and this premise should be somewhat portable to other systems.
AD Recon 101 I have previously covered AD recon in presentations (DEF CON 2016: Beyond the MCSE, Red-Teaming Active Directory), but provide expanded detail here focused on privileged AD account recon. When an attacker is performing reconnaissance of Active Directory, there are a few key items to review:
Identify Privileged Accounts
Identify Privileged Accounts with Old Passwords
Identify Privileged Accounts with Kerberos Service Principal Names (SPNs)
Identify Privileged Accounts with Network Sessions on Regular Workstations
In most Active Directory environments, we can scan the AD forest for all of these as a regular AD user (and in some cases without valid AD credentials).
1. Identify Privileged Accounts
Let’s start with #1. We can either recursively enumerate the Administrators group in every domain in the AD forest or we can scan all AD user accounts in each domain that have the user attribute “AdminCount” set to 1. I presented about how useful the AdminCount attribute can be in 2015 (DerbyCon – “Red vs Blue Active Directory Attack & Defense”).
The AdminCount attribute is automatically set to 1 on any AD accounts that are added to privileged AD groups such as Administrators, Domain Admins, Enterprise Admins, etc. The limiting factor in the usefulness of this technique is that we may also find accounts that used to be in a privileged AD group but no longer a member. This means that scanning for AD accounts with AdminCount=1 provides a quick list of potentially privileged accounts (without group enumeration).
A common method attackers leverage as well as many penetration testers and Red Teamers is called “password spraying”. Password spraying is interesting because it’s automated password guessing. This automated password guessing against all users typically avoids account lockout since the logon attempts with a specific password are performed against against every user and not one specific one which is what account lockout was designed to defeat. The attacker starts with a list list of passwords they’re going to try which starts with the most likely passwords (“Fall2017”, “Winter2018”, etc).
When password spraying begins, we start with the first password in the list. That first password is used in an attempt to authenticate as every user in Active Directory. This one password is attempted against each AD user and once all users have been tested with that password, we move on to the next one.
Since the Active Directory user lockout threshold is 5, we can try 4 different passwords for every user. Then we wait for >30 minutes (lockoutobservationwindow where the DCs keep the lockout count, after this it resets to 0), and try again. It’s trivial to gather the information about the AD environment’s password policy and have the password spraying tool automatically adjust to them.
Graphic shows the Domain Password Policy for the lab domain environment using the AD PowerShell cmdlet Get-ADDefaultDomainPasswordPolicy cmdlet.
This works most of the time because users have bad passwords (especially if the password policy includes a password minimum of <10 characters). Often password spraying connects to an SMB share or a network service, so let’s start with connections to the PDC’s netlogon share (\\PDC\NETLOGON) which is common on many networks. After password spraying has run for a while, we have discovered many user passwords, which may also include privileged accounts.
In early 2020, I published an article on how a Global Administrator could gain control of Azure resources, that no one would know about it, and how this access would persist even after removing them from Global Administrator.
From that article:
“While Azure leverages Azure Active Directory for some things, Azure AD roles don’t directly affect Azure (or Azure RBAC) typically. This article details a known configuration (at least to those who have dug into Azure AD configuration options) where it’s possible for a Global Administrator (aka Company Administrator) in Azure Active Directory to gain control of Azure through a tenant option. This is “by design” as a “break-glass” (emergency) option that can be used to (re)gain Azure admin rights if such access is lost. In this post I explore the danger associated with this option how it is currently configured (as of May 2020). The key takeaway here is that if you don’t carefully protect and control Global Administrator role membership and associated accounts, you could lose positive control of systems hosted in all Azure subscriptions as well as Office 365 service data.”
Elevated Access
There is a switch that can be flipped from “No” to “Yes” that allows a Global Administrator to gain “manage access to all Azure subscriptions and management groups in this directory”. Flipping this switch to Yes adds the current user to the Azure role User Access Administrator at the root level. Once this access is provided, the current user can then add themself to other roles like Subscription Admin. The graphic below shows this flow.
Jake Karnes (@jakekarnes42) with NetSPI published 3 articles (that’s right 3!) describing a new attack against Microsoft’s Kerberos implementation in Active Directory. He posted an Overview article, describing how the attack works, an Attack article on practical exploitation, and if you need further background on Kerberos, a Theory article.
This article attempts to summarize the key details of the attack and provide some expanded information and potential attack scenarios, including how Active Directory could be compromised leveraging this attack method.
Kerberos Bronze Bit Attack TLDR:
If an attacker is able to gain knowledge of a service account’s password hash (which has constrained delegation or resource-based constrained delegation configured), this exploit enables the attacker to impersonate any user (even those protected from delegation with Protected Users or “account is sensitive and cannot be delegated”) when connecting to a service the service account is allowed to delegate to.
The Kerberos Bronze Bit Attack exploit has been incorporated into the Impacket framework already, so attackers are able to perform this attack today. And patching this issue is not as simple as just installing the patch on all Domain Controllers (more on that in the next section).
An attacker can impersonate users which are not allowed to be delegated. This includes members of the Protected Users group and any other users explicitly configured as “sensitive and cannot be delegated.”
An attacker can launch the attack from a service which is not allowed to perform the authentication protocol transition. This means that if the service is configured without the “TrustedToAuthForDelegation” property (shown as “Trust this user for delegation to specified services only – Use Kerberos only” in the AD GUI), the attacker can use the exploit to obtain tickets as if the “TrustedToAuthForDelegation” property were set (shown as “Trust this user for delegation to specified services only – Use any authentication protocol” in the AD GUI).
Detail item #1 above notes that even when AD accounts are explicitly protected from delegation attacks, the Bronze Bit Attack can still effectively target and impersonate them. This is a big deal since the best mitigation for Kerberos Delegation attacks has been configuring admin accounts to not allow delegation, either by adding to the Protected Users group or setting the “account is sensitive and cannot be delegated” as shown in the screenshot below.
We can easily identify accounts configured to protect against Kerberos delegation attacks using PowerShell.
Detail item #2 is probably the most interesting part of this attack. But before describing why, let’s take a moment to review Kerberos Delegation and how it works.
Kerberos Delegation Types:
Unconstrained: Impersonate users connecting to service to ANY Kerberos service.
Constrained: Impersonate authenticated users connecting to service to SPECIFIC Kerberos services on servers.
Constrained with Protocol Transition: Impersonate any user (without prior authentication) to SPECIFIC Kerberos services on servers.
Resource-based Constrained Delegation: Enables delegation configured on the resource instead of the account.
Kerberos Delegation has two primary options: Kerberos Unconstrained Delegation (KUD) and Kerberos Constrained Delegation (KCD). I spoke and blogged about the dangers of Kerberos Unconstrained Delegation in 2015 (at BlackHat & DEFCON).
Unconstrained delegation means that the account configured with this type of delegation can effectively impersonate a user who has authenticated to the service to any Kerberos service in the AD forest (and potentially in other forests as well). Compromising an account with unconstrained delegation means effectively compromise of all accounts that have authenticated to its associated service.
Constrained delegation means that the account configured with this type of delegation can impersonate a user who has authenticated to the service to specifically defined server services as defined in the constrained delegation settings on that account. In the screenshot below, the computer account is allowed to impersonate users only when connecting to the MSSQLSvc service on the computer ADSDB01.lab.adsecurity.org on port 1433 (this is related to the Kerberos Service Principal Name (SPN) associated with this service on the computer account). The account allowed to delegate will not be able to get delegation tickets to impersonate users to other services on the network.
Kerberos Constrained Delegation (Kerberos Only)
There are 2 options when configuring Kerberos Delegation: 1) Kerberos authentication only (S4U2proxy) and 2) Use any authentication protocol (S4U2self aka “Protocol Transition”).
The Kerberos only setting is the most common that Trimarc sees in customer environments and this means that when a user authenticates to the service account (typically on a web server) that is configured for constrained delegation, the service account requests a delegation ticket from a Domain Controller to the service it needs to impersonate the user and connect to (typically a database server). If you take anything away from this paragraph it should be this: Constrained delegation with Kerberos authentication means that the user must authenticate to the service (service account) first. Then the service requests & receives a delegation ticket for that user.
Kerberos Constrained Delegation (Kerberos Only)
A delegation ticket provides the ability for the service account (configured to allow Kerberos delegation) to connect to the services on servers (specified in the Kerberos constrained delegation setting on the account) as the user. This is why I refer to Kerberos delegation as impersonation.
What makes the Kerberos Bronze Bit Attack so interesting and effective is that it can ignore this constrained Kerberos delegation setting (Kerberos Only) and leverage the 2nd method which is “use any authentication protocol” to get a Kerberos delegation ticket for any AD user with no prior authentication.
The constrained delegation setting “Use any authentication protocol” enables the service account to get a delegation ticket from a Domain Controller for any AD user simply by asking for it. I call this “Kerberos Magic”.
Kerberos Constrained Delegation (Use any authentication protocol)
This setting was implemented to support scenarios where a user authenticates to a service with a method that cannot easily be provided to a Domain Controller to prove authentication such as client certificate authentication. This means that the service does not need to prove prior authentication to get a delegation ticket for the user it is requesting, and the Domain Controller provides it. That’s why I call this “Kerberos Magic”. The service account can effectively create delegation tickets.
At SparkCon 2017, I presented on how to discover Kerberos Delegation:
Here’s the PowerShell code for Kerberos Delegation discovery:
Domain Controllers, including Read-Only Domain Controllers, running any Windows version are affected.
Microsoft released a patch on December 8, 2020 to fix this issue. However, the patch only provides the ability to change Microsoft Kerberos behavior on Domain Controllers and doesn’t implement these changes without setting a registry key (HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Kdc\PerformTicketSignature to 2 for Enforcement). Microsoft recommends not setting the registry key to enable enforcement until at least 7 days after installing the patch (and the patch has other patches as pre-requisites).
Deploying the December 2020 patch to all Domain Controllers provides capability for the PerformTicketSignature registry key to be created and set to “1” which is “Deployment” mode. The key has to be manually added – Microsoft notes “Adds support for the PerformTicketSignature registry value to enable protection on Active Directory domain controller servers. By default, this value does not exist”. This supports ticket signatures (which require SHA-2 support via previous patch), though tickets don’t need to be signed. In Deployment mode, new tickets are marked as non-renewable which means they expire at the end of the ticket lifetime (7 days by default) and new tickets need to be requested. According to Microsoft once the February 2021 patch is installed, “the PerformTicketSignature registry key settings will be ignored and Enforcement mode cannot be overridden.”
Enforcement mode (PerformTicketSignature set to “2”) sets all tickets as renewable again and requires Kerberos service tickets have signatures. All tickets must be signed to be considered valid.
If the PerformTicketSignature is set to “0” then Kerberos ticket signatures are disabled. Microsoft does not recommend this setting, though it’s an option. Don’t do this.
This registry key is planned to be set to “Enforcement” in the February 2021 patch cycle.
This means that Domain Controllers will likely be vulnerable in most Active Directory environments until February 2021 (and possibly longer if Microsoft delays the patch that configures enforcement).
In order for Domain Controllers running Windows Server 2008 or Windows Server 2008 R2 to get this security update, the customer must have Extended Support Updates (ESU) as an additional license option. If the ESU key is not installed on the servers, the update will not install.
There really is no reason to continue to run Windows Server 2008/2008R2 on Domain Controllers, so updating the OS to a supported version is required if you don’t have ESU.
The Attack Scenario: Attacking InGen
The articles linked in the Introduction section above describe the attack. In this article, I create a scenario where the attacker targets the fictional company: InGen Technology.
InGen has a web application, “DinoDNA”, with access restricted to dinosaur lab researchers only. The back-end database for DinoDNA is hosted in InGen’s SQL database farm which is managed by the InGen Database Administrator team (Active Directory group “InGen DB Admins”). While InGen is great at cloning creatures from >60 million years ago, they aren’t so great at securing elements of their systems, despite “sparing no expense”. The DinoDNA service account is “svc_DinoDNA@ingentech.co” and it has a Kerberos Service Principal Name (SPN) set to “DINO/dinoweb.ingentech.co”. In order for users to authenticate to the DinoDNA application and have updates to the back-end SQL database show as being updated by the users (and not the DinoDNA account), Kerberos Delegation is configured. Kerberos Delegation is effectively impersonation and is a setting on an Active Directory user/computer account to provide the ability to impersonate users.
In this scenario, the svc_DinoDNA service account is configured with Constrained Delegation allowing it to impersonate users who authenticate to the service to then impersonate users when the DinoDNA needs to connect to the SQL DB on the SQL server farm (Constrained Delegation configured to allow delegation/impersonation from the svc_DinoDNA service account to MSSQLSvc on SQLDB01, SQLDB02, SQLDB03, & SQLDB04)
An attacker was able to get a foothold in the system by phishing users and tricking them into opening a malicious document. With this initial access, the attacker scanned the Active Directory environment and discovered the svc_DinoDNA service account. After performing some additional reconnaissance, the attacker realizes that gaining access to the DinoDNA application would provide access to proprietary data containing dinosaur DNA and core cloning functions. The attacker performs a Kerberoast attack against the svc_DinoDNA service account and is able to crack the password fairly easily since it is a common keyboard combination (“1qaz@wsx”) often referred to “Password Walking”. With this password identified, the attacker creates the associated password hash and leverages this in combination with the Kerberos Bronze Bit attack in order to get a valid service ticket to the DinoDNA SQL database as a SQL Admin account (dnedry-dba who is a member of the InGen DB Admins group). With this valid service ticket, the attacker is able to access the DinoDNA SQL database with full admin rights.
Attack Summary:
Attacker has a foothold in the InGen corporate network.
Attacker gains knowledge of the password hash for the DinoDNA service account by kerberoasting the account.
The DinoDNA service account is configured with constrained delegation in order to allow the DinoDNA webserver to impersonate users when connecting to the back-end SQL database that stores the DinoDNA application data.
The attacker targets one of the SQL database admins (dnedry-dba) in the AD environment for this attack, even if they are a member of the “Protected Users” group or has “Account is sensitive and cannot be delegated” set. These protections are bypassed by this attack, so are irrelevant to the attacker.
Attack code leverages S4U2self and S4U2proxy protocols to obtain a service ticket to SQL for the dnedry-dba account using the service account’s password hash.
The attack code then flips the “Forwardable bit to 1 on the service ticket.
This modified service ticket is used in the S4U2proxy protocol to get a service ticket for the SQL service on one of the SQL database servers as the dnedry-dba account.
With this final, valid service ticket, the attacker can access the SQL database as dnedry-dba.
Jake Karnes notes in his published article that the attack is possible because the forwardable flag is only protected by the ticket encryption which uses the service account’s password hash. Knowledge of this enables flipping this bit value.
Leveraging the Bronze Bit Attack to Compromise Active Directory
While discussing the Bronze Bit Attack within Trimarc, we were talking about worse case scenarios. Compromising Active Directory with this attack definitely falls under worse case scenario. Trimarc has identified the following configuration in about 5% of customer Active Directory Security Assessments (ADSAs), so this is not a hypothetical scenario.
Kerberos Delegation configuration on Active Directory accounts is limited to Domain Admins by default; however, the right to set Kerberos Delegation on AD accounts can be delegated. This requires setting the User Right Assignment “Enable computer and user accounts to be trusted for delegation”. Additionally, the account that receives this right also requires write access to “account control flags” on the targeted account.
Continuing the InGen fictional story, they have an Active Directory environment where the InGen AD Admins have delegated the User Right Assignment “Enable computer and user accounts to be trusted for delegation” to the AD group “InGen Server Admins”. This group also has Full Control (GenericAll) rights on the “Enterprise Applications” OU. With this combination of rights, any member of the InGen Server Admins group can configure Kerberos Delegation on any account in the Enterprise Applications OU. The attacker identifies that there are several user accounts in the “InGen Server Admins” group and spearphishes them and this attack is successful for one of them. The attacker then creates a new account in the Enterprise Applications OU or modifies an existing account. Either way, the attacker configures the LDAP service on a Domain Controller as an additional allowed configuration for Kerberos Constrained Delegation on the account. Once this is set, the attacker leverages the Kerberos Bronze Bit attack to impersonate a Domain Admin in a service ticket valid for the LDAP service on a DC. Once the attacker gets the valid Kerberos service ticket, they are able to run Mimikatz DCSync against the Domain Controller to pull the password hashes for all Domain Admins, Domain Controller computer accounts, and KRBTGT. Now the attacker owns Active Directory.
It’s important to note that not many AD environments have delegated the ability to configure Kerberos Delegation, so this seems like an extreme example. Trimarc has identified that about 40% of customers have at least 1 account that is not an Active Directory administrator account that has the ability to modify a group policy linked to the Domain Controllers OU. Compromise of this account would enable the attacker to configure an AD group with the ability to set Kerberos Delegation. You may ask why do that when you could run code on a DC or update the AD Administrators group membership? The answer is that there is no good detection for the Kerberos Bronze Bit attack currently, so performing this action would likely not be noticed.
Key takeaways to leveraging Kerberos Bronze Bit to compromise Active Directory through Kerberos Constrained Delegation:
Attacker gains knowledge of an AD user account (could be an existing service account).
Attacker has compromised an account that is able to configure Kerberos delegation on an AD user account the attacker has the password for (Domain Controller User Rights Assignment + write access to the AD account’s “account control flags”).
Attacker configures Kerberos Constrained Delegation on the AD account so the account can delegate to the LDAP service on one/many/all Domain Controllers.
Attacker runs the Kerberos Bronze Bit attack code to get a delegation ticket for an Active Directory admin, even if that account is a member of Protected Users or has “account is sensitive and cannot be delegated” set.
Attacker uses the new delegation ticket for the AD admin to compromise AD
There is a second way that the Kerberos Bronze Bit Attack could be leveraged to compromise Active Directory and that’s through Resource-based Constrained Delegation.
Resource-based Kerberos Constrained Delegation (RBKCD) where the resource itself determines what accounts can delegate to itself. This means that if an attacker has Write (modify) access to the account (“RBKCD-target-account”), the attacker can add an attacker-controlled account to the PrincipalsAllowedToDelegateToAccount (attribute msds-AllowedToActOnBehalfOfOtherIdentity) list set on the RBKCD-target-account. This enables RBKCD on the RBKCD-target-account and provides constrained delegation from the attacker controlled account to the RBKCD-target-account.
The attacker controlled account could even be a newly created computer account using PowerMad if AD is configured with the default setting which allows Authenticated Users the ability to join computers to the domain).
An attacker could compromise Active Directory with the Bronze Bit Attack is if the attacker has compromised an account with write (modify) access to a Domain Controller computer account and has compromised another AD account (JoeUser). With this access, the attacker can add the JoeUser account to the PrincipalsAllowedToDelegateToAccount list on the Domain Controller computer account. Since the attacker controls the JoeUser account and has knowledge of the password, the attacker could leverage the Kerberos Bronze Bit attack to connect to the Domain Controller’s service (say LDAP) as any AD user, such as an AD admin account.
Trimarc identified that about 15% of customers have permissions on Domain Controllers (or the Domain Controllers OU) that would allow an account that is not an Active Directory admin account to perform this attack.
Key takeaways to leveraging Kerberos Bronze Bit to compromise Active Directory through Resource-Based Kerberos Constrained Delegation:
Attacker gains knowledge of an AD user account (could be an existing service account) or creates a new computer account in AD.
Attacker has compromised an account that has write access to a Domain Controller computer account or the ability to set permissions on computer objects at the domain or Domain Controller OU level.
The attacker can add the JoeUser account to the PrincipalsAllowedToDelegateToAccount list on the Domain Controller computer account.
Attacker runs the Kerberos Bronze Bit attack code to get a delegation ticket for an Active Directory admin, even if that account is a member of Protected Users or has “account is sensitive and cannot be delegated” set.
Attacker uses the new delegation ticket for the AD admin to compromise AD.
Note that this attack method is possible without leveraging the Kerberos Bronze Bit Attack provided that accounts with AD admin rights are not protected against delegation. The Kerberos Bronze Bit Attack enables us to bypass these protections and use any AD admin account.
Trimarc recommends the following review to ensure that compromising Active Directory with the Kerberos Bronze Bit is mitigated:
Ensure only AD admins are able to configure Kerberos Delegation in AD domains (default setting) by reviewing all Domain Controller group policy User Right Assignment setting “Enable computer and user accounts to be trusted for delegation”. Remove any additional accounts/groups that are configured with this right.
Review the permissions on the Domain and Domain Controllers OU to ensure that no additional permissions are granted that allow accounts that are not AD admins the ability to change permissions (WriteDACL/WriteOwner/GenericAll) or the ability to set Resource-Based Kerberos Constrained Delegation (Write access) on Domain Controllers. Scanning Domain Controllers directly for these permissions is advised to determine if this is an issue.
Detection of this attack is difficult since the Kerberos service ticket that is ultimately used is a valid ticket. It mat be possible to look for tickets marked “forwardable” that are associated with accounts that are members of “Protected Users” (assuming all admin accounts are members of this group) and/or another custom AD group that contains accounts protected configured to block Kerberos Delegation since they should not allow delegation.
Microsoft Patch Process
Microsoft released the patch on December 8, 2020 for this issue, though in order to enforce the KDC behavior change where Kerberos tickets are signed to prevent this attack from working, a registry key must be set. Microsoft refers to this change as “Enforcement”. Microsoft is planning to set the registry key to Enforcement mode in February 2021.
Relevant screenshots from the following article are shown below.
Registry Key Change Required After the Patch is Installed
Conclusion
The Kerberos Bronze Bit attack takes advantage of Microsoft Kerberos implementation details that provide an attacker with access the ability to request and modify Kerberos service tickets to impersonate any Active Directory user. Since the attack code is now publicly available, attackers can leverage this capability in AD environments today. The patch process involves installing the patch on all Domain Controllers, waiting a week, and then configuring the registry key to enforce the new Kerberos configuration which involves signing all Kerberos tickets to prevent future tampering. Since the update process requires installing the patch and then setting a registry key, it’s expected that many environments will remain vulnerable until Microsoft releases a subsequent patch (planned for February 2021) which sets the new registry key to enforcement by default. Detection of the Kerberos Bronze Bit attack is difficult since the Kerberos ticket used in the attack has common items configured and there is no clear sign of tampering (ticket is encrypted with the service account’s password hash).
In May 2020, I presented some Active Directory security topics in a Trimarc Webcast called “Securing Active Directory: Resolving Common Issues” and included some information I put together relating to the security of AD Group Managed Service Accounts (GMSA). This post includes the expanded version of attacking and defending GMSAs I covered in the webcast. I put this information together after speaking with someone about using GMSAs running services on servers that have privileged AD rights and there was confusion about what GMSAs actually do and what they can’t. The confusion seemed to be rooted in the belief that GMSA credentials are protected more than regular accounts (they aren’t). The key benefit is that their passwords change automatically, not that the credential data has stronger protections.
This post is meant to highlight what GMSAs can do and what an attacker can do if not protected appropriately. We have seen limited usage of Group Managed Service Accounts in AD environments when we perform Active Directory Security Assessments at Trimarc. GMSAs should be used wherever possible to replace user accounts as service accounts since the passwords will rotate automatically.
Group Managed Service Accounts (GMSAs) User accounts created to be used as service accounts rarely have their password changed. Group Managed Service Accounts (GMSAs) provide a better approach (starting in the Windows 2012 timeframe). The password is managed by AD and automatically changed. This means that the GMSA has to have security principals explicitly delegated to have access to the clear-text password. Much like with other areas where delegation controls access (LAPS), determining who should have be delegated access needs to be be carefully considered.
Key Points for Group Managed Service Accounts (GMSAs) :
The GMSA password managed by AD.
Computers hosting GMSA service account(s) request current password from Active Directory to start service.
Configure the GMSA to allow computer accounts access to password.
If an attacker compromises computer hosting services using GMSA, the GMSA is compromised.
If attacker compromises an account with rights to request GMSA password, the GMSA is compromised.
Group Managed Service Accounts have the object class “msDS-GroupManagedServiceAccount” and associated attributes specific to GMSAs. These properties include:
msDS-GroupMSAMembership (PrincipalsAllowedToRetrieveManagedPassword) – stores the security principals that can access the GMSA password.
msds-ManagedPassword – This attribute contains a BLOB with password information for group-managed service accounts.
msDS-ManagedPasswordId – This constructed attribute contains the key identifier for the current managed password data for a group MSA.
msDS-ManagedPasswordInterval – This attribute is used to retrieve the number of days before a managed password is automatically changed for a group MSA.
Running the AD PowerShell cmdlet Get-ADServiceAccount, we can retrieve information about the GMSA, including specific GMSA attrbiutes. This GMSA is a member of the domain Administrators group which has full AD & DC admin rights to the domain. The screenshot shows that the password changed recently and won’t change for a few weeks – changed on 5/11/2020 and configured to change every 30 days. This means that if we can get the password for this account, we have almost a month to use the account credentials before it changes. We can also identify a group that can retrieve the password data. We’ll take a look at this is a bit.
For most of 2019, I was digging into Office 365 and Azure AD and looking at features as part of the development of the new Trimarc Microsoft Cloud Security Assessment which focuses on improving customer Microsoft Office 365 and Azure AD security posture. As I went through each of them, I found one that was very interesting.
While Azure leverages Azure Active Directory for some things, Azure AD roles don’t directly affect Azure (or Azure RBAC) typically. This article details a known configuration (at least to those who have dug into Azure AD configuration options) where it’s possible for a Global Administrator (aka Company Administrator) in Azure Active Directory to gain control of Azure through a tenant option. This is “by design” as a “break-glass” (emergency) option that can be used to (re)gain Azure admin rights if such access is lost. In this post I explore the danger associated with this option how it is currently configured (as of May 2020).
The key takeaway here is that if you don’t carefully protect and control Global Administrator role membership and associated accounts, you could lose positive control of systems hosted in all Azure subscriptions as well as Office 365 service data.
Note: Most of the research around this issue was performed during August 2019 through December 2019 and Microsoft may have incorporated changes since then in functionality and/or capability.
Attack Scenario: In this scenario, Acme has an on-premises Active Directory environment. Acme embraced Azure Infrastructure as a Service (IAAS) as an additional datacenter and deployed Domain Controllers to Azure for their on-prem AD (as their “cloud datacenter”). Acme IT locked down the DCs following hardening advice and limited Azure administration to the VMs hosting the DCs. Acme has other sensitive applications hosted on servers in Azure.
Acme signed up for Office 365 and started a pilot. All of the Active Directory and Exchange admins (and many other IT admins) are granted temporary Global Administrator (aka Global Admin or GA) rights to facilitate the pilot. So, more than should be there and not well protected.
Many are familiar with Active Directory, the on-premises directory and authentication system that is available with Windows Server, but exactly what is Azure Active Directory?
Azure Active Directory (Azure AD or AAD) is a multi-tenant cloud directory and authentication service. Azure AD is the directory service that Office 365 (and Azure) leverages for account, groups, and roles. It is also an Identity Provider (IPD) and supports federation (SAML, etc). Note: given how rapidly the cloud changes, elements of this post may become out of date soon after the original post date. Azure AD is highly available and globally deployed.
Azure AD is deployed in over 30 datacenters around the world leveraging Azure Availability Zones where present. This number is growing rapidly as additional Azure Regions are deployed.
For durability, any piece of data written to Azure AD is replicated to at least 4 and up to 13 datacenters depending on your tenant configuration. Within each data center, data is again replicated at least 9 times for durability but also to scale out capacity to serve authentication load. To illustrate—this means that at any point in time, there are at least 36 copies of your directory data available within our service in our smallest region. For durability, writes to Azure AD are not completed until a successful commit to an out of region datacenter.
This approach gives us both durability of the data and massive redundancy—multiple network paths and datacenters can serve any given authorization request, and the system automatically and intelligently retries and routes around failures both inside a datacenter and across datacenters.
To validate this, we regularly exercise fault injection and validate the system’s resiliency to failure of the system components Azure AD is built on. This extends all the way to taking out entire datacenters on a regular basis to confirm the system can tolerate the loss of a datacenter with zero customer impact. … Azure AD is already a massive system running on over 300,000 CPU Cores and able to rely on the massive scalability of the Azure Cloud to dynamically and rapidly scale up to meet any demand. This can include both natural increases in traffic, such as a 9AM peak in authentications in a given region, but also huge surges in new traffic served by our Azure AD B2C which powers some of the world’s largest events and frequently sees rushes of millions of new users. … To support the health checks that gate safe deployment and give our engineering team insight into the health of the systems, Azure AD emits a massive amount of internal telemetry, metrics, and signals used to monitor the health of our systems. At our scale, this is over 11 PetaBytes a week of signals that feed our automated health monitoring systems.
Azure Active Directory is Not Cloud AD Azure Active Directory is not Active Directory hosted in the cloud. There is no standard AD authentication methods such as NTLM or Kerberos; no LDAP; and no group policy (GPO), so Azure AD won’t work for traditional on-prem applications.
There are cloud hosted Active Directory environments that can be used to manage cloud workloads in Microsoft Azure (Azure Active Directory Domain Services), Amazon AWS (Amazon Managed Microsoft AD), and Google Cloud (Managed Service for Microsoft Active Directory (AD)). These are all hosted Microsoft Active Directory environments which have 2 Domain Controllers (or more) and the tenant admins do not receive Domain Admin rights to the hosted AD environment; only delegated access is provided which often includes the ability to create/manage resources in a specific OU and specific GPOs.
Note: I don’t have room to include a comparison of these services here, but may write a future post if there’s interest (I did some research comparing Microsoft Azure vs Amazon AWS hosted AD service offerings in 2017).
Primary Management Tools The tool that most AD administrators are familiar with is Active Directory Users and Computers aka ADUC (MMC tool).
Azure Active Directory administrators will primarily use the web console at https://portal.azure.com to administer the environment.
Admins that manage Active Directory on-prem and now Azure AD/Office 365 will be using the on-prem MMC tools as well as the web admin portals (and various URLs associated with them). There are PowerShell cmdlets available for managing Azure AD (similar to on-prem), though cloud features often move faster than the PowerShell tools are released, which means that using the cloud admin portal should still be used, even when using PowerShell.
Interfacing with Azure Active Directory Since Azure AD doesn’t have LDAP, interfacing with AAD involves connecting via the Graph API (or PowerShell modules). I like PowerShell, so I use the PowerShell modules (or Portal websites) for management and reporting.
There are 2 primary PowerShell modules for interfacing with Azure AD: MSOnline and AzureAD. These can be installed through the PowerShell install feature: Install-Module -Name MSOnline -Force Install-Module -Name AzureAD -Force
The AzureAD module may eventually replace the MSOnline PowerShell module, but there are features available in MSOnline that haven’t been ported to the Azure AD module (yet).
Attacking and Defending the Microsoft Cloud (Office 365 & Azure AD) Sean Metcalf (Trimarc) & Mark Morowczynski (Principal Program Manager, Microsoft)
The allure of the “Cloud” is indisputable. Organizations are moving into the cloud at a rapid pace. Even companies that have said no to the Cloud in the past have started migrating services and resources. The Cloud is a new paradigm and the rapid update pace makes it difficult to keep up, especially when it comes to security.
This presentation focuses on the Microsoft Cloud (Office 365 & Azure AD) and explores the most common attacks against the Cloud and describes effective defenses and mitigation. While the content is focused on the Microsoft Cloud, some of the attack and defense topics are applicable to other cloud providers and are noted where applicable.
Key items covered:
Attacks against the Cloud
Account compromise and token theft
Methods to detect attack activity
Cloud identity firewall
Securing cloud infrastructure against attacks
Secure cloud administration
There are no new features for Active Directory in Windows Server 2019 except one performance update which doesn’t affect most deployments. This update is related to an updated algorithm that better supports the ESE version store on DCs. Ryan Ries describes this on the Ask DS blog:
The intent of the first section of this article is to discuss how Active Directory’s sizing of the ESE version store has changed in Server 2019 going forward. The second section of this article will discuss some basic debugging techniques related to the ESE version store.
Active Directory, also known as NT Directory Services (NTDS,) uses Extensible Storage Engine (ESE) technology as its underlying database.
One component of all ESE database instances is known as the version store. The version store is an in-memory temporary storage location where ESE stores snapshots of the database during open transactions. This allows the database to roll back transactions and return to a previous state in case the transactions cannot be committed. When the version store is full, no more database transactions can be committed, which effectively brings NTDS to a halt.
In 2016, the CSS Directory Services support team blog, (also known as AskDS,) published some previously undocumented (and some lightly-documented) internals regarding the ESE version store. Those new to the concept of the ESE version store should read that blog post first.
In the blog post linked to previously, it was demonstrated how Active Directory had calculated the size of the ESE version store since AD’s introduction in Windows 2000. When the NTDS service first started, a complex algorithm was used to calculate version store size. This algorithm included the machine’s native pointer size, number of CPUs, version store page size (based on an assumption which was incorrect on 64-bit operating systems,) maximum number of simultaneous RPC calls allowed, maximum number of ESE sessions allowed per thread, and more.
Since the version store is a memory resource, it follows that the most important factor in determining the optimal ESE version store size is the amount of physical memory in the machine, and that – ironically – seems to have been the only variable not considered in the equation!
The way that Active Directory calculated the version store size did not age well. The original algorithm was written during a time when all machines running Windows were 32-bit, and even high-end server machines had maybe one or two gigabytes of RAM.
As a result, many customers have contacted Microsoft Support over the years for issues arising on their domain controllers that could be attributed to or at least exacerbated by an undersized ESE version store. Furthermore, even though the default ESE version store size can be augmented by the “EDB max ver pages (increment over the minimum)” registry setting, customers are often hesitant to use the setting because it is a complex topic that warrants heavier and more generous amounts of documentation than what has traditionally been available.
Recent Comments