What are the key Sapphire Ticket best practices?

What Sapphire Ticket Best Practices Are Really Trying to Stop

Sapphire Ticket abuse sits in the same family as other Kerberos ticket forgery and replay problems: an attacker is trying to turn trusted ticket material into durable access. The practical goal is to make ticket issuance, delegation, and use narrow enough that abnormal service-ticket behaviour stands out quickly, while privileged systems are harder to abuse at scale.

The control objective is not just “detect Kerberos abuse.” It is to reduce the number of places where ticket material can be minted, delegated, forwarded, or replayed, because that is what makes ticket-based persistence and lateral movement viable in the first place. Kerberos Security Guide is the most direct reference point for the ticket abuse path behind this question.

For teams that need a broader response lens, the Identity Threat Detection and Response (ITDR) Guide is useful because Sapphire Ticket defence is not only about Kerberos settings, it is also about detecting identity abuse patterns, ticket replay, and suspicious use of trusted accounts across the environment.

Harden the Kerberos Paths That Make Ticket Abuse Possible

The most effective Sapphire Ticket practices start with tightening the accounts and systems that can issue or consume privileged Kerberos material. That means limiting delegation to only the systems that genuinely need it, reducing standing privilege on administrative accounts, and ensuring domain controllers and supporting identity infrastructure are not overexposed. If an account can request, forward, or reuse ticket material broadly, the attack surface expands fast.

Pay special attention to service accounts and other high-value principals that can authenticate across many hosts. Their permissions, delegation settings, and logon behaviour should be treated as part of the Kerberos control plane, not as ordinary application configuration. A broad trust relationship is often the real weakness, because it lets forged or replayed tickets move farther than defenders expect.

• Restrict delegation to approved use cases only.
• Reduce privilege on accounts that can request or present Kerberos material.
• Review where privileged service accounts can authenticate and what they can reach.
• Protect domain controllers and identity logs as high-value detection assets.

Detect Ticket Abuse by Watching for Strange Service-Ticket Behaviour

Sapphire Ticket abuse is most visible when ticket use does not match normal service patterns. That includes unusual service-ticket issuance, tickets being used across systems that do not normally share trust relationships, unexpected reuse of privileged principals, and log activity that does not line up with the normal authentication cadence for the account or host.

Detection should focus on the combination of account, service, host, and timing. One suspicious ticket event can be noise, but repeated service-ticket use across unexpected systems, especially involving privileged identities or remote administrative paths, is much more meaningful. Defenders should also look for gaps in logging on domain controllers and adjacent systems, because weak visibility makes ticket abuse much harder to separate from legitimate Kerberos traffic.

When you are validating telemetry coverage, the Kerberos Security Guide helps map the ticket events and abuse patterns that matter most, while the Identity Threat Detection and Response (ITDR) Guide is useful for shaping investigation and response around identity compromise indicators rather than isolated alerts.

Practitioner Guidance

What to prioritise: Treat privileged Kerberos paths as a high-risk trust boundary. If a service account, delegation path, or domain controller logging gap can let ticket abuse persist unnoticed, fix that before chasing edge-case tuning.

What to verify: Confirm that you can distinguish normal service-ticket use from abnormal reuse across hosts and services, and that the teams responsible for identity infrastructure can actually investigate those events without relying on incomplete logs.

Common mistake: Teams often harden endpoints but leave delegation, service-account scope, and ticket observability too broad. That leaves the abuse path intact even when the surrounding systems look well controlled.

Practitioner takeaway: The strongest Sapphire Ticket defence is narrow trust plus strong visibility: reduce where Kerberos material can be delegated or reused, then make abnormal ticket behaviour obvious enough to investigate quickly.

Related resources from NHI Mgmt Group

• What are effective practices for operationalizing NHI threat detection?
• How should teams respond when a secret is found in a support ticket?
• What are the key privileged account best practices?
• What are the key model explainability best practices for fraud?