Kerberos Ticket Harvesting

How Kerberos Ticket Harvesting Works

kerberos ticket harvesting happens after an attacker gains access to a system that already holds valid tickets, often in memory or local caches. The attacker’s goal is to collect those tickets for later use, because a stolen ticket can sometimes stand in for the original user or service without needing the password again.

This makes the technique especially useful after the initial compromise phase. It turns one successful foothold into a reusable authentication asset, which can extend access beyond the original host and increase the value of a single intrusion.

Why Stolen Kerberos Tickets Are Valuable

Kerberos tickets are bearer-like proof that a principal has already authenticated, so they can be abused for impersonation until they expire or are invalidated. In practice, this means an attacker may use the ticket to access services, move laterally, or blend in with normal domain activity while avoiding repeated password prompts.

The technique is closely related to lateral movement and privilege reuse because the ticket often inherits the permissions of the identity that obtained it. If that identity is privileged, the harvested ticket can expose far more than one account, especially in environments where delegated access or long-lived sessions are common.

Kerberos security discussions often include this family of abuse paths together, and Kerberos Security Guide is the most direct reference for understanding how ticket abuse fits into the broader Kerberos attack surface.

How Organisations Check Exposure

Exposure starts with knowing where Kerberos tickets may be captured or reused. High-value endpoints, admin workstations, servers with interactive sessions, and hosts that store credentials or tickets in memory deserve the closest review, along with any systems that trust delegated authentication paths.

Organisations should also check whether unusual Kerberos activity is being logged and retained well enough to investigate. That includes spikes in ticket requests, odd service access patterns, repeated use of the same ticket material, and signs that privileged accounts are authenticating from unexpected hosts or at unexpected times.

Vendor guidance and platform hardening advice matter here because ticket harvesting is usually enabled by broader host compromise, poor session hygiene, or weak privilege segmentation. The question is not only whether Kerberos is enabled, but whether the surrounding systems make ticket theft easy to perform and hard to notice.

Detection, Containment, and Recovery

Detection usually focuses on the compromise chain rather than the ticket itself. Endpoint telemetry, memory inspection, and authentication logs can reveal suspicious ticket access, repeated delegation use, or a sudden shift from normal user activity to adversary-like lateral movement.

Containment depends on limiting where tickets can be stolen and how far they can travel. Short ticket lifetimes, strong protection for privileged workstations, tighter delegation rules, and reduced standing access all help shrink the usable window for harvested tickets.

When exploitation is suspected, organisations should assume the ticket material may no longer be trustworthy and review adjacent identity material as well. That often means rotating the affected account credentials, checking for additional authenticated sessions, and validating that no post-compromise persistence was established through reused ticket access.

What Makes Ticket Harvesting Hard to See

Kerberos ticket harvesting is dangerous because it often looks like legitimate authentication reuse. The attacker is not always breaking the protocol, they are abusing valid artifacts that were already issued, which makes the activity easier to hide inside ordinary traffic and access patterns.

That is why the most important defensive signal is context. A ticket that is normal on a known admin host may be suspicious on a workstation that should never hold one, and delegation activity that is expected for one service can be a strong indicator of compromise when it appears elsewhere.

Risk and Threat Considerations

Harvested Kerberos tickets can let an attacker bypass password-based controls, extend access after the initial compromise, and move laterally with stolen trust. The main risk is not just unauthorized access, but the way one captured ticket can preserve access long enough to support broader domain compromise.

Failure mechanism: The attacker steals valid ticket material from memory or a cache, then replays it or uses it for access before the ticket expires or is invalidated. If privileged systems are exposed, the stolen ticket can become a stealthy path to higher-value services and additional accounts.

Impact: Organisations may face unauthorized service access, credential-less impersonation, persistence across sessions, and faster lateral movement. In a privileged environment, a single harvested ticket can become a launch point for wider identity compromise.

Practitioner Guidance

What to watch for: Prioritise hosts that handle privileged sessions, delegation, or long-lived interactive use, because those are the environments where ticket material is most likely to be useful to an attacker. Watch for authentication patterns that do not fit the normal host, user, or service relationship.

Governance implication: Treat ticket protection as part of access design, not just incident response. Reducing ticket lifetime exposure, narrowing delegation, and protecting privileged systems are governance decisions that materially change the attack surface for this technique.

Practitioner takeaway: If a host can hold a useful Kerberos ticket, assume it can also become a replay point unless you have hard controls and reliable detection around it.

Related resources from NHI Mgmt Group

• What is the difference between a normal Kerberos ticket issue and a Golden Ticket attack?
• Who is accountable for monitoring suspicious Kerberos ticket requests across forest trust paths?
• Who is accountable for limiting the impact of Kerberos ticket theft?
• What is the difference between protecting Windows logon with MFA and protecting the underlying Kerberos ticket request?