Bleeping Computer

Why Changing Passwords Doesn’t End an Active Directory Breach


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.

For security architects and IT administrators, this gap has real implications during incident response.

The password reset gap

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 created after a password reset:

1. The user has logged in with the new credential while connected to AD. The cached credential store updates, invalidating the old hash.

2. The user has not logged in to a particular machine since the reset. The old cached credential may still be usable for certain authentication attempts.

3. In hybrid deployments, the password has been reset in AD but the new hash has not yet synchronized to Entra ID. The old password may still authenticate during the password hash synchronization interval.

Verizon’s Data Breach Investigation Report found stolen credentials are involved in 44.7% of breaches. 
 
Effortlessly secure Active Directory with compliant password policies, blocking 4+ billion compromised passwords, boosting security, and slashing support hassles!

Try it for free

How attackers exploit the gap

Cached credentials

Attackers take advantage of cached password hashes with 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.

Limiting that exposure is crucial to defending 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 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.

This doesn’t remove identity drift entirely, but it does reduce exposure at the network edge, where corporate laptops and remote systems are frequently targeted.

Specops uReset
Specops uReset

Active sessions

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. In some cases, that window is long enough to establish additional persistence or move laterally.

Unless sessions are explicitly invalidated, through logoff, reboot, or ticket purging, access can continue well beyond the reset itself.

Service accounts

Unlike user accounts, 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 through a network.

Because these accounts are tied to running services, they’re less likely to be reset quickly, especially if there’s a risk of disruption. That makes them a reliable fallback for attackers after an initial access point is closed.

Ticket attacks

As mentioned above, in environments using the Kerberos authentication protocol, 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. Resetting user passwords won’t invalidate forged tickets, and access can continue until the underlying issue is addressed.

Permissions

AD is heavily driven by Access Control Lists (ACLs). If an attacker grants a compromised account (or a new one they control) rights like resetting passwords for other users, they’ve effectively created a backdoor. Even if the original password is changed, those permissions remain.

Furthermore, accounts protected by AdminSDHolder (like Domain Admins) 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.

How to ensure attackers are removed

The time between a password reset and it synching across AD and Entra ID is small, typically just a few minutes, which severely limits the opportunity attackers have to exploit the gap. Forcing more frequent synchronizations is also possible, for instance turning on AD Change Notification or manually initiating a Sync to the Entra ID tenant.

However, the gap still exists, and by the time an account compromise is discovered, attackers may have been able to establish additional footholds. If password resets aren’t enough on their own, defenders need to look at fully closing off access.

That starts with invalidating anything already in play. Active sessions should be terminated, and Kerberos tickets cleared by forcing logoffs or reboots on affected systems. For more serious compromises, resetting the KRBTGT account (twice) is often necessary to invalidate forged tickets.

Next comes credential hygiene beyond standard user accounts. Service account passwords should be rotated, especially those with elevated privileges, and any cached credentials on endpoints should be cleared as systems reconnect.

Just as important is reviewing what’s changed in the directory itself. That means auditing:

  • Group memberships
  • Delegated rights and ACLs
  • Privileged accounts and roles

Look for anything that could allow access to be re-established without relying on a password.

For serious breaches, there isn’t a single step that guarantees eviction. It’s a combination of cutting off sessions, rotating the right credentials, and verifying that no hidden access paths remain.

Secure your AD today

Hardening your AD requires every account to be protected by strong passwords, combined with a secure reset process that limits opportunities for abuse.

Specops helps you do both, giving you confidence that password resets strengthen your security rather than introduce new gaps.

Book a demo to see how our solutions can support your identity security strategy.

Sponsored and written by Specops Software.



Source link