Active Directory – Resetting passwords can stop one attack path, but AD and hybrid Entra ID environments may still allow access through cached credentials, sessions, tickets, and permissions.
A password reset can feel like the moment an Active Directory breach ends. But in many real-world incident responses—especially across Windows and hybrid Entra ID setups—the attacker’s access isn’t always shut off immediately.
Even after a credential change, the old password material may remain usable along specific authentication paths. That short gap can be enough for an intruder to keep operating, re-establish access, or pivot to new systems before defenders fully contain the incident.
In Windows environments, password hashes can be cached locally to support offline logons.. If a machine hasn’t reconnected to the domain since the reset. it may still hold the previous credential in a form that can be used.. In hybrid deployments. defenders also have to account for synchronization timing. where a password change in Active Directory may not instantly reflect in Entra ID.
As a result, a reset can create multiple states after the change.. One possibility is that the user logs in with the new credential while connected to Active Directory—updating the cached store and invalidating the old hash on that endpoint.. Another is that the user hasn’t logged into a specific machine since the reset. leaving the older cached credential potentially usable for certain authentication attempts.. In hybrid cases. there can be a brief interval where the old password still authenticates because the updated password hash hasn’t synchronized to Entra ID yet.
That timing challenge matters because stolen credentials appear prominently in real incidents.. Verizon’s Data Breach Investigation Report found stolen credentials were involved in 44.7% of breaches. underscoring why password-related containment steps are so central—but also why relying on them alone can be risky.
Attackers often focus on cached credentials. including techniques such as pass-the-hash. where a captured hash is used instead of the plaintext password.. If that hash was obtained before the reset, simply changing the password may not invalidate it immediately everywhere.. For defenders. reducing exposure in this “edge” zone—where corporate laptops and remote endpoints frequently sit—becomes a practical requirement during and after a compromise.
To address reset abuse and limit the window where old hashes remain usable. the report points to identity-side controls such as Specops uReset.. It is described as enabling secure self-service password resets by adding end-user ID verification to reduce the chance that reset workflows themselves can be exploited.. When paired with the Specops Client. uReset can update the local cached credential store immediately on the device where the reset is performed. narrowing the period in which an old hash could still work on that endpoint.
Password resets also don’t automatically remove access that already exists through active authentication.. Active Directory access is heavily tied to Kerberos tickets, which remain valid for a period of time.. If an attacker (or a legitimate user) already holds a valid ticket. they can continue accessing resources without re-entering a password.. That means a compromised session can persist after the reset, giving the attacker time to maintain access or establish persistence.
The same logic extends beyond user accounts.. Service accounts often rely on long-lived credentials and have elevated privileges tied to critical systems.. The report notes that attackers can expose these credentials through methods such as Kerberoasting or during lateral movement.. Because service accounts are tied to running services. defenders may be cautious about rotating them quickly. and the resulting delay can make them a dependable fallback for an attacker once an initial access path is disrupted.
Then there are ticket-forging attacks.. In Kerberos-based environments, access decisions are driven by tickets rather than repeated password checks.. If an attacker can forge tickets, they may not need valid credentials at all.. A Golden Ticket attack—enabled by compromising the Kerberos Ticket Granting Ticket account—can allow attackers to create ticket-granting capabilities for any user within the domain.. Silver Tickets, by contrast, are more targeted and grant access to specific services without contacting a domain controller.. In both cases. password resets won’t invalidate forged tickets. and attackers can continue until the underlying Kerberos compromise is addressed.
Even when credentials are changed, permission structures can preserve unwanted access.. Active Directory is driven by Access Control Lists (ACLs).. If an attacker grants a compromised account—or one they create—rights such as the ability to reset passwords for other users. those permissions can function like a backdoor.. Changing the original password doesn’t necessarily remove those authorization paths.
The report also highlights AdminSDHolder as a critical mechanism.. Accounts protected by AdminSDHolder (including Domain Admins) inherit permissions from a template. and attackers who alter the ACL on AdminSDHolder can ensure their permissions are re-applied periodically via SDProp.. That persistence mechanism can keep malicious access in place even after defenders believe they’ve restored “normal” account behavior.
Defenders can limit the reset-to-synchronization window, but the gap doesn’t always disappear.. The report notes that the time between a password reset and syncing across Active Directory and Entra ID is typically just a few minutes. which can reduce the opportunity attackers have to exploit credential drift.. It also points to options like enabling AD Change Notification or manually initiating a sync to the Entra ID tenant to tighten timing further.
Still, the breach may already have matured by the time the password change occurs. The report stresses that by the point defenders discover an account compromise, attackers may have established additional footholds—so password resets alone may not be enough to “evict” them from the environment.
In practice, closing access requires cutting off what’s already in motion.. That means terminating active sessions and clearing Kerberos tickets by forcing logoffs or reboots on affected systems.. For more serious incidents, resetting the KRBTGT account—twice—is described as often necessary to invalidate forged tickets.
Beyond ending active access, defenders should also return to credential hygiene.. The report emphasizes rotating service account passwords. especially for accounts with elevated privileges. and clearing cached credentials on endpoints so that once systems reconnect. they no longer rely on pre-reset credential material.
Equally important is validating what changed inside the directory itself. The report recommends auditing group memberships, delegated rights and ACLs, and privileged accounts and roles, with a focus on whether anything could allow access to be re-established without depending on passwords.
For organizations dealing with serious compromises, there isn’t a single “one and done” action that guarantees removal. The report frames the solution as a combination: terminate sessions, rotate the right credentials, and verify that no hidden access paths remain.
Hardening Active Directory. it adds. involves pairing strong password protections with a secure reset process designed to reduce opportunities for abuse.. It also notes that Specops supports this approach by helping organizations ensure password resets strengthen security rather than introduce new gaps.
For teams preparing for future incidents. the key lesson is straightforward: when a breach is active. the credential reset may be necessary. but it’s rarely sufficient.. Attackers can persist through caching. sessions. Kerberos tickets. and authorization changes—so incident response needs to treat password resets as the start of a broader containment and verification effort.
Sponsored and written by Specops Software.
Active Directory breach password reset gap Kerberos tickets Entra ID sync cached credentials service account risk