ExtraSIDs

How ExtraSIDs changes Kerberos authorisation

ExtraSIDs matter because Kerberos does not only rely on the user identity in the ticket, it can also honour additional security identifiers embedded in the ticket. If those identifiers are accepted during authorisation, the ticket can convey access as though the account belonged to groups or roles that were never legitimately assigned.

Why forged tickets with ExtraSIDs are dangerous

Attackers use ExtraSIDs to widen the effective privileges of a forged ticket without changing the visible account name. That makes the abuse harder to spot from a simple username check, because the real access decision is driven by the extra group SIDs carried inside the ticket and not just the principal that appears to be authenticating.

In practice, this is dangerous wherever authorisation logic trusts group membership claims from the ticket. A forged ticket can inherit administrative or delegated access, and the resulting privilege jump may look like an ordinary Kerberos session unless defenders inspect the ticket contents and the resulting access path carefully.

How organisations detect exposure to ExtraSIDs abuse

Exposure is usually confirmed by reviewing where Kerberos tickets are accepted for privileged authorisation, especially in environments that bridge trust boundaries or rely on transitive group membership. Asset inventory, domain trust review, and vendor or platform guidance help determine where ticket contents may influence access decisions beyond the intended account scope.

Defenders should also look for unusual privileged logons that do not match the known privileges of the originating account, and for authentication patterns that succeed without the expected administrative provisioning trail. MITRE ATT&CK Enterprise Matrix is useful here because it helps map credential access, privilege escalation, and lateral movement behaviours that often accompany forged-ticket abuse.

For control mapping and audit review, NIST SP 800-53 Rev 5 Security and Privacy Controls provides a structured way to examine authentication, access enforcement, and logging around the systems that consume Kerberos assertions.

Remediation and hardening after ExtraSIDs abuse

When ExtraSIDs abuse is suspected or confirmed, the response is not just to remove the malicious ticket. The underlying trust path, account privilege model, and any credentials or keys that enabled ticket forging need to be treated as compromised until proven otherwise.

That usually means constraining where privileged Kerberos material can be issued, tightening delegation and trust relationships, and reducing the number of accounts that can create or validate high-impact tickets. The best long-term control is to make ticket content less capable of silently expanding privilege beyond the real account’s assigned authority.

NIST Cybersecurity Framework 2.0 is useful for organising containment, recovery, and control improvement after a ticket-forgery incident, while NIST SP 800-207 Zero Trust Architecture reinforces the principle that access decisions should not rely on implicit trust in a ticket alone.

Risk and Threat Considerations

ExtraSIDs abuse is a privilege-escalation technique, so the main risk is not identity spoofing in the abstract, but unauthorised access that survives normal account-based review. If defenders trust the ticket too much, an attacker can carry extra group memberships into authorisation and obtain access that the underlying account should never have had.

Failure mechanism: A forged Kerberos ticket includes additional SIDs that the target system interprets as valid group memberships, so the access check succeeds against elevated privileges rather than the real account’s baseline rights.

Impact: The attacker can obtain administrative or domain-level capabilities, move laterally, and blend into apparently legitimate Kerberos activity while using privileges that were never assigned to the compromised identity.

Practitioner Guidance

What to watch for: Focus on any environment where ticket-derived group membership can influence high-value access decisions, especially across trusts, delegated administration paths, or systems with weak visibility into the ticket contents themselves. Privileged access should be validated against known entitlement state, not assumed from the apparent account name alone.

Governance implication: Ownership should sit with the teams that manage Kerberos trust, privileged accounts, and authorisation policy together, because ExtraSIDs is ultimately a cross-cutting identity and access control problem. The operational question is whether your environment can detect and contain privilege claims that arrive embedded in a forged ticket.