Active Directory: the 2026 revision of the CISA guide

On 15 September 2026, a revision of the guidance Detecting and mitigating Active Directory compromises was published. The document is authored by the Australian Signals Directorate, ASD (1), through its Australian Cyber Security Centre, and co-signed by the Cybersecurity and Infrastructure Security Agency, CISA (2), the National Security Agency, the Canadian Centre for Cyber Security, the United Kingdom’s National Cyber Security Centre and its New Zealand counterpart. The first version was dated 26 September 2024. The guidance runs to seventy-four pages and is published under a Creative Commons Attribution 4.0 licence.

Its scope is Microsoft’s three directory services: Active Directory Domain Services, AD DS (3), Active Directory Certificate Services, AD CS (4), and Active Directory Federation Services, AD FS (5). The techniques are presented in the order in which they are usually executed, starting with privilege escalation and lateral movement and ending with persistence. Each technique is covered in three parts: the mechanism, the mitigating controls, the detection events.

The 2026 revision brings two substantive changes. The first is the addition of the Shadow Credentials technique, which abuses the msDS-KeyCredentialLink attribute. The second is a rebuild of DCSync detection, which now rests on auditing remote procedure calls rather than on auditing directory object access.

Before turning to the techniques, the guidance sets a prerequisite: securing privileged access using Microsoft’s tiered model, the Enterprise Access Model, which supersedes the older Active Directory Administrative Tier Model and accounts for hybrid environments.

Tier 0 covers user objects with significant access in the domain: members of the Domain Admins and Enterprise Admins groups, the KRBTGT (6) object, the AD FS service account, backup administrators, Microsoft Entra Connect user objects. On the machine side it covers Domain Controllers, the AD FS server, the root certificate authority, backup servers and the Microsoft Entra Connect server.

• Tier 0 user objects never expose their credentials to lower tier systems.
• Tier 0 computer objects are managed only by Tier 0 user objects.
• Lower tiers consume services provided by higher tiers, never the reverse.
• Privileged access pathways are reduced in number, protected and closely monitored.

Tier 0 objects call for additional protections: phishing-resistant multi-factor authentication, MFA (7), privileged access workstations, Kerberos armoring and zero trust policy enforcement. The guidance is explicit about the expected effect: this model makes several of the techniques described outright impossible, and forces malicious actors into more complex methods, which are therefore more detectable.

Eight techniques serve to gain privileges or to move through the domain. They share an operational trait: they rest on legitimate Active Directory functionality and generate the same events as normal activity. Detection therefore rarely turns on the presence of an event, and almost always on its volume, its fields or its context.

Kerberoasting

Any user object configured with a service principal name, SPN (8), will have its service ticket, TGS (9), issued to any other user object in the domain, including unprivileged ones. That ticket is encrypted with the object’s password hash, which can be cracked offline to reveal the cleartext password.

Detection rests on event 4769, generated on every TGS request. Two fields discriminate. A ticket encryption type of 0x17 indicates RC4 (10), which malicious actors favour because it cracks faster; as that type is uncommon, its residual volume is usable as a signal. Ticket Options values of 0x40800000 or 0x40810000 match the defaults of offensive security tools. Events 4738 and 5136 complete the picture: they record user object modification, the technique by which an SPN is added long enough to retrieve the ticket, then removed.

There are four mitigating controls: minimise the number of user objects configured with an SPN; create them as group Managed Service Accounts, gMSA (11), which enforce a 120-character password on automatic rotation, or failing that a password of at least 30 characters, unique and managed; grant them the minimum privileges needed and keep them out of highly privileged groups; enable AES (12) encryption, since Active Directory uses RC4 by default for service tickets.

AS-REP Roasting

The variant applies to user objects configured not to require Kerberos pre-authentication. The ticket granting ticket, TGT (13), is then returned in the authentication server response, encrypted with the password hash, and cracks in the same way. That configuration exists only to support systems older than Kerberos version 5.

Detection rests on event 4768, generated on a TGT request, with the same volume logic over a short window. Event 4625 adds to it: AS-REP Roasting can be executed before any authentication, without a valid user object, which produces a logon failure while the ticket is still issued. Correlating 4625 with 4768 establishes whether the technique was executed in the context of a valid user object. Events 4738 and 5136 record changes to the pre-authentication setting.

There is a single mitigating control: require Kerberos pre-authentication on all user objects. For the rare cases where it must be waived, the guidance calls for minimum privileges, exclusion from highly privileged groups, and a password of at least 30 characters for service accounts and at least 15 characters for users.

