PAC and Silver / Golden Tickets

Why PACs and forged tickets matter

The PAC (Privilege Attribute Certificate) in a Kerberos ticket provides information that a service uses to decide access rights. If a PAC is forged, the service may create an access token with unintended privileges. Forging a ticket for a specific service is called a Silver Ticket attack; forging a TGT is called a Golden Ticket attack.

• A PAC contains more than group information; it also carries information used to create a token.
• Silver Tickets use a service key, while Golden Tickets use the krbtgt key.
• Their scopes differ, so the logs to check and the defenses to use differ as well.

Kerberos ticket basics

Kerberos issues a TGT through the AS (Authentication Service) and a service ticket for a specific SPN through the TGS (Ticket Granting Service). The client presents its TGT in a TGS-REQ and passes the returned service ticket to the service. The service decrypts the ticket with its own key, validates the PAC and Authenticator, and then asks LSA to create an access token.

Client --AS-REQ/REP--> KDC(AS)
Client --TGS-REQ/REP--> KDC(TGS)
Client --AP-REQ--> Service (validates the ticket and PAC)
Service --AP-REP(optional)--> Client

• TGTs are for use within the KDC; service tickets are specific to an SPN and use a service key.
• Services validate the PAC, Authenticator, and ticket expiration locally.
• LSA’s evaluation of the PAC and creation of a local access token form the authorization boundary.

How PACs work

Information in a PAC

A PAC is a signed bundle of user attributes and authorization context that a service uses to create an access token locally. The KDC creates it and embeds it in service tickets and TGTs. It is more than a list of SIDs: it is an “authorization certificate” with signing and validation requirements.

SIDs and logon information in a PAC

• User SID and Group SIDs: SIDs of groups the user belongs to, including domain local, global, and universal groups. Group information is included in the PAC; without it, the access token cannot be assembled.
• Extra SIDs: Additional SIDs attached through delegation or S4U. They represent the context of service delegation.
• Logon SID: A SID that uniquely identifies a logon session. It is used for auditing and session isolation.
• User flags / logon information: User type, logon type, and token restrictions, signed in accordance with Kerberos policy.

What is LSA?

• LSA (Local Security Authority) is the local security subsystem in Windows. It handles the local parts of Kerberos, NTLM, and SSPI, as well as policy evaluation.
• Its role is to perform PAC validation on behalf of the service, check signatures, evaluate SIDs, add or remove privileges, and generate an access token.
• LSA runs on each host rather than on a DC. The key point is that it judges PAC trustworthiness through local policy and signature validation.

From PAC to access token

• After validating the PAC signature, the service passes the PAC to LSA to generate an access token.
• LSA applies token filters (removing privileges or narrowing a token during constrained delegation) and evaluates user rights and privileges.
• It applies default privileges and filtering according to the logon type (Service, Network, Interactive, and so on).

PAC integrity checks and deciding which combinations are valid

• Dual signatures: A PAC has a KDC signature and a server signature. The service validates the KDC signature with the KDC public or shared key to check whether the PAC has been altered.
• SID origins and scope: The KDC calculates Group SIDs in the PAC from AD attributes such as tokenGroups. LSA examines SID scope (domain local, global, or universal) and trust boundaries to decide whether they are valid.
• Examples of invalid combinations
  • Using a Domain Local SID for a service in another domain when the SID is not valid outside its domain (it is invalidated as out of scope).
  • SIDHistory contradicting the current SID (LSA removes a privileged SID that appears only in SIDHistory).
  • A kvno mismatch or different generations of krbtgt and service keys causing signature validation to fail (for example, KRB_AP_ERR_MODIFIED).
  • A trust mismatch: A SID from outside the forest is invalidated when no trust exists.
  • A logon type mismatch: Privileges reserved for interactive logons are stripped from a Network logon.
• Cases that fail in practice or exercises
  • Adding Domain Admins (512) to a PAC does not necessarily provide full administrator rights because UAC or token filtering may remove privileges.
  • A service with a new kvno may fail to validate a PAC issued by an RODC or a DC using an old kvno.
  • A Silver Ticket with manually added SIDs may be rejected by additional service-side RBAC checks in SQL or SharePoint.

When adding a SID does not grant privileges

• Privilege filtering: Local policy or token restrictions can remove privileges such as SeTcbPrivilege.

• Group scope and role dependencies: Domain local SIDs are invalid in external domains; combinations of universal and global groups affect where rights apply.

• Service-specific validation: SQL Server and SharePoint may reevaluate database permissions or internal roles in addition to PAC SIDs, so adding a SID alone may not grant full administrator access.

• A PAC is a signed authorization context, with more meaning than a list of SIDs.

• LSA reevaluates the PAC and filters privileges, so added SIDs may be removed.

• The logon type and service-specific validation determine the final privileges.

Silver Ticket

Prerequisites for forging a service ticket

