Changing Your Password Won’t Save You

Last Updated on May 31, 2026 by Arnav Sharma

Incident response teams reach for password resets almost by instinct. A compromised account gets flagged, someone fires off a reset, and there’s a quiet feeling that the door just got locked. It’s a reasonable reflex. But in Active Directory environments, that locked door still has several open windows.

I’ve seen this play out more than once during post-incident reviews. The reset happened fast. The attacker was gone within the hour. And yet, two weeks later, forensics showed persistent access that nobody noticed during the initial response. Understanding why that happens is not a nice-to-have for security architects. It’s table stakes.

---

Why the Reset Doesn’t Stick Immediately

Windows caches password hashes locally so devices can authenticate when they’re offline or can’t reach a domain controller. That’s a practical design choice. But it creates a gap that doesn’t close until the device reconnects and the user logs in with the new credential.

Think of it this way: resetting a password in AD is like changing the lock on your front door, but a spare key is still sitting in a lockbox at the hardware store. Until someone physically retrieves and destroys that spare, the old key still works in the right circumstances.

This gets more complicated in hybrid environments. When your AD syncs to Entra ID via password hash synchronization, there’s a window between the reset in AD and the moment that new hash lands in Entra ID. It’s usually only a few minutes, but a short window is still a window.

Three states can exist simultaneously after a reset:

• The user has logged back in on a domain-connected machine. Old hash is gone, new one is cached.
• A machine hasn’t reconnected since the reset. Old hash still sitting there, potentially usable.
• Hybrid sync hasn’t completed yet. Old password may still authenticate against Entra ID.

---

The Techniques Attackers Use to Ride Out a Reset

Pass-the-Hash

Attackers who already captured a credential hash before the reset can still use it. Pass-the-hash doesn’t require knowing the plaintext password. If the hash was grabbed from memory before you reset the account, the reset didn’t help you on endpoints that haven’t yet updated their local cache.

This is why forcing a domain reconnect and cache refresh matters during incident response, not just resetting the password in the directory.

Active Kerberos Tickets

Kerberos is ticket-based. Once a ticket is issued, it’s valid for its entire lifetime regardless of what happens to the underlying password. An attacker with an active session at the time of your reset just keeps going. They already have a valid ticket granting ticket (TGT) and can request service tickets without touching a password at all.

Unless you explicitly purge Kerberos tickets (force logoffs, reboots, or run klist purge on affected systems), sessions outlive the reset.

Service Accounts: The Overlooked Target

User account passwords get reset. Service account passwords rarely do, often because someone is worried about breaking a running service. Attackers know this. After initial access gets cut off, service accounts with elevated privileges become the fallback.

Techniques like Kerberoasting let attackers request encrypted service tickets for any service account registered with a Service Principal Name (SPN), then crack those tickets offline. By the time your IR team is patching up the obvious holes, an attacker may have already moved laterally using a service account nobody thought to rotate.

Golden and Silver Ticket Attacks

These are the nastiest persistence mechanisms in the Kerberos playbook. A Golden Ticket requires compromising the KRBTGT account (the master key for all Kerberos operations in the domain). With that, an attacker can forge valid TGTs for any user, including accounts that don’t exist. Password resets mean nothing here because the attacker isn’t using any real credential.

A Silver Ticket is more targeted. It grants access to a specific service without contacting a domain controller at all. Both attacks bypass password changes entirely. The only real remediation for Golden Tickets is resetting KRBTGT twice (to force rotation of both the current and previous key).

ACL Persistence

AD is built on Access Control Lists. An attacker who spent time inside your directory may have quietly granted themselves (or a newly created account) rights like DCSync, WriteOwner on privileged groups, or the ability to reset passwords for other accounts.

There’s also AdminSDHolder to consider. Any account protected by it inherits permissions from a specific template object every hour, courtesy of a background process called SDProp. If an attacker modified the ACL on AdminSDHolder, those changes propagate back to every protected account 60 minutes later. You reset the account, you patch the obvious hole, but an hour later the permissions are back.

---

What a Real Eviction Actually Looks Like

The word “eviction” is deliberate. A password reset is not eviction. It’s more like changing your front door lock while the attacker is already inside browsing your kitchen.

A proper eviction after a serious AD compromise looks something like this:

1. Kill active sessions. Force logoffs and reboots on affected systems. On high-value targets, purge Kerberos tickets explicitly.

2. Reset KRBTGT twice. If there’s any sign of Golden Ticket usage (look for Event ID 4769 with unusual encryption types or very long ticket lifetimes), reset KRBTGT, wait for replication across all domain controllers, then reset it again. This invalidates any forged tickets in circulation.

3. Rotate service accounts. Every service account with elevated privileges needs a new password. Yes, this might break something. That’s a much smaller problem than leaving an attacker with a working credential.

4. Audit what changed in the directory. Don’t just look at the compromised account. Check for:

• New group memberships or changes to privileged groups
• Delegated rights and ACL modifications, especially on AdminSDHolder and domain root
• New user accounts or computer objects created during the compromise window
• Changes to Group Policy Objects

5. Check endpoints. Clearing cached credentials on laptops and remote systems matters, especially for accounts that may not reconnect to the domain for days or weeks.

---

Practical Takeaways

A few things I’d prioritise if you’re revisiting your IR runbooks in light of all this:

• Stop treating password resets as the finish line. They’re a starting point. Build session invalidation and Kerberos ticket purging into your default incident response playbook.
• Know where your service accounts are and what they can do. Run BloodHound or a similar AD enumeration tool regularly in a read-only mode to understand your privilege paths. If you don’t know which service accounts have SPNs registered, attackers do.
• Speed up your hybrid sync. In Entra ID hybrid setups, enabling AD Change Notification reduces the sync window from minutes to near-real-time. It’s a small config change that closes one of the gaps.
• Hunt for ACL changes post-incident. Most IR tools flag file system and process activity well. AD ACL changes are quieter and easy to miss unless you’re specifically looking.
• The KRBTGT reset is painful but sometimes necessary. It disrupts authenticated sessions across the domain. Do it when the evidence points to Kerberos ticket forgery. Don’t skip it to avoid the disruption.