Password spraying

Password spraying tries a single password, or a small set of passwords, against a wide list of user objects, staying below the lockout threshold. The guidance flags a point that is often overlooked: the built-in domain Administrator account is not subject to the account lockout threshold. Even when it reports as locked out, it can still be authenticated to if the correct password is supplied, which clears the locked status and resets the bad password count. It should therefore be treated as a break glass account, with a password of at least 30 characters, marked as sensitive and not delegable, and monitored.

Second point: MFA is largely ineffective against this technique once initial access has been obtained, because authentication can be made directly to a Domain Controller over NTLM (14), which does not support it. The guidance recommends disabling NTLM and, where that is not possible, enabling LDAP (15) channel binding, extended protection for authentication and SMB (16) signing.

The badPasswordTime attribute complements these events: if several user objects share the same date and time of last failure, or very close values, spraying is likely. On the mitigation side, the guidance calls for passwords of at least 30 characters for local administrator, service and break glass accounts, managed through Local Administrator Password Solution, LAPS (17), where possible; four random words and at least 15 characters for single-factor authentication; lockout after at most five failed attempts, except for break glass accounts; randomly generated passwords on creation and reset; a monthly network scan for credentials stored in the clear.

MachineAccountQuota compromise

The ms-DS-MachineAccountQuota attribute allows any user object, by default, to create up to ten computer objects in the domain. Those objects automatically join the Domain Computers group and inherit its privileges. If that group is over-privileged, the malicious actor creates their own computer object, authenticates as it, and moves up a level. The technique also seeds KrbRelayUp where LDAP signing is not enforced, resulting in escalation to local administrator.

Three events are enough: 4741 on creation of the computer object, to be assessed against the creating object; 4724, an attempt to reset an object’s password, generated at or near the same time since the object must be given a password to be usable; 4624, to be correlated to establish that the created object did authenticate.

Mitigation comes down to four points: set MS-DS-MachineAccountQuota to zero, the real need being limited to administrators; confirm that Domain Computers is not a member of any privileged group; confirm that it holds no write privilege over any Active Directory object; enable LDAP signing on Domain Controllers, which also addresses KrbRelayUp.

Unconstrained delegation

When a computer object is configured for unconstrained delegation, a copy of the TGT of every user object that authenticates to it is held in that machine’s Local Security Authority Subsystem Service, LSASS (18), process. A malicious actor who gains local administrator rights extracts the tickets from it. Several techniques exist to force an object to authenticate to the targeted machine: the guidance cites the Print Spooler service on a Domain Controller, whose abuse yields the TGT of the Domain Controller’s own computer account.

Detection combines five events, four of them collected on the machines configured for unconstrained delegation rather than on Domain Controllers: 4103 and 4104 for PowerShell activity, which common tools rely on; 4624 for unusual authentications, and on the Domain Controller side for logons whose source address matches a machine configured for unconstrained delegation; 4688 for process creation, with the LSASS extraction commands the guidance sets out explicitly, procdump.exe -accepteula -ma lsass.exe lsass.dmp, rundll32.exe C:\windows\System32\comsvcs.dll, MiniDump <PID> C:\lsass.dmp full and sekurlsa::minidump; 4770 for TGT renewal, the default maximum lifetime being seven days.

The most effective mitigation is to remove unconstrained delegation in favour of resource-based constrained delegation. Three controls sit alongside it: mark privileged user objects as sensitive and not delegable; place them in the Protected Users group, whose members cannot be delegated; disable the Print Spooler service on Domain Controllers.

Password in Group Policy Preferences

CVE-2014-1812 allowed passwords distributed through Group Policy Preferences, GPP (19), to be decrypted. These values, known as cpasswords, live in the SYSVOL (20) directory present on every Domain Controller and readable by every user in the domain. The private key used to encrypt them was published around 2012. Microsoft security patch 2962486, released in 2014 under bulletin MS14-025, removed the ability to create them but did not remove existing cpasswords, whose deletion remains a manual step never carried out in many environments.

The guidance is categorical about detection: there is no effective method. There are too many ways to reach SYSVOL and the directory is read constantly as part of normal group policy processing. The only approach proposed is to place a canary GPP password belonging to a user object that should never be used, and to monitor any authentication by that object.

Mitigation is simple and carries no operational cost: remove all GPP passwords and apply patch 2962486.

AD CS compromise

