Follow the Adversary: The Top 3 Red Team Exploitation Paths from 2024

Though 2024 may be behind us, many of the security threats and vulnerabilities that organizations faced last year remain. The CrowdStrike Professional Services Red Team tracks them all in its efforts to defend organizations against adversaries.

The three most common exploitation paths we encountered were: 

1. Unsecured Credentials: Weak or exposed credentials remain one of the easiest ways for adversaries to escalate privileges and move laterally.
2. Active Directory Certificate Services (AD CS) Abuse: Misconfigurations in AD CS provide attackers with near-instant escalation paths to domain compromise. These attack paths, often described as numbered escalation variants, can lead to immediate domain compromise under the right circumstances.
3. Excessive Permissions in Active Directory: This is another common issue that can be tough to remove in complex environments. Overly permissive access rights allow attackers to pivot and gain higher privileges undetected.

In this blog, we break down these three critical exploitation paths, detailing how they occur and what steps organizations can take to mitigate them.

A quick note on terminology: This article makes heavy use of the term “principal.” In Active Directory, principals are effectively any object that can be authenticated; for most of this article, this refers to user, service, and computer objects. If only a user, service, or computer is meant, it will be specified.

Exploitation Path 1: Unsecured Credentials

Unsecured credentials remain a pervasive issue. It’s much easier for the Red Team (and adversaries) to break in when the keys to the house are under the doormat. Not only is it a quick escalation path, it can also be difficult to detect without good identity monitoring.

There are many reasons this issue sticks around. Some common ones we see are:

• Teams lack access to a dedicated password management solution, so they resort to a shared spreadsheet for common credentials they use (such as a shared, external invoicing account).
• Administrators need to perform the same task routinely across hosts, so they save a PowerShell script to a shared location where they can quickly pull it down and run it. The script contains their hard-coded credentials instead of prompting for credentials.
• Backups of deployed code, particularly internal web servers, are saved in a development team’s shared folder that is accessible to any authenticated user. The code uses hard-coded values for credentials or keys rather than environment variables, exposing the secrets in plain text.
• Individual users back up their Desktop or Documents folders to a shared drive and have a nasty habit of including some form of a “passwords.txt” or “reminders.docx” file.

SharePoint is one area where credentials may be accidentally shared. If a company uses Microsoft Teams, files shared in “channels” (not individual direct messages) may find their way into the broader team’s site due to their linked nature. These can be found in the Files tab and may be located under an “Attachments” folder. Someone may share a sensitive file containing credentials, thinking it’s limited to a specific group in the Teams application — but if it isn’t properly locked down, it could be available to anyone on SharePoint.

So where have we found these credentials? As you might guess from the examples above, the top sources this year were SharePoint, network file shares, and code repositories. Process tools like Jira also got an honorable mention, as people (correctly) updated issues for project management but included configurations or passwords as part of the updates. Other locations where credentials often hide include deployment histories (Azure, Jenkins, etc.) and runbooks (Azure, Terraform, Ansible, etc.).

Potential Mitigations for Unsecured Credentials

Credential management may feel overwhelming at first, but it can become more manageable. Below are a few steps you can take:

• Implement a suitable (and secure) password management solution
• Perform routine scans of your network shares and SharePoint with tools like Snaffler
• Conduct user training, particularly for developers and IT staff who tend to write scripts or code with service account credentials baked in
• Use masking functions for secrets in automation (e.g., vaults in Ansible)
• Conduct code reviews prior to commit, and supplement these reviews using repository searchers like TruffleHog

Though it’s not a full mitigation because credentials shouldn’t be kept in plain text to the maximum extent possible, you can also review network share drives’ accessibility settings. Large, built-in groups like Authenticated Users often have access to more shares than intended as the use of the shares morphs over time or they are quickly set up. A tool like Snaffler can also be used to identify shares without digging into the files for quicker discovery.

Exploitation Path 2: Active Directory Certificate Services (AD CS)

AD CS abuse is another mainstay of near-instant regret since the paper Certified Pre-Owned came out in 2021. These attack paths, often called by their short names of numbered escalation variants (ESC1, ESC4, etc.), can lead to immediate domain compromise under the right circumstances — which, in our experience, is unfortunately much of the time.

