Active Directory Password Resets Fail to Expel Attackers

Executive Summary

Password resets, the standard first response to a suspected Active Directory (AD) compromise, do not reliably remove attackers. According to a technical analysis published May 11, 2026 by Specops Software, cached credential hashes, unexpired Kerberos tickets, and persistent ACL modifications allow adversaries to maintain access long after a user password is changed. In hybrid Entra ID environments, a synchronization delay can leave the old password valid for several minutes. Attackers who have already established alternate footholds — such as forged Golden or Silver Tickets, compromised service accounts, or modified AdminSDHolder ACLs — are unaffected by password changes alone.

Technical Analysis

Specops identifies three distinct states that can exist after a password reset:

1. Cached credential persistence. Windows caches password hashes locally for offline logon. If a device has not reconnected to the domain controller since the reset, the old hash remains usable. Attackers can leverage this via pass-the-hash attacks, where the hash itself authenticates without the plaintext password.

2. Kerberos ticket lifetime. AD authentication relies on Kerberos tickets that remain valid for a configurable period (typically 10 hours for TGTs). An attacker holding a valid ticket can continue accessing resources without re-entering credentials. Resetting the password does not invalidate already-issued tickets; only explicit logoff, reboot, or ticket purging achieves that.

3. Hybrid sync delay. In environments synchronizing AD to Entra ID via Azure AD Connect, the new password hash may not propagate immediately. The old password remains valid for authentication to cloud resources during the synchronization interval, which can be several minutes.

Beyond these timing gaps, four attack techniques bypass password resets entirely:

• Golden Ticket attacks. Compromise of the Kerberos Ticket Granting Ticket (KRBTGT) account hash allows forging valid TGTs for any user. Password resets do not invalidate forged tickets.
• Silver Ticket attacks. Forged service tickets grant access to specific resources without contacting a domain controller. Again, password changes have no effect.
• Service account persistence. Service accounts often have long-lived, elevated passwords that are infrequently rotated. Attackers can extract these via Kerberoasting or lateral movement and use them as a fallback after a user account reset.
• ACL backdoors. Attackers who modify Access Control Lists — for example, granting a compromised account the right to reset other users' passwords — create persistent permissions. Modifications to the AdminSDHolder object are re-applied hourly by SDProp, making them especially resilient.

Mitigations & Recommendations

Defenders should treat password resets as only one step in a broader incident response process. Specops recommends:

• Forcing session invalidation. After a password reset, require users to log off and reboot, or use klist purge to clear Kerberos tickets. In hybrid environments, manually trigger an Entra ID sync to minimize the synchronization gap.
• Rotating KRBTGT password twice. To invalidate existing Golden and Silver Tickets, the KRBTGT account password must be reset twice (with replication between resets). This forces re-issuance of all Kerberos tickets.
• Auditing AdminSDHolder and privileged ACLs. Regularly review ACLs on the AdminSDHolder object and privileged groups to detect unauthorized modifications.
• Implementing self-service password reset with local cache update. Specops uReset, combined with the Specops Client, can update the local cached credential store immediately on the device where the reset is performed, reducing the window for pass-the-hash attacks.
• Monitoring for anomalous authentication. Track Kerberos TGT requests, service ticket usage, and logon events after a password reset to detect continued attacker activity.