AD CS implements Microsoft’s public key infrastructure. A misconfigured certificate template opens a direct escalation route. The configuration known as ESC1 combines four conditions: enrolment rights open to user objects, an extended key usage, EKU (21), that enables client authentication, the ability for the requester to supply their own subject alternative name, SAN (22), and the absence of certificate manager approval. Any user object can then request a certificate on behalf of a privileged object and authenticate as it.

The resulting certificate remains valid even if the impersonated object changes its password. It is invalidated only by expiry or revocation, and revocation is not systematically performed during incident response. Twelve other vulnerable configurations, ESC2 through ESC13, exist and are not detailed in the guidance, which refers readers to work by SpecterOps, Mandiant and Microsoft.

AD CS auditing is not enabled by default. Object access auditing for Certificate Services must be enabled under Advanced Audit Policy Configuration, then every available option must be selected on the Auditing tab in the certificate authority properties. Once collection is in place, nine events are usable.

The guidance adds a useful manual control: audit certificates issued for client authentication and look for mismatches between the requester and the subject name. A mismatch indicates a request made on behalf of another. The mitigating controls address template configuration, removing the Enrollee Supplies Subject flag, restricting standard user object permissions, removing the EDITF_ATTRIBUTESUBJECTALTNAME2 flag on the certificate authority, requiring certificate manager approval, removing EKUs that enable authentication, and the protection of the servers themselves, classified as Tier 0.

Shadow Credentials

This is the technique added in this revision. The msDS-KeyCredentialLink attribute, introduced with the Windows Server 2016 Domain Functional Level to support passwordless authentication including Windows Hello for Business, accepts key credentials. A malicious actor with sufficient permissions over an object adds their own key credential, authenticates by certificate and obtains a TGT as that object.

Two properties make it a persistence technique as much as an escalation one. The key remains valid after the target object’s password changes. Multiple key credentials can coexist on a single object, so a legitimate key and a malicious one sit side by side without conflict. By default, members of Domain Admins can modify the attribute on every user and computer object in the domain, and members of Key Admins and Enterprise Key Admins on every computer object.

Detection rests on a single event, 5136, generated when a directory object attribute is modified. It requires enabling Audit Directory Service Changes under Advanced Audit Policy Configuration, then configuring system access control lists on the objects concerned. The filter is twofold: the Attribute LDAP Display Name must be msDS-KeyCredentialLink, and the Subject Name field must not correspond to an authorised provisioning service. The guidance stresses the second point: an authorised list of passwordless authentication services must be maintained, since a malicious actor can deploy a plausibly named service to defeat a check based on account name recognition alone.

A periodic review complements event-based detection. For each key credential the attribute stores a unique identifier, a creation time, the public key material and the associated object. It contains neither the originating system nor the originating user, and therefore cannot on its own settle the question. It does allow three anomalies to be spotted: multiple key credentials on an object that does not warrant them, a key credential on an object that does not use passwordless authentication, a recently added key credential outside any known provisioning activity. In an environment that does not use passwordless authentication, any value in that attribute is suspicious.

Ten techniques concern full compromise of the domain or the maintenance of access. What they share is resistance to the usual eviction measures: several survive a general password reset, and two force the domain to be rebuilt.

Golden Certificate

Administrative access to a certificate authority allows its CA certificate and private key to be extracted, using the native backup tools or Mimikatz, Seatbelt and SharpDPAPI. Client authentication certificates are then forged for any object in the domain. They remain valid until revoked.

Detection is difficult because it requires catching the backup and exfiltration. The CAPI2 log on the certificate authority, which must be enabled in Event Viewer, produces event 70 when a certificate private key is acquired: that is the most direct signal, to be filtered on a subjectName field matching a CA certificate. Event 4876, raised when a backup of the CA database starts, is not reliable here: it is only generated if the certificate database and database log option is selected, not if only the private key and CA certificate are exported. Events 1102, 4103 and 4104 complete the set.

The decisive mitigating control is a hardware security module, HSM (23): the certificate authority’s private key can then no longer be backed up or exfiltrated. Around it, the guidance calls for MFA for privileged users, application control on certificate authority servers to block the execution of tools such as Mimikatz, and treatment of those servers at the same level as Domain Controllers.

DCSync

DCSync consists of requesting directory replication in order to obtain password hashes. It requires the Replicating Directory Changes, Replicating Directory Changes All or Replicating Directory Changes in Filtered Set permissions, or GenericAll or AllExtendedRights on the domain root object. By default those rights belong to the Enterprise Admins and Domain Admins groups and to the Administrators group on Domain Controllers. The prime target is the KRBTGT object, a precondition for a Golden Ticket. The hashes obtained are either cracked or replayed directly in a Pass-the-Hash, since NTLM accepts the hash as a valid authentication token.

