Why Password Resets Don't Stop Active Directory Attacks

Key Takeaways

• Cached password hashes remain usable on devices until users log in with new credentials
• Kerberos tickets stay valid for their full lifetime regardless of password changes
• Hybrid AD/Entra ID environments have sync delays that leave old passwords working temporarily

The Reset Reflex

When security teams detect a compromise, password resets are step one. It makes intuitive sense. Change the locks, lock out the intruder. But in Active Directory environments, this reflex has a flaw. Resetting a password doesn't immediately invalidate the old credential everywhere.

The gap between a password reset and full credential invalidation gives attackers time. Sometimes minutes. Sometimes hours. In poorly managed environments, potentially days. That window is often enough to maintain access or establish new footholds.

Three States After a Password Reset

Windows caches password hashes locally to support offline logins. This creates a problem during incident response. After a password reset, systems can exist in three different states.

1. The user has logged in with the new credential while connected to AD. The cached credential store updates and invalidates the old hash.
2. The user hasn't logged in to a particular machine since the reset. The old cached credential may still work for certain authentication attempts.
3. In hybrid deployments, the password has been reset in AD but hasn't synced to Entra ID yet. The old password still authenticates during the sync interval.

Each state represents a potential attack surface. Devices that haven't reconnected to the domain still hold the previous credential in usable form. In hybrid environments, sync delays can extend this window further.

How Attackers Exploit Cached Credentials

Pass-the-hash attacks are the most common exploitation method. Attackers use the captured hash directly instead of needing the plaintext password. If that hash was captured before the reset, changing the password doesn't immediately invalidate it on every endpoint.

The attack chain typically works like this: an attacker compromises one endpoint, extracts cached password hashes from memory, and uses those hashes to authenticate to other systems. Even after the security team resets the compromised user's password, the old hash remains valid on any device the user hasn't logged into with their new credentials.

Corporate laptops and remote systems are frequent targets because they often go days or weeks without connecting to the domain. The longer a device stays offline, the longer the old cached credentials remain valid on that endpoint.

The Kerberos Ticket Problem

Cached hashes aren't the only issue. Kerberos tickets present a separate challenge. When a user authenticates to Active Directory, they receive tickets that grant access to network resources. These tickets have a defined lifetime, typically 10 hours by default.

A password reset doesn't revoke existing Kerberos tickets. An attacker holding a valid ticket can continue using it until it expires naturally. In some environments, ticket lifetimes extend to 24 hours or longer, giving attackers a full day of access after the security team thinks they've locked them out.

Hybrid Environment Complications

Organizations running hybrid AD and Entra ID deployments face additional complexity. Password changes in on-premises AD need to synchronize to the cloud. This sync happens on an interval, not instantly.

During that interval, the old password continues to authenticate against cloud resources. An attacker who captured credentials before the reset can still access cloud applications, even if on-premises access has been cut off. The sync delay varies by configuration, but even short delays create exploitable windows.

What Actually Works

Effective incident response requires more than password resets. Security teams need to address each authentication path separately.

• Force immediate logoff of active sessions across all systems
• Revoke or reset Kerberos tickets for compromised accounts
• Trigger immediate password sync in hybrid environments
• Update cached credentials on endpoints where possible
• Monitor for authentication attempts using old credentials

Self-service password reset tools that update local cached credentials immediately can help close the gap. When a user resets their password through such a tool, the device they're using updates its credential cache right away. This doesn't eliminate the problem across all devices, but it reduces exposure at the network edge.

Building Better Response Procedures

The core issue is that Active Directory's authentication architecture predates modern threat models. It was designed for availability and user convenience, not for rapid credential invalidation during active breaches.

Organizations can't change AD's fundamental architecture. But they can build incident response procedures that account for its limitations. That means knowing exactly how long credentials remain valid in each part of the environment, and having documented steps to address each authentication path when a breach occurs.

Frequently Asked Questions

How long do cached credentials stay valid after a password reset?

Until the user logs in with the new password on that specific device while connected to the domain. Devices that remain offline can hold old cached credentials indefinitely.

Do Kerberos tickets get revoked when I reset a password?

No. Existing Kerberos tickets remain valid until they expire naturally, typically 10 hours by default. Attackers can continue using valid tickets after a password reset.

How quickly do password changes sync in hybrid AD/Entra ID environments?

Sync timing depends on your configuration. There's always some delay between an on-premises password change and cloud authentication using the new password.

What should I do instead of just resetting passwords during a breach?

Force logoff of active sessions, revoke Kerberos tickets, trigger immediate password sync in hybrid environments, and update cached credentials on endpoints where possible.

Can attackers use old password hashes after a reset?

Yes. Pass-the-hash attacks use the hash directly without needing the plaintext password. If the hash was captured before the reset, it may remain valid on devices that haven't updated their credential cache.

Source: BleepingComputer