When organizations detect a compromised account, the instinct is immediate: reset the password. It's a logical first step, but in Active Directory (AD) environments, it often isn't enough to remove an attacker who has already established persistence. Analysis from Specops Software highlights how cached credentials, Kerberos tickets, and AD-specific attack paths can keep adversaries authenticated and active well after a password change.
The Problem with Password Resets Alone
A password reset invalidates the user's current password hash in Active Directory. What it does not automatically do is:
- Invalidate existing Kerberos Ticket Granting Tickets (TGTs) already issued to the attacker's session
- Clear cached credentials on workstations or servers where the account has previously authenticated
- Revoke NTLM hashes stored in Windows Credential Manager or LSA secrets on remote systems
- Terminate active RDP or SMB sessions where a token is still valid
This creates a window — sometimes hours, sometimes much longer — where an attacker can continue operating under the old session context even after the password is changed.
Kerberos Ticket Lifetime
Kerberos TGTs have a default lifetime of 10 hours in most Active Directory configurations, with a renewal period of up to 7 days. Once issued, a TGT authenticates the holder to services across the domain without re-querying the domain controller for credentials. An attacker who has obtained a TGT — through Pass-the-Ticket, credential harvesting, or legitimate compromise — can continue using it until it expires, regardless of the underlying password being changed.
What defenders need to do:
- Force Kerberos ticket invalidation by using
klist purgeon affected systems or via Group Policy to set shorter ticket lifetimes - Enable Kerberos Armoring (FAST) to protect tickets from offline cracking
- Audit for
4769(Kerberos Service Ticket Operations) events in the Security log for anomalous ticket requests
Cached Credentials and Pass-the-Hash
Windows systems cache domain credential hashes locally to allow logon when the domain controller is unreachable. These cached hashes — stored in the registry under HKLM\SECURITY\Cache — persist until overwritten. An attacker with local admin access can extract these hashes with tools like Mimikatz and use them in Pass-the-Hash (PtH) attacks against other systems, even after the original password is reset.
NTLM authentication doesn't require the attacker to know the plaintext password — the hash alone is sufficient to authenticate. Until cached credentials are cleared from every affected endpoint, the attacker retains lateral movement capability.
Golden and Silver Tickets
For attackers who achieve Domain Admin access, the threat extends further. A Golden Ticket attack — using the KRBTGT account's hash to forge arbitrary Kerberos tickets — persists until the KRBTGT password is rotated twice (because older domain controllers may still accept tickets signed with the previous hash). A single KRBTGT password reset is insufficient.
Silver Tickets, forged for specific services using a service account's hash, are harder to detect and are not validated against the domain controller at all, making them particularly persistent.
What a Thorough Remediation Looks Like
A genuine Active Directory breach remediation requires more than a password reset. Security teams should:
- Identify all systems the compromised account authenticated to using DC Security logs (Event ID 4624, 4625, 4648)
- Clear cached credentials from affected endpoints via Group Policy or endpoint management tools
- Force Kerberos ticket expiration by temporarily setting the domain maximum ticket lifetime to a very short value
- Rotate the KRBTGT password twice if any Domain Admin-level compromise is suspected
- Audit service account SPNs for signs of Kerberoasting — service tickets for sensitive accounts should be reviewed
- Review privileged group membership (Domain Admins, Enterprise Admins, Schema Admins) for unauthorized additions
Password hygiene matters, but in Active Directory environments, it is only one layer of a multi-step incident response. Organizations that treat a password reset as closure risk leaving attackers with an extended window of opportunity.