As the name implies, AD CS governs the addition of cryptographic certificates and public key infrastructure (PKI) to the Active Directory environment. When coupled with Public Key Cryptography for Initial Authentication (PKINIT), these certificates can be used with Kerberos to authenticate as the principal without a password (think smart cards but without the physical card).

If PKINIT isn’t enabled in the environment, these certificates can still often be used to authenticate to other protocols such as Lightweight Directory Access Protocol (LDAP) over TLS, which can lead to secondary attacks like configuring Resource-based Constrained Delegation. 

Of the escalation paths we’ve seen in our operations, ESC1, ESC4, and ESC8 were the most consistent offenders. We explain these in greater detail below.

ESC1

This attack path includes settings that allow an attacker to request a certificate with an additional identity specified, allowing them to impersonate the target account. The vulnerable combination of settings for this attack path are:

• Large, built-in groups (usually Domain Users, Domain Computers, or Authenticated Users) can enroll with the template and with the certificate authority (CA)
• Manager approval is disabled, although this is not a deal-breaker with a little social engineering or luck (for example, inattentive managers)
• The desired template is enabled
• The Extended Key Usage (EKU) is set to a value that allows for some form of Kerberos authentication (e.g., client authentication), the EKU specifies “Any Purpose,” or the EKU is missing altogether 
• The certificate template has the ENROLLEE_SUPPLIES_SUBJECT flag, which allows the requestor to specify an additional principal when requesting the certificate

When these conditions are met, the enrollee can supply the name of a domain administrator or a domain controller and gain full Kerberos authentication without ever knowing their password.

If you used the open-source tool Certipy to gather AD CS data, the template shown below would be vulnerable to ESC1.

It is worth noting that if the certificate cannot be requested by those large, built-in groups, it could still provide a path (albeit a slightly longer path) to domain privilege escalation if non-Tier 0 principals can enroll in the vulnerable template. For example, we have commonly seen individual servers with the ability to enroll using vulnerable templates and have abused that permission to compromise the domain after gaining local administrative permissions over that server.

Mitigation: To mitigate against ESC1, ensure certificate templates do not include the ENROLLEE_SUPPLIES_SUBJECT flag. If it is absolutely necessary for other deployed technologies to supply an alternative subject name, then ensure the enrollment permissions are locked down to only other highly privileged groups, like domain admins and domain controllers. If that is also not an option, consider the feasibility of requiring manager approval for the requests to identify illegitimate use.

Review templates that specify “Any Purpose” or are missing an EKU altogether. Generally, “Any Purpose” and missing EKUs should be adjusted to only support the limited set of uses needed for that certificate. 

ESC4

ESC4 is more straightforward to explain than the exploitation path detailed above. Certificate templates are Active Directory objects like anything else in the environment, and ESC4 abuses misconfigured access control entries (ACEs) on these templates. With the ability to modify a template, an attacker could intentionally render it vulnerable using the settings described for ESC1 above.

Using Certipy again, the template below would be vulnerable to ESC4.

Mitigation: ESC4 follows a more traditional approach. Review permissions on template objects, and restrict ownership and other write permissions to domain admins wherever possible, since template owners/writers will be able to escalate to domain admin by modifying the template. Tools like Certipy can help identify these owners, as can traditional Active Directory exploration tools like BloodHound.

ESC8

Rounding out the most common offenders list is ESC8. Rather than abusing a template, this escalation path abuses the Web Enrollment capability on the CAs themselves. The CA Web Enrollment service allows users to perform certificate tasks in a web-based user interface on the CA by accessing the endpoint http(s)://ca-name.example.com/certsrv.

Though this can be useful for users who are not technically inclined, this functionality can also be abused with NTLM relay attacks.

SMB and LDAP signing are hardening options that can thwart NTLM relay attacks against their respective services — but ESC8 targets an HTTP service, which is not protected by these controls.

Once the authentication process has successfully completed through the attacker-in-the-middle, the attacker can use the resulting session with tools like Certipy or ntlmrelayx to automatically request a certificate for any template the victim can use. This can allow for impacts like authentication as the victim account or exploitation of other vulnerable templates not accessible to broad groups. If the victim is a domain controller, full domain compromise usually follows shortly after.

Mitigation: For ESC8, consider removing the Web Enrollment service entirely. If the service is still needed, Microsoft has supplied additional protections via Extended Protection for Authentication (EPA). You should also require HTTPS to access the Web Enrollment endpoint to force a TLS tunnel, and you can disable NTLM authentication for Internet Information Services (IIS) on the CA to limit the relayed credentials. For more information on these hardening steps, please see the Microsoft documentation.

