CISA, NSA, global cyber agencies issue guidance to detect and mitigate 17 Active Directory compromise techniques

Titled ‘Detecting and mitigating Active Directory compromises,’ the guidance explains how malicious actors can use these techniques to compromise Active Directory and recommends measures to mitigate the associated risks.

The guidance was developed by the Australian Signals Directorate (ASD) Australian Cyber Security Centre (ACSC) in cooperation with the U.S. Cybersecurity and Infrastructure Security Agency (CISA) and National Security Agency (NSA), the Canadian Centre for Cyber Security (CCCS), the U.K. National Cyber Security Centre (NCSC-UK), and New Zealand National Cyber Security Centre (NCSC-NZ). The document covers the agencies’ core cyber security functions, including threat identification and dissemination and the development of security specifications and mitigations.

After gaining initial access, malicious actors enumerate Active Directory to understand the organisation’s structure, objects, configurations, and relationships. This knowledge often exceeds the organization’s own understanding, enabling attackers to exploit weaknesses and misconfigurations more successfully. Armed with this intelligence, they escalate privileges, move laterally, and gain full domain control.

To improve Active Directory security, organizations must comprehensively understand their unique Active Directory configuration. Numerous commercial and open-source tools help organizations assess their Active Directory environments, including BloodHound, which provides a graphical user interface for understanding Active Directory and identifying misconfigurations and weaknesses that malicious actors could exploit. PingCastle provides an Active Directory security report, while Purple Knight provides information on an Active Directory environment’s security.

Interestingly, Active Directory stores data as objects that represent different resources, such as users, computers, groups and organisational units. The most common objects in an Active Directory domain are user and computer objects. User objects represent real users, service accounts, and built-in users such as the Kerberos Ticket Granting Ticket (KRBTGT) user object. Computer objects represent systems, such as servers and workstations in a domain. Every server and workstation that is joined to a domain has a corresponding computer object in Active Directory. These objects are used by Active Directory for authentication, authorisation and policy enforcement.

Malicious actors targeting Active Directory aim to escalate privileges and gain domain control by targeting the highest-privileged accounts, particularly Domain Admins and Enterprise Admins. While compromising service accounts or lower-privileged objects may grant significant access, preventing attackers from obtaining top-tier privileges is critical. Therefore, securing privileged access must be a top organizational priority to mitigate AD compromises.

Microsoft’s Enterprise Access Model provides a tiered framework for securing privileged access, designed for modern hybrid environments where on-premises AD connects to cloud services via Entra ID. The model enforces strict principles: Tier 0 users (highly privileged accounts) don’t expose credentials to lower tiers, Tier 0 computers are managed only by Tier 0 users, and hierarchy is enforced to prevent lower tiers from controlling higher ones. Additional protections for Tier 0 include phishing-resistant MFA, privileged access workstations, Kerberos armoring, and zero-trust policies. Access pathways are minimized, protected, and closely monitored.

Implementing the Enterprise Access Model makes many common AD attacks significantly harder or impossible to execute, forcing attackers toward more complex and riskier techniques. This substantially increases the likelihood that malicious activities will be detected, enabling organizations to identify compromises faster and minimize overall impact.

An attacker can then crack the TGS ticket (encrypted with the user’s password hash) to obtain the cleartext password and authenticate as that user. Service accounts targeted this way often have elevated privileges; if compromised, they can enable privilege escalation and lateral movement. Service accounts in highly privileged groups like Domain Admins can result in complete domain compromise.

Kerberoasting is difficult to detect because it mimics legitimate TGS requests. Monitor event 4769 (TGS request events) for anomalies: multiple TGS requests for different SPN-configured users within a short timeframe, or unusual TGS requests for services not typically accessed by the requester. These patterns may indicate active Kerberoasting and warrant investigation.

The agencies also detailed AS-REP Roasting, which exploits Active Directory user objects configured to not require Kerberos pre-authentication. Similar to Kerberoasting, any user object in the domain, including unprivileged user objects, can send an Authentication Server Request (AS-REQ) to retrieve the AS-REP ticket for any user object configured to not require Kerberos pre-authentication. 

The AS-REP ticket is encrypted with the user object’s password hash, which can be cracked to reveal the cleartext password. If malicious actors crack the AS-REP ticket and obtain the cleartext password, then they can authenticate as the user object (see Figure 2). AS-REP Roasting may be executed by malicious actors shortly after they gain initial access to an Active Directory domain to escalate their privileges and move laterally.

The document also covered password spraying attempts to authenticate to multiple user objects using either a single password or multiple passwords until they successfully authenticate to a user object. These passwords can come from public password wordlists or be derived from the target environment for a higher likelihood of success. For example, malicious actors may identify passwords being reused in the target environment and use these in password spraying to identify if they belong to any user objects. 

To minimise authentication attempts and the risk of detection, malicious actors can retrieve a list of usernames from Active Directory and attempt to authenticate to each one using a single password. This technique is particularly effective against organisations that reuse passwords. If malicious actors compromise a user object via password spraying, then they control the user object and inherit the user object’s access and privileges.

The guidance addressed Active Directory Certificate Services (AD CS) compromise, which implements Microsoft’s public key infrastructure (PKI), providing various services including encryption, code signing and authentication. The AD CS Certificate Authority (CA) manages and issues public key certificates. The AD CS CA can be configured with multiple certificate templates, allowing user and computer objects to request certificates for various purposes. Depending on the configuration of the AD CS CA, vulnerabilities can exist that can be exploited by malicious actors to escalate privileges and move laterally.