The guidance flags a preparatory variant: enable reversible encryption storage on the target objects, wait for their next password change, then run DCSync to retrieve the cleartext passwords. This manoeuvre defeats complexity requirements and removes the cracking step altogether.

Detection has been rebuilt. The now preferred method rests on auditing the remote procedure calls, RPC (24), associated with Microsoft’s directory replication protocol. It produces less volume and a better signal-to-noise ratio than the previous one, but imposes two prerequisites: Domain Controllers running Windows Server 2019 or later, and the Microsoft October 2025 cumulative update or later.

• Enable RPC event auditing for success, preferably through Group Policy, or with auditpol /set /subcategory:"RPC Events" /success:enable.
• Configure the RPC firewall filter on each Domain Controller with the action set to permit: an action set to deny would block replication and desynchronise the directory.
• Filter on the interface globally unique identifier, GUID (25), e3514235-4b06-11d1-ab04-00c04fc2dcd2 and on OpNum 3, otherwise the event is generated for all audited RPC activity.
• Alert on event 5712 where the initiating account or source address is not authorised for directory replication.
• If replication runs over SMB, a non-default configuration, the source address is absent from event 5712: in that case correlate the SubjectLogonId field of event 5712 with the TargetLogonID field of event 4624.

The directory service access method remains available and less recommended, its volume being higher since event 4662 covers a far wider scope than replication alone. Three globally unique identifiers qualify it: 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2 for DS-Replication-Get-Changes-All, 89e95b76-444d-4c62-991a-0facbeda640c for DS-Replication-Get-Changes-In-Filtered-Set, and 19195a5b-6da0-11d0-afd3-00c04fd930c9, which indicates a change of permissions on the domain object intended to open replication access.

DCSync cannot be eliminated, since the permissions it abuses are required for Active Directory to function. The guidance therefore calls for reducing exposure: minimise the number of user objects holding the permissions; confirm that no object configured with an SPN holds them, so as to break the chain that runs from Kerberoasting to DCSync; prevent those objects from logging on to unprivileged operating environments; review the permissions every six months; disable NTLMv1; eliminate LAN Manager hashes, which a minimum 15-character password achieves.

Dumping ntds.dit

The ntds.dit file is the AD DS database, present on every Domain Controller except read-only ones, and holds the password hashes of all user and computer objects. Because the file is locked, copying it goes through the Volume Shadow Copy Service or Ntdsutil. Full decryption also requires the SYSTEM registry hive from the same Domain Controller. The guidance flags a quieter route: backups of Domain Controllers, sometimes placed on file shares and rarely protected to the same standard as the servers themselves.

Losing the file means losing more than the hashes. It means losing the KRBTGT hash, the trusted domain object hash and the backup key of the data protection application programming interface, DPAPI (26). That last one is immutable: it cannot be reset, and the only recovery option Microsoft recommends is to create a new domain and migrate all user objects to it.

Detection rests on six events collected on Domain Controllers: 1102 for clearing of the security audit log; 4103 and 4104 for PowerShell activity relating to the file; 4656 for a handle request on the object, to be filtered on an Object Name field matching ntds.dit; 4663 for actual access, which requires a system access control list, SACL (27), on the file; 4688 for process creation, which yields the commands and their parameters; 8222 for shadow copy creation, a common way of bypassing the file lock.

Mitigation is about hardening Domain Controllers: access limited to the privileged users who need it, access pathways restricted to jump servers and secure admin workstations, backups encrypted and reserved to backup administrators, no service or application unrelated to security, centralised logging, Print Spooler disabled, SMB version 1 disabled.

Golden Ticket

The KRBTGT object’s hash allows arbitrary TGTs to be forged. It does not need to be cracked, since it is the hash itself that encrypts the tickets. That hash is obtained through DCSync or by dumping ntds.dit. The KRBTGT object being the root of trust for the domain, its compromise requires a coordinated reset of every user and computer object password, and may lead to rebuilding the domain.

The most robust detection is detection by absence. Normal Kerberos authentication produces event 4768 on the TGT request, then 4769 on the TGS request, and the two correspond. A TGT forged offline was never requested from the Key Distribution Center: event 4769 exists, the corresponding 4768 is missing. Inconsistencies visible on 4769 round out the search: a user object that does not exist in the domain, a declared group membership with no real counterpart, an algorithm weaker than the domain default, a ticket lifetime far from the ten-hour default, Mimikatz using ten years.

