Logs that show evidence of a Kerberos Key List Attack are Kerberos and domain controller logs that record unusual ticketing activity, repeated service ticket requests, or access patterns consistent with offline key discovery. Because the exact signals depend on platform and auditing settings, correlate authentication events with changes in account behaviour and suspicious use of privileged service identities.
What a Kerberos key list attack leaves behind in logs
A kerberos key list attack is usually visible as a pattern, not a single event. The most useful logs are Kerberos authentication records and domain controller logs that show repeated ticket activity, abnormal service ticket requests, or access behavior that does not fit the account’s normal use. The key question is whether the sequence suggests offline key discovery or later abuse of the same identity path.
In practice, investigators look for ticket requests that spike without a matching business reason, requests that target many services in a short period, or authentication changes that appear after the suspicious ticketing sequence. Correlating those events with account behavior gives context, because the attack often becomes clearer when you compare what the account usually does with what the logs suddenly show.
Kerberos logs are most valuable when they are read alongside domain controller auditing and account activity telemetry. That combination helps distinguish routine service use from enumeration-style behavior, repeated retries, and suspicious access against privileged service identities. For broader Kerberos hunting patterns, the Kerberos Security Guide covers ticket abuse patterns that often sit in the same detection surface.
Why the ticket trail matters more than one event ID
A single log line rarely proves a key list attack. What matters is the relationship between authentication, ticket issuance, and subsequent account behavior. If a service account starts requesting tickets in an unusual volume, at unusual times, or against unusual services, that can indicate the attacker has moved from discovery to practical use of Kerberos material.
This is why investigators should not overfocus on one platform-specific audit event. Different environments expose different detail, but the core pattern is consistent: unusual ticketing, repeated access attempts, and privileged service identities behaving outside their baseline. The evidence becomes stronger when those signals line up with a second change, such as a new host, a different source address, or an increase in access against sensitive services.
When logs are incomplete, the answer is not to guess from a single indicator. Instead, correlate the directory source, the service being requested, and the identity that made the request. If the account is privileged or broadly trusted, the same event pattern has higher impact because abuse of that identity can reach deeper into the environment.
That is also why a Kerberos-focused investigation often needs to move outward from the ticket trail to the account lifecycle. A suspicious sequence may reflect credential exposure, service-account misuse, or earlier compromise of the host that holds the relevant material. The logs tell you where to start, but the account context tells you how serious it is.
How to validate suspicion without overcalling normal traffic
The practical test is whether the activity is explainable by the service’s real workload. Scheduled jobs, clustered services, and high-traffic applications can generate heavy Kerberos activity without being malicious, so the investigator needs a baseline for normal volume, source systems, and timing. Unusual ticket repetition only becomes actionable when it departs from that baseline in a way the business cannot justify.
Look for whether the same identity is making repeated requests across multiple hosts, whether the pattern is concentrated around high-value services, and whether the activity is followed by new access to systems the account does not usually touch. That progression matters because key discovery alone is noisy, but discovery followed by meaningful access is a stronger sign that the attack path succeeded.
For organizations that want a broader control view, the audit trail should preserve enough detail to reconstruct who requested what, from where, and when. A good review process should also preserve timestamp alignment across domain controllers, authentication logs, and endpoint telemetry so that ticketing anomalies can be tied back to the initiating system.
Risk and Threat Considerations
Kerberos key list attacks are risky because they can look like ordinary authentication volume until the attacker starts using the recovered material. If the logs are sparse, delayed, or not correlated, defenders may miss the transition from probing to abuse, especially when a privileged service identity is involved.
Failure mechanism: Attackers exploit repeated ticket requests and related authentication behavior to infer or validate Kerberos secrets, then reuse the same identity path for unauthorized access or lateral movement.
Impact: A successful attack can expose privileged services, increase the blast radius of a single compromised account, and create follow-on access that blends into normal Kerberos traffic.
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 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1558 — Steal or Forge Kerberos Tickets | Directly covers Kerberos ticket abuse and discovery behavior. |
| Recommendation — Map suspicious ticket patterns to T1558 and hunt for Kerberos abuse paths in logs. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Log correlation and anomaly review are central to spotting the attack pattern. |
| IA-5 — Authenticator Management | Kerberos abuse often indicates compromised or mismanaged authentication material. | |
| AC-2 — Account Management | Privileged service identity misuse makes account governance material to the investigation. | |
| Recommendation — Correlate Kerberos and domain controller logs under AU-6 to detect abnormal ticket activity. Review credential lifecycle controls under IA-5 when ticket activity suggests secret exposure. Validate and constrain suspicious service accounts under AC-2 before further abuse occurs. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | The answer depends on collecting and correlating log evidence. |
| Recommendation — Centralize and review Kerberos-relevant logs under CIS-8 for detection and investigation. | ||
Practitioner Guidance
What to verify: Confirm that Kerberos and domain controller logs are retained long enough to compare ticket activity with account baseline, source host, and follow-on access. If you cannot reconstruct the sequence, the detection value drops quickly.
What to prioritize: Start with privileged service identities, accounts with unusual ticket volume, and any identity whose behavior changed before suspicious access appeared. Those cases are more likely to matter than isolated noise from a busy but ordinary service.
Decision rule: If the ticket pattern is paired with unexpected service reach, treat it as potential compromise and move to containment and credential review rather than waiting for a perfect proof point.
Practitioner takeaway: The most useful evidence is not just “Kerberos activity,” but a believable sequence of abnormal ticketing, identity drift, and later access that the account should never have needed.