Why Password Changes Fail to Stop Active Directory Breaches

Password resets are typically the go-to move when a breach is suspected. The logic is straightforward: changing credentials should sever an attacker’s line back into the network. But in Active Directory (AD) and hybrid Entra ID environments, that assumption doesn’t always hold.

A password change does not instantly invalidate the old credential across every authentication path. Even a brief window of opportunity can allow attackers to maintain access or re-establish a foothold. For security architects and IT administrators, this gap carries serious implications during incident response.

The password reset gap

Windows systems store password hashes locally to enable offline logon. If a device hasn’t reconnected to the domain, it may still hold the previous credential in a usable form. In hybrid setups, a short delay can occur before the new password syncs to Entra ID.

This creates three possible states after a password reset:

1. The user logs in with the new credential while connected to AD. The cached store updates and invalidates the old hash.

How attackers exploit the gap

Cached credentials are a prime target. Attackers use techniques like pass-the-hash, where the hash itself replaces the plaintext password. If that hash was captured before the reset, changing the password doesn’t immediately invalidate it everywhere.

Limiting that exposure is critical. Solutions like Specops uReset enforce end-user ID verification for secure self-service password resets, reducing the risk of abuse. 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 eliminate identity drift entirely, but it reduces exposure at the network edge, where corporate laptops and remote systems are frequently targeted.

Active sessions present another vulnerability. AD authentication relies heavily on Kerberos tickets, which remain valid for a set period. If a user or attacker already holds a valid ticket, they can continue accessing resources without re-entering a password. An attacker with an active session stays authenticated even after the password is 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.

Service accounts are often overlooked. Unlike user accounts, they tend to have long-lived passwords with elevated privileges tied to critical systems. Attackers can expose these credentials through techniques like Kerberoasting or discover them during lateral movement. Because these accounts are tied to running services, they’re less likely to be reset quickly, especially if there’s a risk of disruption. This makes them a reliable fallback for attackers after an initial access point is closed.

Ticket attacks bypass password changes entirely. In environments using Kerberos, access is controlled through tickets rather than repeated password checks. 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. Resetting user passwords won’t invalidate forged tickets, and access can continue until the underlying issue is addressed.

Permissions are another persistent backdoor. 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. 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 its synchronization across AD and Entra ID is typically just a few minutes, which severely limits the opportunity for attackers to exploit the gap. Forcing more frequent synchronizations is possible, for instance by turning on AD Change Notification or manually initiating a sync to the Entra ID tenant. However, the gap still exists. By the time an account compromise is discovered, attackers may have already established additional footholds. If password resets aren’t enough on their own, defenders need to fully close off access.

Start by 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, focus on credential hygiene beyond standard user accounts. Service account passwords should be rotated, especially those with elevated privileges. 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 membershipsLook 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.