DCSync replicates Active Directory information, including password hashes, using ‘Replicating Directory Changes’ and related privileges or ‘GenericAll’/’AllExtendedRights’ permissions on the domain root, privileges granted by default to Enterprise Admins, Domain Admins, and the Administrators group on Domain Controllers. By compromising accounts or groups with these privileges, attackers can execute DCSync to retrieve all user and computer password hashes or target specific objects like KRBTGT (used for Golden Ticket attacks). Attackers then either crack the hashes to reveal cleartext passwords or use them directly in Pass-the-Hash attacks.

With the hash, malicious actors can create their own TGTs to impersonate any user object and then request a Ticket Granting Service (TGS) ticket from a Domain Controller. The TGS ticket can be used to access other Active Directory systems with the impersonated user’s privileges, enabling privilege escalation and lateral movement while minimizing the risk of detection. The KRBTGT hash is commonly obtained through DCSync or by dumping the ntds[dot]dit file from a Domain Controller, and it does not need to be cracked because the hash itself is used to encrypt the TGTs.

A successful Golden Ticket attack represents a complete compromise of an Active Directory domain because the KRBTGT user object serves as the domain’s root of trust. Recovery can require resetting all user and computer object passwords, including the KRBTGT password, in a coordinated manner. In some cases, organizations may need to build a new Active Directory domain with new user and computer objects and destroy the compromised domain. These recovery activities can be significant, costly and disruptive.

Silver Tickets forge valid TGS tickets using compromised password hashes from user objects running services or from computer objects themselves. With a forged TGS ticket, attackers authenticate directly to targeted services, such as CIFS (file access), LDAP (Active Directory queries), SQL, or HOST (task scheduling and PowerShell Remoting) without contacting a domain controller. This direct authentication bypasses normal detection mechanisms and enables persistent access to specific computer objects and their services.

Silver Tickets function as evasion techniques because authentication events occur between the attacker and target rather than through Domain Controllers, where monitoring is typically concentrated. Once established, attackers can use compromised computer credentials to maintain indefinite persistence: despite Active Directory’s 30-day password rotation policy, the process is initiated by computer objects themselves, allowing attackers with compromised hashes to tamper with this mechanism and authenticate as the computer object indefinitely, even after years without legitimate password updates.

The joint guidance identified that AD FS enables the secure sharing of verified identity information across security and enterprise boundaries. It is commonly used to extend authentication from an AD DS domain to cloud-based resources and services. AD FS supports SAML, an authentication standard that enables single signon. AD FS can be configured as an identity provider for different services (i.e., service providers such as Azure, AWS and Microsoft 365) that it can securely share identity information with, acting as an authentication broker. 

AD FS uses a private key to sign SAML responses, and these tokens are used to identify and authenticate users to the services for which AD FS acts as an identity provider. A Golden SAML compromises the AD FS private key to enable the forging of SAML responses. It is similar to a Golden Ticket, but instead of forging tickets for accessing on-premises systems, a Golden SAML forges SAML responses to access cloud-based resources and services. SAML responses can be forged to impersonate any user and to obtain access to any service for which AD FS acts as an identity provider. 

Shadow Credentials enables privilege escalation and lateral movement by exploiting the msDS-KeyCredentialLink attribute, designed for passwordless authentication like Windows Hello for Business since Windows Server 2016. Attackers with sufficient permissions or membership in highly privileged groups like Domain Admins can add malicious key credentials to user or computer objects, then authenticate via certificate-based authentication and request a TGT from a Domain Controller to impersonate the target and inherit its privileges. Because multiple credentials can coexist on a single object, malicious credentials persist even after legitimate password changes, allowing attackers to maintain indefinite access alongside authorized passwordless authentication mechanisms.

The guidance also mentioned that detecting Active Directory compromises can be difficult, time-consuming, and resource-intensive, even for organisations with mature security information and event management (SIEM) and security operations centre (SOC) capabilities. This is because many Active Directory compromises exploit legitimate functionality and generate the same events that are generated by normal activity. Distinguishing malicious activity from normal activity often requires correlating different events, sometimes from different sources, and analysing these events for discrepancies. 

For some Active Directory compromises, the detection relies on the presence of one event and the absence of another. The complexity of detecting Active Directory compromises is one of the leading causes of their success and their prevalence against organisations. The use of canary objects in Active Directory is an effective technique to detect Active Directory compromises. The benefit of this technique is that it does not rely on correlating event logs, providing a strong indication that a compromise has happened. Notably, this technique does not rely on detecting the tooling used by malicious actors like some other detection techniques do, but instead detects the compromise itself. As such, it is more likely to accurately detect compromises against Active Directory. 

“Any compromise against Active Directory that enumerates objects in the domain can be detected using this technique,” according to the document. “This is important as most compromises against Active Directory start with enumerating all objects in a domain using a tool, such as SharpHound, which collects information from Active Directory. Malicious actors employ this tactic to identify misconfigurations, weaknesses and vulnerabilities that can be exploited to escalate privileges and move laterally. This type of enumeration is detected by this technique and can provide an early warning to organisations that an Active Directory compromise is underway.”

It pointed out that kerberoasting, AS-REP roasting and DCSync Active Directory compromises can be detected using this technique. “A limitation of this technique is that malicious actors may choose to only target a single or a small number of user objects. If so, they are unlikely to try and read the canary objects. As a result, this technique would not generate the desired audit failure event and, subsequently, would not be detected by the SIEM.”