An Aside: NTLM Relay Attacks

If the mechanics of NTLM relay attacks are foreign or a distant memory, let’s take a moment for a brief refresher. The NTLM authentication protocol makes use of a challenge and response flow wherein the principal’s password hash is used to encrypt a number that’s only used once (“nonce”). The client receives the nonce, encrypts it using the principal’s password hash (NT hash), and returns it to the service. Finally, the service sends the username, the nonce, and the client’s encrypted response to the domain controller. The domain controller retrieves the password hash for the supplied username, encrypts the nonce itself, and compares it to the encrypted value from the service. If everything matches up, the principal has successfully authenticated.

With an NTLM relay attack, the attacker positions themself in the middle of this process, where they can intercept and/or intentionally coerce authentication and redirect it to the desired location. Typically, this requires access to port 445 and a series of tunnels to achieve. Port 445 is automatically bound by the SYSTEM account on startup for Windows hosts, making local administrative access a prerequisite for most NTLM relay attacks in a Windows-heavy environment.

In a coercion scenario, the victim server is forced into authenticating to the compromised host. However, the attacker intercepts the first step of the authentication and sends it to the target server or service instead, initiating authentication there. The attacker-in-the-middle chauffeurs the rest of the NTLM flow back and forth until complete. Once the flow completes, the attacker controls the authenticated session.

Exploitation Path 3: Excessive Permissions in Active Directory

Excessive permissions in Active Directory are another perennial issue, but this group of issues can be difficult to fully stamp out in complex environments due to the number of moving parts. This issue is also challenging because it often stems from multiple areas, such as insufficient or unfollowed policies or the back-and-forth battle between expedience and security.

The CrowdStrike Services Red Team often encounters misconfigured, forgotten, or over-permissioned objects that have allowed us to hop, skip, and jump our way to control of environments. Let’s focus on just a few.

Over-Permissioned Accounts

This one has popped up in most environments we’ve tested. Service accounts that are members of domain admins or equivalent groups are one of the biggest issues. The problem here is that service accounts are often heavily proliferated through the environment to do their job. Further, they make up the biggest share of credentials we find in unsecured locations. Even if we don’t find it in a file share, we can potentially get the credential through Kerberoasting or from a host’s registry if the account is running as a service on that host.

It's not just domain administration rights that can be dangerous, though, and we can use service accounts as a stepping stone to local administrator status on servers that contain other paths.

The other major players here are service desk-type administrator accounts that can ultimately compromise the domain. We often see nested Active Directory group memberships that chain their way to the domain’s built-in Administrators group or accounts with the ability to modify other principals that can compromise the domain.

Insufficient Tiering of Accounts

Without going into too much detail, assets in a network can often be thought of in tiers, with Tier 0 being the domain itself and principals that can operate on it (e.g., domain administrators and domain controllers). Tier 1 often includes most other servers and their administrators, Tier 2 is typically help desk administrators and supporting infrastructure, and Tier 3 covers everything else.

Though many companies are getting better at segregating administrative accounts from normal user accounts, the CrowdStrike Services Red Team often finds there isn’t subsequent tiering for administrators, particularly between Tier 0 and Tiers 1/2. This means accounts with full control of the domain are logged in to workstations and file servers where their credentials are potentially accessible in LSASS, or they leave stale RDP sessions that can be hijacked. This is harder and potentially noisier to exploit, but it’s a problem nonetheless.

Misconfigured and Forgotten Access Control Rights

Another common Red Team finding is the Domain Users group having access control rights like AllExtendedRights, WriteDacl, or GenericAll on a few computer objects, and sometimes even other users.

To make matters worse, the computer objects may not correspond to a server that’s reachable over the network. But if the object hasn’t been removed from Active Directory, attackers can still abuse those permissions to take it over. This can lead to downstream attacks like chaining access controls to reach something else or enrolling in AD CS.

Two of the most common paths for misconfigured ACEs on computer objects are shadow credentials and Resource-based Constrained Delegation (RBCD), which can be abused when domain users have AllExtendedRights, GenericAll, GenericWrite, WriteDacl, or Owner on a computer object.

