Why Changing Passwords Doesn’t End an Active Directory Breach
Password resets in Active Directory and hybrid Entra ID environments do not immediately invalidate old credentials due to cached hashes, Kerberos ticket lifetimes, and synchronization delays, allowing attackers to maintain access.
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. In both Active Directory (AD) and hybrid Entra ID environments, password changes do not immediately invalidate the old credential across every authentication path. Even a short window is an opportunity that potentially allows attackers to maintain access or re-establish a foothold.
Windows systems cache password hashes locally to support offline logon. If a device hasn’t reconnected to the domain, it may still hold the previous credential in a usable form. In hybrid environments, there can also be a short delay before the new password syncs to Entra ID. This means there are three possible states after a password reset: the user has logged in with the new credential while connected to AD, the user has not logged in to a particular machine since the reset, or in hybrid deployments, the password has been reset in AD but the new hash has not yet synchronized to Entra ID.
Attackers exploit this gap using methods like pass-the-hash, where the hash itself is used instead of the plaintext password. If that hash was captured before the reset, changing the password doesn’t immediately invalidate it everywhere. Solutions like Specops uReset enable secure self-service password resets by enforcing end-user ID verification and can update the local cached credential store immediately on the device where the reset is performed, closing the window where the old hash remains usable on that endpoint.
AD authentication is primarily handled through Kerberos tickets, which are valid for a set period of time. If a user or attacker already has a valid ticket, they can continue accessing resources without re-entering a password. That means an attacker with an active session remains authenticated even after the password has been changed. Unless sessions are explicitly invalidated through logoff, reboot, or ticket purging, access can continue well beyond the reset itself.
Service accounts tend to have long-lived passwords with elevated privileges tied to critical systems. Attackers can expose those credentials through techniques like Kerberoasting or discover them when moving laterally. Because these accounts are tied to running services, they’re less likely to be reset quickly, making them a reliable fallback for attackers after an initial access point is closed.
In environments using Kerberos, access is controlled through tickets rather than repeated password checks. If an attacker can forge those tickets, they don’t need valid credentials at all. A Golden Ticket attack, made possible by compromising the Kerberos Ticket Granting Ticket account, allows attackers to create valid ticket-granting tickets for any user in the domain. Silver Tickets are more targeted, granting access to specific services without contacting a domain controller. In both cases, these attacks effectively bypass password changes.
AD is heavily driven by Access Control Lists (ACLs). If an attacker grants a compromised account rights like resetting passwords for other users, they’ve effectively created a backdoor. Even if the original password is changed, those permissions remain. Accounts protected by AdminSDHolder inherit permissions from a specific template; attackers who modify the ACL on the AdminSDHolder object can ensure their permissions are re-applied every hour by SDProp.
To fully remediate, defenders need to invalidate active sessions, clear Kerberos tickets by forcing logoffs or reboots, and for serious compromises, reset the KRBTGT account twice to invalidate forged tickets. Service account passwords should be rotated, and cached credentials on endpoints cleared. The time between a password reset and syncing across AD and Entra ID is typically just a few minutes, but the gap still exists, and attackers may have established additional footholds by the time a compromise is discovered.