Why is a Diamond Ticket more difficult to detect than a classic forged Kerberos ticket?

A Diamond Ticket is harder to detect because it begins with a legitimate ticket request and then modifies the resulting ticket, rather than building everything from scratch. That means expected fields such as ticket timing are more likely to look normal. Defenders lose some of the obvious anomalies that traditional forged tickets expose, so detection has to focus on surrounding compromise activity and authentication patterns.

Why Diamond Tickets Blend Into Normal Kerberos Behaviour

A classic forged Kerberos ticket is often produced offline, so defenders can spot mismatches between the forged structure and the environment that issued it. A Diamond Ticket starts from a real ticket request path and then alters the result, which preserves more of the normal shape of authentication and makes simple anomaly checks less reliable.

The practical difference is that the ticket inherits more of the context defenders expect to see: plausible timestamps, issuer characteristics, and a request flow that resembles ordinary authentication. That does not make it invisible, but it reduces the number of obvious structural defects that stand out in a fully fabricated ticket.

In detection terms, the problem shifts from “does this ticket look fake?” to “does this ticket sit inside a suspicious authentication sequence or post-compromise pattern?” That means defenders need surrounding telemetry, not just ticket inspection, to build confidence.

What Classic Forged Tickets Expose That Diamond Tickets Hide

Classic forged tickets tend to fail in places that are easy to inspect: field consistency, timing, issuance context, and other artefacts that do not line up with normal Kerberos flow. Because the attacker manufactures the ticket outright, the resulting object often lacks the subtle environmental cues that a legitimate request produces.

Diamond Tickets narrow that gap by using the legitimate request as the starting point. The attacker is no longer relying only on a synthetic artefact, so the ticket may look more compatible with the realm’s normal patterns even though it is still being abused. That is why a detector tuned only to “impossible” ticket properties usually performs better on classic forgeries than on this variant.

For defenders, this means the ticket itself becomes a weaker source of truth. The better question is whether the authentication event came from an account, host, or session that should have been capable of producing that request in the first place.

What Detection Has to Look At Instead

When the ticket artifact is less distinctive, detection has to move outward to the environment around it. The most useful signals are unusual account behaviour, privileged logon patterns, host-to-host relationships, ticket issuance timing, and follow-on activity that suggests an attacker is using legitimate authentication to support later steps.

That is why Kerberos abuse analysis is stronger when it includes correlated telemetry such as authentication logs, service access, privilege changes, and lateral movement indicators. The ticket may appear normal in isolation, but the broader sequence often still reveals compromise pressure. In practice, this is a correlation problem as much as a protocol problem.

For that reason, ticket-focused detections should be treated as one layer in a broader detection strategy, not the whole answer. The more the attacker can reuse valid protocol behaviour, the more important it becomes to inspect surrounding authentication patterns and the downstream actions taken with that access.

Risk and Threat Considerations

Diamond Tickets matter because they reduce the reliability of simple forgery detection and increase the chance that a malicious authentication event blends into normal Kerberos traffic. That creates a real window for persistence, privilege use, and lateral movement if defenders rely too heavily on ticket structure alone.

Failure mechanism: The attacker anchors the ticket in a legitimate request path, which preserves enough expected context to bypass detectors that mainly look for obviously synthetic ticket artefacts.

Impact: Compromise can persist longer before detection, and the attacker may gain more time to use the ticket for access, movement, or escalation before an investigation focuses on the surrounding account activity.

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 CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
MITRE ATT&CK	T1550 — Use Alternative Authentication Material	Kerberos ticket abuse is an authentication-material technique.
Recommendation — Map suspicious ticket reuse to T1550 and correlate it with lateral movement or privilege use.
NIST CSF 2.0	DE.CM-01 — Networks and network services are monitored to find anomalies, indicators of compromise, and other potentially adverse events	Diamond Tickets require surrounding telemetry and anomaly detection beyond the ticket itself.
	DE.AE-02 — Potentially adverse events are analysed to better understand attack targets and methods	The technique is detected by analysing the authentication sequence, not only the ticket artifact.
Recommendation — Monitor authentication and service access events for deviations from normal Kerberos patterns. Analyze suspicious Kerberos activity in context to distinguish valid issuance from abuse.
NIST SP 800-53 Rev 5	AU-6 — Audit Record Review, Analysis, and Reporting	Kerberos abuse is best found by reviewing correlated authentication and access logs.
	IA-5 — Authenticator Management	Ticket abuse exploits authentication material and its lifecycle of issuance and use.
Recommendation — Correlate Kerberos and access logs to identify anomalous ticket issuance and use. Harden credential and ticket lifecycle controls to reduce abuse of valid authentication paths.

Practitioner Guidance

What to verify: Treat ticket validation as incomplete unless you can also explain the requesting account, source host, timing, and subsequent access chain. If those pieces do not line up, the ticket deserves investigation even when it looks structurally normal.

What practitioners underestimate: The hardest part is not recognising a forged ticket pattern, but proving that the authentication path itself was legitimate. If your detection logic does not connect ticket events to account behaviour and host context, Diamond Ticket activity can look innocuous long enough to matter.

Practitioner takeaway: With this technique, the decisive signal is usually not the ticket object alone, but the surrounding authentication story and the post-authentication behaviour that follows it.