The guidance is explicit about the limits of that approach: a careful malicious actor forges a ticket as close as possible to a legitimate one, and detection based on content anomalies guarantees nothing. Hence the mitigating control it settles on, changing the KRBTGT password every six months, or as soon as compromise is established or suspected, and changing it twice, since Domain Controllers hold both the old and the new password so as not to interrupt authentication. The interval between the two resets must be long enough for the first to have replicated to every Domain Controller.

Silver Ticket

A Silver Ticket forges a service ticket from the hash of the user object running a service, or from a computer object’s hash. It does not go through a Domain Controller, which makes it above all an evasion technique: the exchange is confined to the malicious actor and the targeted machine, and organisations rarely log authentication anywhere other than on Domain Controllers. The services targeted are file sharing, LDAP, the database service and the HOST service, which gives access to scheduled tasks and to PowerShell Remoting.

The technique also opens durable persistence. Active Directory changes computer object passwords every thirty days, but that change is initiated by the machine, not by the Domain Controller. A computer object whose password has not changed in years is still allowed to authenticate. A malicious actor holding the hash can tamper with the renewal process and keep access indefinitely.

Detection moves to the targeted machine. Two events are needed there: 4624 for the logon, and above all 4627, generated alongside it, which gives the group memberships of the account that logged on. Since the ticket is forged, it can carry a SID and memberships that do not match the object, and that discrepancy is the signal.

Mitigation combines gMSAs for objects configured with an SPN, effective password changes for all computer objects including Domain Controllers every thirty days, exclusion of computer objects from privileged groups, and no write or modify permission for the Domain Computers group over Active Directory objects.

Golden SAML

AD FS signs Security Assertion Markup Language, SAML (28), responses with a private key. A malicious actor who obtains that key forges responses and reaches the services for which AD FS acts as identity provider. The technique requires three elements: the token signing certificate and its private key, the Distributed Key Manager, DKM (29), master key held in AD DS and needed to decrypt the certificate, and the list of services concerned.

The effect reaches beyond the internal estate. If the relying party, Microsoft Entra ID for instance, trusts the identity provider’s MFA claims, the forged response bypasses MFA and survives a password change on the impersonated object. The technique was used in the supply chain compromise involving SolarWinds in 2019 and has been used since. The guidance notes that a relying party can be configured to require MFA even in the presence of an identity provider claim, which closes that door.

Access to the DKM container deserves particular attention: that attribute should be read only periodically, and only by the AD FS service account. Every occurrence calls for a check. Configuring directory service access auditing with Read All Properties on the AD FS parent and child containers is a prerequisite.

On mitigation, the AD FS service account must be a gMSA, which gives it a 120-character password rotated every thirty days and puts it out of reach of both Kerberoasting and cracking, and it must serve no other purpose. Token signing and encryption certificates must be rotated every twelve months, or sooner on compromise, twice in rapid succession in order to revoke existing tokens.

Microsoft Entra Connect compromise

Microsoft Entra Connect synchronises Active Directory with Microsoft Entra ID. The default configuration, password hash synchronisation, PHS (30), creates two objects: a user object in Active Directory prefixed MSOL, and an object in Entra ID prefixed Sync. The MSOL object holds replication permissions, which is to say exactly the permissions a DCSync requires. The Sync object holds the Directory Synchronisation Accounts role, which lets it create, modify and delete user objects and set passwords.

Administrative access to a Microsoft Entra Connect server allows the cleartext passwords of both objects to be extracted, notably with AADInternals. The first yields the hashes of the whole directory, the second allows the password of an object holding the Global Administrator role to be set, and therefore full control of the cloud estate. The other common configuration, pass-through authentication, PTA (31), is compromised differently: the authentication process between Entra ID and Active Directory is hijacked, which allows authentication as any object without knowing its password, and keeps a cleartext copy of the passwords presented.

Detection combines seven events collected on Microsoft Entra Connect servers: 611 for a password hash synchronisation failure, 650 and 651 for the start and end of retrieval of updated passwords, 656 for a detected change and the attempt to synchronise it, 657 for a successful synchronisation, 1102 for clearing of the security audit log, 4103 and 4104 for the PowerShell activity AADInternals relies on. A correlation-based detection sits alongside them: a pass-through authentication event with no corresponding authentication event on a Domain Controller indicates that the process has been hijacked.

