Why an Active Directory Password Reset Isn't Enough to Evict an Attacker
A simple Active Directory password reset often fails to eliminate persistence. Valid Kerberos tickets, local hash caching, and ACL-based backdoors allow attack…
When a SOC team resets compromised credentials, closes the ticket, and archives the incident, they may find that alerts continue to trigger in the following hours. Valid Kerberos tickets and locally cached hashes often leave the door wide open. The attacker hasn't left the building.
This is not a zero-day vulnerability, but rather a set of known Active Directory design behaviors. According to a technical analysis by BleepingComputer dated May 11, 2026, a password reset does not inherently break persistence. Caches, valid tickets, and ACL backdoors provide continued access after a credential change, creating a false sense of security that—per The Hacker News on November 12, 2025—exposes over 90% of Fortune 1000 companies.
Data from the Verizon DBIR, cited by BleepingComputer, indicates that approximately 44.7% of breaches involve stolen credentials. This explains why a reset is the first defensive reflex, but also why it is insufficient to resolve technical persistence on its own.
- Even after a reset, Windows systems may retain the previous hash in their cache if they haven't reconnected to the domain, allowing offline access and pass-the-hash attacks.
- Kerberos tickets remain valid for their remaining lifespan regardless of a password change, allowing attackers to maintain active sessions without re-authenticating.
- Golden Ticket and Silver Ticket attacks bypass password controls entirely, as the attacker independently forges valid Kerberos tickets for the domain.
- Modifications to Access Control Lists (ACLs), including the AdminSDHolder object, create permission-based backdoors that persist beyond credential rotation and are reapplied hourly.
"Password resets are often the first response to a suspected compromise. It makes sense; resetting credentials is a quick way to cut off an attacker's most obvious path back in. However, that doesn't always completely solve the issue." BleepingComputer, May 11, 2026
The Persistence of Cached Hashes
When an administrator forces a password change in Active Directory, the modification is written to the domain controller (DC), but propagation across all authentication paths is not instantaneous.
Windows systems cache password hashes to facilitate offline access. If an endpoint has not re-established a connection with the DC after the reset, the previous hash remains valid for local authentication.
In hybrid environments synchronizing Active Directory with Entra ID, replication delays can also occur before the new password hash is propagated across the entire infrastructure.
During this window, an attacker can reuse the previous hash via pass-the-hash techniques, continuing to move laterally through the network without ever needing to know the new credentials.
Kerberos Tickets: The Persistence Bridge
"Once attackers control AD, they control your entire network." According to an analysis by The Hacker News on November 12, 2025, this is what is at stake. In Active Directory, Kerberos authentication issues tickets that remain valid for a duration defined by domain policy, independent of any subsequent password resets.
If an attacker has already secured a valid ticket, they can continue accessing resources without re-entering a password, and the domain controller will not automatically invalidate the session.
This behavior stems from the architectural distinction between the Authentication Service and the Ticket Granting Service: the DC issues the ticket but does not continuously monitor real-time revocation following a password change.
While the exact duration depends on organizational configurations, the time frame is often more than enough for an attacker to consolidate persistence and execute lateral movement to other systems.
Golden and Silver Tickets: Forging Access
Golden Ticket and Silver Ticket attacks represent an even more extreme scenario. By forging a Ticket Granting Ticket (TGT) or a service ticket, the attacker requires neither valid credentials nor the most recent password hash.
A user password reset does not invalidate these autonomously generated cryptographic documents because the domain recognizes them as technically legitimate.
Anyone who controls the KRBTGT account secret can issue valid authorizations for the entire forest, rendering a password change completely irrelevant to the state of the compromise.
This technique exploits the fact that the domain trusts any ticket signed with the KRBTGT account's secret key—a mechanism that is not interrupted by a simple password change for a compromised user.
ACL Backdoors and the AdminSDHolder Object
A persistence vector entirely independent of credentials resides within Access Control Lists (ACLs). An attacker with elevated privileges can modify inherited permissions on protected objects, including AdminSDHolder—the container that defines the Security Descriptor Propagator (SDProp).
The SDProp process automatically restores those permissions every hour for privileged groups within the domain. Even after resetting every administrator password, an ACL backdoor can survive.
If an attacker has inserted an ACL backdoor, it is periodically reapplied, maintaining access even after the rotation of all administrative passwords.
This mechanism is particularly insidious because it requires neither a password hash nor an active ticket to maintain high-level privileges over time.
Strategic Response: Beyond the Reset
Response teams must treat password resets as the first link in a larger chain, not as the conclusion of an incident. Full eviction requires coordinated actions across multiple layers.
- Invalidate Kerberos tickets and active sessions. Changing a password does not automatically revoke issued tickets or disconnect active sessions. It is necessary to force the logout of compromised users and, where possible, trigger purge procedures to close the persistence window.
- Rotate the KRBTGT account password. This operation is critical to invalidating any Golden Tickets forged by attackers, as domain trust relies on this service account’s secret.
- Audit ACLs and AdminSDHolder. Verifying configurations and restoring original ACLs is the only way to remove credential-independent access, given that AdminSDHolder modifications are reapplied hourly by SDProp.
- Verify local caches and hybrid synchronization. Ensure that Windows endpoints have re-established communication with the DC and that no replication delays remain in hybrid AD/Entra ID environments that could keep the old hash active.
Editorial Note: The analyses cited are programmatic technical editorials rather than reports on a single documented breach. BleepingComputer describes known AD mechanisms in an article containing commercial references to Specops; the same source reports, based on vendor claims, that a password monitoring solution blocked over 4 billion compromised credentials. The Hacker News shows an internal date conflict (November 12, 2025 byline vs. May 11, 2026 metadata) and includes promotional content. DeafNews has independently verified the technical facts regardless of the sponsored nature of the source materials.
The lesson is that Active Directory is not a monolithic authentication system; the separation between identity, authorization, and permission configuration creates procedural gaps that attackers are adept at exploiting.
To the CISO: An incident response plan cannot end with a reset. You must invalidate sessions, rotate the KRBTGT secret, and audit ACLs before declaring the event over. Otherwise, you aren't closing the door—you are just changing the lock while the intruder is already inside with a duplicate key. This is the illusion that costs the most.
Information has been verified against the cited sources and is current at the time of publication.