A password reset is often the first response to something suspicious. It makes sense; data reset is a quick way to cut the most obvious attacker’s way back.
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 old authentication for the entire authentication process.
Even a short window is an opportunity that may allow attackers to maintain access or re-establish a position.
For security developers and IT managers, this gap has real implications for incident response time.
Password reset loophole
Windows systems password cache hashes in place to support offline logins. If the device has not yet reconnected to the domain, it can still hold the previous credentials in a usable form. In mixed cases, there may also be a short delay before the new password is synced to Entra ID.
This means that there are three states that may be created after a password reset:
1. User logged in with new credentials while connected to AD. The authentication store updates, invalidating the old hash.
2. The user has not logged in to the device since the reset. Old archived evidence may be useful in certain verification efforts.
3. In mixed deployments, the password is reset with AD but the new hash is not yet synced to Entra ID. The old password can still be verified during password hash synchronization.
Verizon’s Data Breach Investigation report found stolen credentials were involved in 44.7% of breaches.
Easily protect your active directory with compliant password policies, prevent 4+ billion compromised passwords, strengthen security, and reduce support issues!
Try it for free
How attackers exploit the loophole
Cached authentication
Attackers use the cached password in ways such as pass-the-hash, where the hash itself is used instead of a plain text password. If that hash was captured before the reset, changing the password doesn’t instantly disable it everywhere.
Limiting that exposure is critical to protecting AD environments. Solutions like Specops uReset enable secure self-service password resets by enforcing end-user ID verification to reduce the risk of reset abuse.
When combined with the Specops Client, uReset can update the cached credential store immediately on the device where the reset was performed, closing the window where the old hash remains in use in that store.
This doesn’t eliminate identity drift entirely, but it does reduce exposure at the edge of the network, where corporate laptops and remote systems are often targeted.
Active sessions
AD authentication is mainly handled by Kerberos tickets, which are valid for a fixed period of time. If a user or attacker already has a valid ticket, they can continue to access resources without re-entering the password.
That means an attacker with an active session remains authorized even after the password has been changed. In some cases, that window is long enough to establish additional persistence or lateral movement.
Unless the sessions are explicitly invalidated, by logging out, restarting, or clearing tickets, access can continue well beyond manual reset.
Service accounts
Unlike user accounts, service accounts often have long-lasting passwords, and elevated privileges associated with sensitive systems. Attackers can expose that information by using techniques like Kerberoasting or find it when traversing the network.
Because these accounts are tied to active services, they are less likely to be reset quickly, especially if there is a risk of disruption. That makes them a reliable fallback to attackers after the original access point is closed.
Attack tickets
As mentioned above, in environments that use the Kerberos authentication protocol, access is controlled by tickets rather than repeated password checks. If an attacker can forge those tickets, they don’t need valid credentials at all.
The Golden Ticket attack, made possible by compromising the Kerberos Ticketing Account, allows attackers to create valid ticketing tickets for any user on a domain. Silver Tickets are more targeted, providing access to specific services without contacting a domain administrator.
In both cases, this attack successfully bypasses password changes. Resetting user passwords will not invalidate fraudulent tickets, and access can continue until the underlying problem is resolved.
Permits
AD is largely driven by Access Control Lists (ACLs). If an attacker grants the compromised account (or a new one they control) privileges such as resetting passwords for other users, they have successfully created a backdoor. Even if the original password is changed, those permissions remain.
In addition, accounts protected by AdminSDHolder (such as Domain Administrators) inherit permissions from a specific template. Attackers who change the ACL on the AdminSDHolder object can ensure that their permissions are reset every hour with SDProp.
How do you ensure that intruders are removed
The time between resetting a password and syncing across AD and Entra ID is short, usually a few minutes, which greatly limits attackers’ opportunities to exploit the loophole. Forcing regular synchronization is also possible, for example turning on AD Change Notification or manually starting Synchronization on the Entra ID tenant.
However, the gap still exists, and by the time account corruption is discovered, attackers may be able to devise additional measures. If resetting the password isn’t enough on its own, security guards need to consider blocking access altogether.
That starts with doing anything that comes into play. Active sessions should be terminated, and Kerberos tickets cleared by forcing a logout or reboot on the affected systems. As a worst-case scenario, resetting the KRBTGT account (twice) is usually necessary to invalidate the fake tickets.
Next comes authentication hygiene beyond standard user accounts. Service account passwords should be rotated, especially those with elevated privileges, and any credentials cached in storage locations should be erased as systems are reconnected.
Equally important is updating the directory itself. That means researching:
- Group membership
- Post privileges and ACLs
- Special accounts and roles
Look for anything that would allow access to be reset without relying on a password.
For serious violations, no single action warrants expulsion. It’s a combination of truncating sessions, rotating relevant information, and ensuring that no hidden access methods remain.
Secure your AD today
Hardening your AD requires that every account be protected with strong passwords, combined with a secure reset process that limits the potential for abuse.
Specops helps you do both, giving you the confidence that resetting a password strengthens your security rather than introducing new vulnerabilities.
Book a demo to see how our solutions can support your identity protection strategy.
Powered and written by Specops Software.
