Join our Newsletter — 33% off our NHI Course

Kerberos Ticket Purging

Kerberos ticket purging is the process of removing cached Kerberos tickets from a device or user session. It forces the next authentication to request fresh tickets from the Kerberos Key Distribution Centre, which helps cut off continued access after password changes, account disablement, or suspected ticket misuse.

What Kerberos ticket purging does

kerberos ticket purging clears locally cached tickets so the next sign-in or service access must obtain fresh credentials from the Kerberos Key Distribution Centre. That breaks dependence on tickets that may still be usable after a password change, account disablement, or suspected misuse.

The key operational value is that purging changes the trust anchor from a possibly stale client cache back to live directory authentication. In practice, that makes it a containment step, not a fix for the root cause of compromise.

When purging helps and what it does not do

Ticket purging is most useful when an administrator needs to invalidate a user or host’s cached access quickly, especially after a suspected ticket theft, a password reset, or a session that should no longer remain authenticated. It is also useful when troubleshooting inconsistent logon behaviour caused by stale tickets.

It does not revoke tickets already issued to other devices, and it does not replace changes at the account, key, or delegation layer. If an attacker already holds a forged ticket, simply clearing one cache may leave other footholds intact until broader remediation is completed.

For that reason, purging is best treated as one part of a response sequence, alongside account review, ticket lifetime review, and validation that the underlying principal and Kerberos settings are still trustworthy.

How organisations check exposure

Exposure is usually determined by where Kerberos is used, which devices still hold cached tickets, and whether the account or session in question has already been changed in directory services. Administrators should verify the affected endpoint, the user session, and any services that may continue to accept older Kerberos material.

This is especially important in Windows environments where ticket caches can survive until logoff or reboot, and where administrators may need to confirm whether the cached ticket is merely stale or was part of a larger compromise pattern. The Kerberos Security Guide is a useful broader reference for the surrounding attack paths and defensive context.

Because stale Kerberos material often intersects with ticket forgery, delegation, and domain controller telemetry, teams should also correlate what they see on the endpoint with authentication events and directory change activity.

Remediation and verification after purging

Purging should be followed by a deliberate validation step: confirm the next authentication really does request fresh tickets, then check whether access resumes only under the expected account state. If access continues unexpectedly, the issue is no longer just cached tickets and should be treated as a deeper trust problem.

In compromise cases, responders often need to look beyond the local cache and assess whether ticket issuance material, service credentials, or account state has been abused elsewhere. The Golden Ticket, Silver Ticket and DCSync Guide and the MITRE ATT&CK T1558 Steal or Forge Kerberos Tickets Guide both help frame what to investigate when ticket misuse may be involved.

Where the goal is full recovery after suspected ticket abuse, administrators should also review the account used to issue Kerberos tickets and validate whether additional resets or directory-side containment are needed. The krbtgt account guide covers the deeper reset path that becomes relevant when forged tickets are suspected.

Detection and ongoing operational use

Purging itself is not usually the primary detection signal. Instead, it is a response action that should be paired with telemetry showing unusual ticket requests, unusual service access, or signs that a session continues to behave normally after it should have been cut off.

Operations teams often use ticket purging as a way to separate cache artefacts from genuine persistence. If access vanishes after purging, the problem may have been limited to the client cache; if the same access reappears through fresh authentication, the underlying account or trust relationship remains exposed.

That distinction matters because it tells defenders whether they are dealing with stale session material or an active compromise path that needs broader identity and directory remediation.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
MITRE ATT&CK T1558 — Steal or Forge Kerberos Tickets Kerberos ticket purging is a response to ticket theft and forgery paths.
Recommendation — Map suspicious Kerberos activity to T1558 and investigate for stolen or forged ticket use.
NIST SP 800-53 Rev 5 IA-5 — Authenticator Management Ticket purging depends on controlling credential and ticket lifecycle after compromise.
IA-9 — Service Identification and Authentication Kerberos tickets authenticate services and hosts through machine and service trust relationships.
AU-6 — Audit Record Review, Analysis, and Reporting Ticket purge events should be correlated with authentication logs and suspicious reuse.
Recommendation — Review IA-5 handling to ensure expired or compromised Kerberos material is removed promptly. Apply IA-9 to validate service authentication paths that depend on Kerberos tickets. Use AU-6 to correlate purge activity with anomalous logons and ticket requests.