Two mitigating controls are specific to this area and often overlooked: disable hard match takeover, which prevents the source of authority for an Entra ID object from switching to Active Directory, and disable soft matching once initial synchronisation is complete, failing which a new Entra ID object can be provisioned on demand. To these are added a ban on synchronising privileged objects between the two directories, with separate administrative accounts on each side, and MFA for all privileged Entra ID users.

One-way domain trust bypass

Establishing a trust between two domains creates a trusted domain object, TDO (32), whose password is shared between the two domains and stored in the directory. A malicious actor with administrator rights on a Domain Controller in the trusting domain retrieves that password hash from the System container, requests a TGT from the trusted domain by supplying it, and reaches resources in the trusted domain. The direction of the trust therefore offers no protection.

The guidance draws a clear conclusion: Active Directory domains do not act as security boundaries. The boundary is the forest, and even then the guidance describes domain hopping by combining a Golden Ticket with SID History, which reaches other forests where inter-forest trusts exist.

Detection turns on monitoring use of the TDO, which should only ever communicate with the domain it was created for. Event 4768, collected in the trusted domain, with a User ID field matching the TDO name, is the primary signal. It is supported by 1102, 4103 and 4104 on the Domain Controllers. Any other activity associated with the TDO, unusual LDAP queries or authentication events, calls for a check.

One operational consequence is worth carrying into incident response: the scope of an incident affecting one domain must include every domain with which a trust exists. And the TDO password is reset first in the trusting domain, then to the same value in the trusted domain.

SID History compromise

Every AD DS object carries a unique and immutable security identifier, SID (33), and a sIDHistory attribute meant to hold previous identifiers after a migration between domains. With administrator rights on a Domain Controller, a malicious actor adds the SID of a privileged object or group to the history of an object they control. That object then inherits the corresponding privileges without appearing in the group’s membership. It is a technique of persistence and concealment: the object passes for an ordinary user in every membership review.

Detection rests on four events: 4738, which records modification of the sIDHistory attribute on a user object and is the direct signal; 4675, generated when SIDs are filtered, which can reveal a domain hopping attempt; 4103 and 4104 for PowerShell activity; 1102 for clearing of the log. Since the attribute should only serve migrations, its modification is a rare event in most organisations, which makes it a low-noise signal.

Three mitigating controls: do not use the attribute, and clear it once a migration is complete and access has been reconfigured; check it weekly; enable SID filtering on domain and forest trusts. The guidance states that last control’s limit: it prevents the SIDs of built-in groups such as Domain Admins and Enterprise Admins from being used across domains, but lets through those whose relative identifier is greater than 1000.

Skeleton Key

Skeleton Key is malware that hijacks the NTLM and Kerberos authentication processes in the memory of a Domain Controller’s LSASS process and injects a universal password into it. Legitimate authentication keeps working; the malicious actor’s authentication succeeds with that password. The two are then indistinguishable.

The technique has three characteristics that detection can use. It downgrades to RC4 even where a stronger algorithm is available, which makes authentication fail for protected accounts or for accounts configured without RC4 on the infected Domain Controller; a variant without that downgrade exists but causes noticeable performance or memory problems. It resides only in memory and disappears on restart, so it has to be reinjected. It has to be deployed on every Domain Controller for all malicious authentication to succeed, failing which some attempts fail depending on which controller is reached.

Detection requires two preparatory steps: enable audit mode for the LSASS process, which generates an event for each driver that fails to load when LSASS protection is active, and enable Audit Kernel Object on Domain Controllers from Windows Server 2016 onwards, a system access control list being applied by default to the LSASS process from that version.

On event 4663, the guidance asks that the security solutions present on the host be established beforehand, since some legitimately access the LSASS process. The mitigating controls add three measures specific to this technique to the usual Domain Controller hardening: run LSASS in protected mode, apply Microsoft’s vulnerable driver blocklist, and restrict driver execution to an approved set, for example with Windows Defender Application Control. The guidance notes that LSASS protection can be bypassed through a vulnerable kernel mode driver, which is why the last two controls necessarily accompany the first.

Appendix B consolidates the events by source. That is the part of the guidance that transposes directly into a collection plan. It calls for careful reading on one point: Domain Controllers are only one source out of six.

Two configuration prerequisites govern the whole set. Events 4103 and 4104 require PowerShell module and script block logging. Events 4656 and 4663 require system access control lists on the objects to be monitored, starting with the ntds.dit file. To these are added the specific activations already listed: RPC event auditing and the RPC firewall filter for DCSync, directory service change auditing for Shadow Credentials, object access auditing and the Auditing tab for AD CS, the CAPI2 log on certificate authorities, kernel object auditing for Skeleton Key, directory service access auditing for both success and failure for canaries and for the DKM container.

