Password Resets Alone Won't Evict Attackers From Active Directory

The Reset Button Isn't a Kill Switch

When an Active Directory account gets compromised, the instinctive response is to reset the password and move on. It feels decisive. It isn't. The BleepingComputer piece surfacing research from Specops Software makes the mechanics explicit, and every operator running a Windows environment should internalize this before their next incident response call.

Why Kerberos Tickets Outlive the Reset

Kerberos tickets are issued at authentication time and carry their own validity window — typically ten hours for a Ticket Granting Ticket (TGT), with possible renewal up to seven days in default configurations. When you reset a password, you are not invalidating tickets that have already been issued. An attacker sitting on a compromised host with a valid TGT can continue requesting service tickets and moving laterally for the remainder of that ticket's lifetime. The password change happened in the directory; the attacker's session didn't get the memo.

This is not a theoretical edge case. It is the default behavior of Kerberos. Defenders who reset a password and then stand down are handing attackers a window to complete their objectives — whether that's dumping more credentials, establishing persistence, or exfiltrating data.

Cached Credentials Are a Separate Problem

Beyond live tickets, Windows caches domain credential hashes locally by default (typically the last ten logons). These cached credentials exist specifically so users can log in when a domain controller is unreachable. For attackers, they represent a secondary foothold that survives a password reset entirely. If an adversary has already extracted those cached hashes — through tools that target the SECURITY registry hive, for instance — they can attempt offline cracking at their own pace. The new password you just set doesn't touch those cached hashes; they reflect the credential state at the time of the last successful domain authentication.

What a Complete Remediation Actually Looks Like

A proper eviction from a compromised AD environment requires several coordinated steps that go well beyond a single password reset:

• Purge active Kerberos tickets on the affected account. The klist purge command works on the client side, but for a genuine incident you want to force ticket invalidation domain-wide. Resetting the password twice in quick succession is a common technique to trigger TGT invalidation, because the Kerberos protocol ties ticket validity to the NT hash of the password — two rapid resets are more reliable than one.
• Review and reduce cached credential count via Group Policy (Interactive logon: Number of previous logons to cache). Lowering this to zero on sensitive systems — jump boxes, domain controllers, privileged admin workstations — removes the cached hash attack surface entirely.
• Audit for persistence mechanisms before you declare the account clean. Password resets and ticket purges address authentication artifacts, not backdoors. Check for new scheduled tasks, service installations, added members in privileged groups, and modifications to AdminSDHolder or delegation settings.
• Treat the endpoint as compromised, not just the account. If an attacker had enough access to capture credentials, assume the host is dirty. Reimaging is the only reliable remediation for the endpoint itself.
• Review KRBTGT if there is any possibility the attacker reached a domain controller. A compromised KRBTGT key means Golden Ticket attacks remain viable regardless of any user-level password reset. The standard guidance is to reset KRBTGT twice, spaced by the replication interval.

The Broader Operational Takeaway

The mental model of "reset password = problem solved" is dangerous precisely because it creates false confidence. Incident responders close the ticket, leadership gets told the breach is contained, and the attacker — still holding a valid TGT or a crackable cached hash — continues working. We see this pattern repeatedly in post-incident reviews.

Active Directory's authentication architecture was designed for availability and interoperability, not for instant revocation. That's not a flaw you can patch away; it's a design characteristic you have to account for in your incident response playbooks. If your IR runbook doesn't have explicit steps for Kerberos ticket invalidation and cached credential review, update it before you need it.

The full Specops-sourced breakdown is worth reading for the technical specifics: Why Changing Passwords Doesn't End an Active Directory Breach — BleepingComputer