Which logs show evidence of Kerberos ticket harvesting?

Where Kerberos ticket harvesting shows up in logs

kerberos ticket harvesting is usually detectable by stitching together domain controller security logs with host telemetry from the workstation or server where the ticket activity occurred. The useful clue is not a single event, but a pattern: abnormal ticket requests, repeated service ticket activity, and host-side signs that tickets were accessed, copied, or exported.

On the domain controller, focus on authentication and ticket issuance activity that is out of character for the account or source host. A sudden burst of ticket requests, especially when followed by lateral movement, is more important than any one event by itself. On the endpoint, look for process activity or memory access that coincides with ticket handling, because harvesting often leaves traces on the compromised system even when the attacker later uses the tickets elsewhere.

For defenders, the practical value is correlation. Ticket harvesting can look benign if you inspect only one telemetry stream, but the pattern becomes clearer when you line up Kerberos events, host process activity, and downstream access attempts from the same machine or identity. That is especially true when a workstation starts behaving like an authentication source rather than a normal user endpoint.

How to distinguish harvesting from normal Kerberos noise

Normal Kerberos use produces predictable traffic from known hosts, during known hours, for known services. Harvesting tends to break that rhythm. Watch for repeated service ticket requests that do not match the user’s usual application set, tickets requested from a workstation that does not normally act as a source of privileged authentication, and follow-on access to systems that the original user should not be reaching.

Another useful discriminator is sequence. Legitimate activity usually has a clear user action behind it, while harvesting often looks like enumeration, access, and reuse in quick succession. If the logs show ticket access or export activity and then a jump into administrative or cross-system access, treat that as a stronger indicator than isolated authentication events.

Do not overread one noisy endpoint. Service-heavy hosts, jump boxes, and admin workstations can generate many authentication events legitimately. The question is whether the ticket pattern aligns with the host’s role, the account’s normal behavior, and the timing of subsequent movement. When those three do not line up, the signal is much stronger.

What to correlate before you call it an incident

Start by tying domain controller logs to host telemetry and privilege-use records. That gives you the best chance of separating routine authentication from stolen-ticket use. If the host logs show unusual ticket access and the domain controller shows a burst of ticket activity from that same source, the next step is to see whether any lateral movement or privileged access followed shortly after.

Host telemetry matters because ticket harvesting often involves tooling or processes that leave traces outside the domain controller. If you can identify the source process, parent process, or suspicious access pattern on the compromised machine, you can tell whether the ticket activity was merely observed or actively manipulated. The strongest cases are the ones where all three layers align: authentication, host behavior, and post-harvest access.

For deeper Kerberos investigation and detection patterns, use the Kerberos Security Guide as the parent reference for ticket abuse, golden and silver ticket scenarios, and the event patterns that often sit next to harvesting activity. For adversary behavior mapping, the MITRE ATT&CK Enterprise Matrix is useful for connecting credential access and lateral movement into a broader intrusion timeline.

Risk and Threat Considerations

Ticket harvesting is dangerous because it can turn a single compromised endpoint into reusable authentication material. Once an attacker has usable tickets, they may be able to move laterally without repeatedly exposing obvious password theft signals, which makes detection slower and containment harder.

Failure mechanism: The attacker obtains kerberos ticket from memory, cache, or export activity on the compromised host, then reuses them to authenticate to other services or systems under the victim’s existing trust relationships.

Impact: The blast radius can expand quickly from one workstation to broader domain access, especially if the harvested tickets include access to administrative or high-value services.

Practitioner Guidance

What to verify: Confirm whether the source host actually had a legitimate reason to generate the observed Kerberos volume and whether the same account shows unusual service access immediately afterward. If the pattern is unusual but not yet confirmed as malicious, preserve the host evidence before rotating anything that could destroy investigative value.

Decision rule: If ticket access is paired with unexplained lateral movement or privileged service use, treat the event as a likely credential compromise and escalate quickly. If the host is a known admin endpoint, verify whether the behavior fits expected administrative tooling before assuming compromise.

Practitioner takeaway: Kerberos ticket harvesting is best confirmed by correlation, not by a single log line, and the fastest way to reduce uncertainty is to align domain controller activity with host-side evidence and the first downstream access that follows.

Related resources from NHI Mgmt Group

• How should security teams respond when authentication logs do not show enough detail to detect pass-the-ticket or forged Kerberos activity?
• Which logs show evidence of Kerberos Key List Attack?
• How should teams respond when a secret is found in a support ticket?
• Which logs show evidence of fast-flux DNS?