Reading across the table brings out the events that serve several detections and therefore deserve priority. Event 1102 covers four techniques, 4103 and 4104 cover four each on Domain Controllers, 4624 covers three, 4768 four, 4738 three, 5136 three. These are the best-yielding signals for a collection effort that is starting out.

The guidance devotes a section to a detection technique that does not rest on event correlation. The observation behind it is blunt: the complexity of detecting Active Directory compromises is one of the leading causes of their success. The techniques abuse legitimate functionality, generate the same events as normal activity, and several are detected by the absence of an event rather than by its presence.

The mechanism is simple. Canary objects are created in the directory, with read access denied to the Everyone group. The Directory Service Access audit policy is configured for both Success and Failure. Any attempt to read a canary object’s properties then produces an audit failure event 4662, on which the security information and event management system, SIEM (34), alerts using the object’s globally unique identifier.

What makes it valuable is that the technique detects the compromise itself rather than the tooling used to carry it out. It applies to any compromise that enumerates domain objects, which is where most of them begin, for instance with SharpHound. The guidance names Kerberoasting, AS-REP Roasting and DCSync as detectable this way, and mentions the canaries developed by Airbus among the available tools.

The limit is stated plainly: a malicious actor who targets only one user object, or a small number of them, does not read the canaries and is not detected. The technique therefore does not replace collection, it gives it a low-noise safety net.

The document is primary and signed by six national agencies. The values cited here were taken from the original file and cross-checked against the Appendix B tables, not from a text conversion.

Collection first, rules second

Writing detection rules against events that are not being collected is the most common failure on this subject. The order is therefore fixed.

• Enable the missing logging on Domain Controllers: PowerShell module and script block logging, kernel object auditing, directory service change auditing, RPC event auditing for success with the matching firewall filter, directory service access auditing for both success and failure.
• Apply system access control lists to the objects to be monitored, starting with ntds.dit and with the objects for which msDS-KeyCredentialLink is to be audited.
• Extend collection to the five sources that are not Domain Controllers: certificate authorities, with the CAPI2 log enabled, AD FS servers, Microsoft Entra Connect servers, computer objects configured for unconstrained delegation, and sensitive servers likely to be targeted by a Silver Ticket.
• Check the prerequisites for RPC-based DCSync detection: Domain Controller operating system version and the October 2025 cumulative update. Failing that, detection stays on event 4662, with the volume that entails.

Detections by absence

Three detections described in the guidance rest not on the presence of an event but on its absence. They require specific engineering in the SIEM and are often left out.

• An event 4769 with no corresponding 4768, indicating a TGT forged offline and therefore a Golden Ticket.
• An authentication seen at a service provider with no corresponding 1200 and 1202 events on the AD FS side, indicating a forged SAML response.
• A pass-through authentication event on a Microsoft Entra Connect server with no corresponding authentication on a Domain Controller, indicating that the process has been hijacked.

The zero-cost debts

Some of the mitigating controls cost nothing more than a decision and a check. They close direct escalation routes and should be handled before the long programmes.

• Set ms-DS-MachineAccountQuota to zero and confirm that Domain Computers is neither a member of a privileged group nor the holder of a write privilege.
• Remove residual cpasswords from SYSVOL and confirm that patch 2962486 has been applied.
• Inventory and remove computer objects configured for unconstrained delegation, and disable the Print Spooler service on Domain Controllers.
• Inventory user objects without Kerberos pre-authentication and restore the requirement.
• Clear the sIDHistory attribute outside an ongoing migration, and put a weekly check in place.
• Mark the built-in Administrator account as sensitive and not delegable, give it a 30-character password and monitor it.
• Enable LDAP signing on Domain Controllers, disable SMB version 1 and NTLMv1.
• Deploy canary objects and wire them into the SIEM on their globally unique identifier.

The long programmes

What remains is the work that is planned over several years: implementing the tiered model, moving service accounts to gMSAs, rotating the KRBTGT password every six months and AD FS certificates every twelve, actually renewing computer object passwords every thirty days, moving certificate authorities onto hardware security modules, and applying application control and driver restriction on Domain Controllers.

A closing remark on how to use the document. The guidance describes techniques that are widely known and publicly documented, some of them for years. Its value to a detection team lies not in that description but in three rarer things: the precise list of fields to filter on, the appendix that consolidates events by source, and the inventory of audit configurations to enable beforehand. It is that last list which determines whether the first two are of any use.