This attack obtains the NT hash / AES key of a service account (or computer account) and creates a service ticket for a specific SPN. The attacker can also construct the PAC freely.

Where validation happens

The forged ticket is passed directly to the service without going through a DC. The service decrypts it with its own key and only checks the PAC signature, which is why the attack can work without KDC signature validation.

Scope and detection

• Possible: Impersonate authentication to an SPN protected by the stolen service key and gain privileges according to the PAC.
• Not possible: Use it for other SPNs or gain the ability to issue TGS tickets for the whole domain.
• Detection difficulty: There is no DC log event 4769. Look for anomalies in service-side Security logs or errors such as KRB_AP_ERR_MODIFIED.

Defense and auditing

• Use gMSAs: Group managed service accounts with automatic rotation reduce the risk of stolen keys.

• Design services with least privilege: Avoid privileged service accounts and minimize local administrator rights.

• Monitor service logs: Even without event 4769, monitor application and service logs (IIS, SQL, SMB) and mismatch events.

• A service key enables forging a service ticket without involving a DC.

• The effect is limited to a specific SPN, but the PAC can be constructed freely.

• Service-side logs, key rotation, and least privilege are key to detection and defense.

Golden Ticket

Prerequisites for forging a TGT

This attack steals the domain’s krbtgt account key and forges a TGT with any user SID. Because the issuer appears to be the DC, TGS requests become unrestricted.

How it uses the KDC’s trust

The KDC treats krbtgt as the root of trust for the TGT signing key. If an attacker signs a TGT with the same key, the KDC accepts it as though the KDC had issued it and cannot reject subsequent TGS-REQs. This is a collapse of the authentication infrastructure’s trust boundary.

Scope and detection

• Possible: Create a TGT with any user or SID and obtain TGS tickets for all SPNs. Long-lived TGTs can also provide persistence.

• Not possible: Cross a forest boundary without obtaining a separate trust key. AES support is required where RC4 is disabled.

• Detection: Monitor large numbers of events 4768/4769, TGTs with unrealistic lifetimes, kvno mismatches, and rejection logs after krbtgt rotation.

• Obtaining the krbtgt key allows unrestricted TGT forgery and gives an attacker the same standing as a DC.

• TGS tickets can be requested for every SPN, affecting the whole domain.

• Detection centers on log anomalies, krbtgt rotation, and long-lived TGTs.

From Golden Tickets to Silver Tickets

Why the chain is used

An attacker can obtain a TGS using a Golden Ticket TGT, extract the service key from it, and produce Silver Tickets in quantity to move laterally without going through a DC. Even if krbtgt rotation invalidates the Golden Ticket, the stolen service key can keep Silver Tickets usable for persistence.

Steps in the chain

• Golden stage: Obtain the krbtgt key → forge a long-lived TGT with any SID → obtain a TGS for any desired SPN.

• Extract service key: Decrypt the obtained TGS or dump memory → steal the corresponding service account key.

• Produce Silver Tickets: Create Silver Tickets for specific SPNs with the stolen service key → move laterally or persist without going through a DC.

• Golden acts as a key to every SPN, while Silver acts as a lasting key to an individual SPN.

• If the service key remains after krbtgt access is lost, Silver Tickets can sustain activity.

• Breaking the chain requires rotating and monitoring both krbtgt and service keys.

Behavior seen in exercises

When Administrator can authenticate but has limited privileges

Even if SIDs are added to a PAC, LSA filters and UAC may remove privileges. Remote logons (Network logons) in particular may strip privileges such as SeTcbPrivilege, so some operations can be denied even to a local administrator.

When group SID 512 does not grant administrator rights

Adding 512 (Domain Admins) to a PAC does not always make the token an Owner or grant the expected privileges, due to how SIDHistory is handled and group scope restrictions. In addition, service-specific RBAC may check the PAC alongside other conditions, allowing elevation only for certain group sets.

Failures that look like domain errors

KRB_AP_ERR_MODIFIED or an error that resembles “invalid domain” can result from an SPN mismatch, failed PAC signature validation, or an inconsistency while assembling the token. It is important to check service-side event logs and klist output rather than looking only at the DC.

• Even after PAC modification, LSA and UAC may remove privileges, leaving fewer rights than expected.
• Adding SIDs alone may not bypass service-specific RBAC, causing inconsistent behavior.
• Many errors involve PAC signatures or SPN consistency and do not appear in DC logs.

Design and audit considerations

Kerberos delegates authorization to services on the assumption that the KDC signs the PAC. If the PAC trust boundary fails, the separation of authentication and authorization no longer holds. Design must account for that boundary and combine key management with monitoring.

• Define the boundary between authentication (KDC/PAC signing) and authorization (service/LSA tokens) and monitor both.
• “Protecting with AD groups” can fail when keys are stolen or PACs are forged, so combine key rotation with service-side RBAC.
• In practice, use gMSAs, least privilege, log monitoring, and regular rotation of krbtgt and service keys.