Resetting a password doesn't always remove attackers from Active Directory. Learn how cached credentials and Kerberos tickets can keep attackers authenticated and what you can do to actually kick them out.
You just reset a compromised user's password. You breathe a sigh of relief, thinking the attacker is locked out. But here's the uncomfortable truth: that password change alone might not kick them out of your Active Directory environment. Attackers are crafty, and they have multiple ways to hold on.
Think of it like changing the locks on your front door while someone is already sitting in your living room. The locks are new, but the uninvited guest is still inside. In the digital world, cached credentials and Kerberos tickets act like that guest—they give attackers a way to stay authenticated even after you've rotated the password.
### Why a Simple Password Reset Isn't Enough
Active Directory doesn't just rely on passwords. It uses a system of tickets and tokens to keep sessions alive. When a user logs in, the domain controller issues a Kerberos ticket-granting ticket (TGT). This ticket is valid for a set period, often hours or even days, depending on your policy.
Resetting the password invalidates the user's password hash, but it doesn't automatically revoke those existing tickets. If an attacker has already obtained a valid TGT, they can continue using it until it expires. They can also request new service tickets without needing to know the new password. It's a loophole that many security teams overlook.
### Cached Credentials: The Silent Persistence
Another trick attackers use is cached credentials. Windows machines store a local copy of recent user credentials to allow logins when the domain controller is unavailable. If an attacker has physical or remote access to a machine, they can extract these cached hashes using tools like Mimikatz.
Even after a password reset, those cached hashes remain valid on the local machine until the user logs in again and updates the cache. An attacker who already has a foothold can use these cached credentials to move laterally or escalate privileges, all while you think the breach is contained.
- Kerberos tickets can live for hours or days after a password change
- Cached credentials on local machines persist until the user logs in again
- Attackers use tools like Mimikatz to extract and reuse these artifacts
### What You Can Do to Actually Kick Attackers Out
A password reset is a good start, but it's not the finish line. You need a multi-step response. First, force a full logout of all user sessions. This invalidates any active Kerberos tickets tied to that account. Next, require users to log in again from a clean machine to refresh their cached credentials.
You should also consider implementing a script that clears cached credentials on all endpoints. This ensures that any stored hashes are removed, not just overwritten. Finally, audit your Kerberos ticket lifetimes. Shortening them from 24 hours to 4 hours reduces the window of opportunity for attackers.
> "A password reset is like changing the oil in a car that's on fire. It helps, but you need to address the actual fire first." — This analogy from a security veteran captures the gap between what we think works and what actually works.
### Practical Steps for Your Incident Response Plan
Here's a quick checklist to integrate into your breach response:
- Revoke all Kerberos tickets for compromised accounts using the `klist purge` command or a domain-wide script
- Force logoff of all user sessions via Group Policy or remote management tools
- Clear cached credentials on all workstations using `rundll32.exe keymgr.dll, KRShowKeyMgr` or a script
- Shorten Kerberos ticket lifetimes to 4 hours or less during active incidents
- Monitor for anomalous use of old tickets with SIEM alerts
These steps take more effort than a simple password reset, but they close the gaps that attackers exploit. In a real breach, every minute counts. Don't let a half-measure give the adversary a second chance.
### The Bottom Line
Active Directory is a complex beast, and attackers know its weaknesses better than most admins. Password resets are a necessary first step, but they're not a silver bullet. By understanding how Kerberos tickets and cached credentials work, you can build a response that actually works.
Next time you handle a breach, remember: change the password, but also purge the tickets, clear the cache, and force a fresh login. That's how you truly end the attack.