1. ASD (1): Australian Signals Directorate, the Australian signals intelligence agency, parent of the Australian Cyber Security Centre.
2. CISA (2): Cybersecurity and Infrastructure Security Agency, the United States cybersecurity and infrastructure security agency.
3. AD DS (3): Active Directory Domain Services, Microsoft’s directory and authentication service.
4. AD CS (4): Active Directory Certificate Services, Microsoft’s public key infrastructure service.
5. AD FS (5): Active Directory Federation Services, Microsoft’s identity federation service.
6. KRBTGT (6): Kerberos Ticket Granting Ticket, the user object created with the domain, whose hash encrypts ticket granting tickets. The root of trust for the domain.
7. MFA (7): Multi-Factor Authentication, authentication requiring several distinct factors.
8. SPN (8): Service Principal Name, the identifier that ties a service to a directory object.
9. TGS (9): Ticket Granting Service, the Kerberos ticket granting access to a specific service.
10. RC4 (10): Rivest Cipher 4, a stream cipher used by default by Active Directory for service tickets and vulnerable to password cracking.
11. gMSA (11): group Managed Service Account, a service account type whose 120-character password Active Directory manages and rotates automatically.
12. AES (12): Advanced Encryption Standard, the block cipher to be used in place of RC4 for Kerberos tickets.
13. TGT (13): Ticket Granting Ticket, the initial Kerberos ticket, presented to obtain service tickets.
14. LDAP (14): Lightweight Directory Access Protocol, the protocol for querying and modifying the directory.
15. NTLM (15): New Technology LAN Manager, the family of Microsoft authentication protocols predating Kerberos, which does not support MFA.
16. SMB (16): Server Message Block, Microsoft’s file and print sharing protocol.
17. LAPS (17): Local Administrator Password Solution, Microsoft’s solution for managing local administrator account passwords.
18. LSASS (18): Local Security Authority Subsystem Service, the Windows process that validates authentication and holds the associated secrets in memory.
19. GPP (19): Group Policy Preferences, the Group Policy extension that allowed passwords to be distributed encrypted with a publicly known key.
20. SYSVOL (20): System Volume, the shared directory present on every Domain Controller and readable by every user in the domain.
21. EKU (21): Extended Key Usage, the certificate field that defines permitted uses, including client authentication.
22. SAN (22): Subject Alternative Name, the certificate field naming the identities to which it applies.
23. HSM (23): Hardware Security Module, the hardware module that holds private keys and prevents their extraction.
24. RPC (24): Remote Procedure Call, the mechanism for calling procedures across systems, on which the directory replication protocol runs.
25. GUID (25): Globally Unique Identifier, the unique identifier assigned to objects, interfaces and attributes.
26. DPAPI (26): Data Protection Application Programming Interface, the Windows data protection interface, whose directory backup key is immutable.
27. SACL (27): System Access Control List, the list defining which accesses to an object are audited.
28. SAML (28): Security Assertion Markup Language, the standard for exchanging authentication assertions between identity provider and service provider.
29. DKM (29): Distributed Key Manager, the component whose master key, stored in the directory, decrypts the AD FS signing certificate.
30. PHS (30): Password Hash Synchronisation, the synchronisation mode that copies password hashes from Active Directory to Microsoft Entra ID.
31. PTA (31): Pass-Through Authentication, the mode in which Microsoft Entra ID forwards authentication requests to Active Directory for validation.
32. TDO (32): Trusted Domain Object, the object created when a trust is established, holding a password shared between the two domains.
33. SID (33): Security Identifier, the unique and immutable identifier of a directory object, which determines its access rights.
34. SIEM (34): Security Information and Event Management, the system that collects, correlates and alerts on security events.

1. ASD ACSC, CISA, NSA, CCCS, NCSC-UK and NCSC-NZ, Detecting and mitigating Active Directory compromises, September 2026 revision, 74 pages. cyber.gov.au
2. CISA, resource page Detecting and Mitigating Active Directory Compromises, revision date 15 September 2026, accessed 16 September 2026. cisa.gov
3. CISA, alert on the initial release of the guidance, 26 September 2024. cisa.gov
4. NSA, press release on the joint publication of the guidance, September 2024. nsa.gov
5. Microsoft, MS-DRSR specification, Directory Replication Service Remote Protocol, referenced in a footnote of the guidance for the replication interface identifier. learn.microsoft.com
6. Microsoft Learn, 5712(S) A Remote Procedure Call (RPC) was attempted, referenced in a footnote of the guidance for the event description.