The first option, shadow credentials, requires one of two scenarios: 1) PKINIT enabled for authentication or 2) the presence of TLS with LDAP. The attacker writes a new credential into the msDS-KeyCredentialLink attribute of the target, adding a passwordless authentication mechanism for that principal.

RBCD is a little more complex, so let’s start with a little history lesson. The Kerberos authentication protocol uses tickets to gain access to services throughout the environment. If a user wants to access a web server, they obtain a service ticket for the HTTP service and send it over. If that service needs to access a back-end database to fetch information for the user, though, the provided service ticket won’t cover that. Thus, we have arrived at the double-hop problem.

Microsoft initially solved this problem by introducing unconstrained delegation. With this setup, the user would send a forwardable Ticket Granting Ticket (TGT) in addition to the service ticket. The web server (in this example) could then request a service ticket as the user to reach the back-end database. The problem? The TGT is as good as having the user’s password for anything using Kerberos authentication, so a compromised server would lead to the compromise of any users who accessed it.

Next came constrained delegation. Microsoft added Service for User to Self (S4U2Self) and Service for User to Proxy (S4U2Proxy). Now, the service could request a service ticket for any user in the environment either for itself (S4U2Self) or a designated list of services (S4U2Proxy). This list consisted of service principal names (SPNs) stored in the msDS-AllowedToDelegateTo attribute of the principal. This was better, but it was still flawed for reasons that don’t pertain to this discussion.

That finally takes us to RBCD. With RBCD, the paradigm is switched: The back-end service has a list of which services can delegate to it, and these services are stored as SPNs in the msDS-AllowedToActOnBehalfOfOtherIdentity attribute. The front-end service still uses S4U2Proxy and can still request a service ticket on behalf of any user that isn’t protected, but only if the back-end says it can. This is a step up, because now the target (the back-end) needs to be compromised first.

Enter misconfigured ACEs. With something like GenericWrite over another object, primarily computer accounts in this case, the principal can modify the msDS-AllowedToActOnBehalfOfOtherIdentity attribute to add an SPN that they control. That SPN could come from another attack (e.g., Kerberoasting), from another controlled computer, or from abusing the default machine account quota, which lets any user add 10 computer objects, no questions asked. These computer objects always come with an SPN.

Once the property has been modified, the attacker can use S4U2Proxy to request a service ticket for an administrator to the HOST service of the target, gaining administrative access over the computer.

Potential Mitigations for Excessive Permissions

One of the biggest steps to take is routine evaluation of your Active Directory environment for misconfigured items. The open-source tool BloodHound excels at this, taking data from AD Explorer or its own data ingestor and arraying it in a searchable database and graph. This can make it a little easier to find the needles in the haystack than sifting through Active Directory itself.

Key areas to look are:

• GenericAll, GenericWrite, AllExtendedRights, and WriteDacl for non-privileged users or groups over another object — there aren’t many normal reasons so see these rights for unprivileged users
• Multiple layers of nested groups that could lead to unintended permissions
• Active Directory objects, particularly computers, that no longer exist in the network but weren’t fully removed from Active Directory

Another nontechnical approach is to have strong policies and procedures around creating and destroying Active Directory objects. This ensures objects don’t get set up with a default template including permissions they don’t need, or get left behind when decommissioning. Domain administrator service accounts should not be provisioned without legitimate need.

On the technical side, make good use of the built-in Protected Users group in Active Directory. This will prevent those users from being delegated, like in the RBCD attack, and prevent their credentials from being cached wherever they log in. This is particularly useful for domain admins and any sensitive Tier 1 administrators. You should be aware that this may come with impacts to functionality, so ensure you understand all of the ramifications before you implement this. You can also mark the accounts “sensitive” individually, but that will only apply the delegation protections.

Wrap-Up

Though we’ve routinely seen (and abused) other things like weak SCCM implementations or lack of LDAP signing, addressing these three issues will greatly improve the general security posture of your network and make the Red Team (or real attackers) sit up straight and buckle in to dig deeper. These issues are also common year-over-year, so make it your organization’s priority to address them in 2025.

Additional Resources

• For more on what red team exercises can do for your organization, check out Red Teaming: How Red Team Testing Prepares You for Cyberattacks.
• Learn more about how CrowdStrike’s Professional Services can help your organization prepare for, respond to, and recover from breaches.