The Diamond Ticket attack represents a sophisticated escalation in Active Directory (AD) exploitation methods, leveraging intricate flaws in Kerberos authentication and authorization mechanisms. This article explores the technical nuances of the Diamond Ticket attack, delving deeply into the underlying mechanisms, the role of Privilege Attribute Certificates (PACs), and the root causes that make AD environments susceptible. We conclude with detailed detection and mitigation strategies to protect against such threats.

Table of Contents

• Introducing- Diamond Ticket
• Attack Machnism
• Ticket Structure
• PAC Validation
• PAC Validation Limitation
• Prerequisites for Attack
• Remotely Diamond Attack -Linux
• Locally Diamond Attack-Windows
• Detection Techniques
• Mitigation Strategies

Introducing- Diamond Ticket

A Domain PAC (Privilege Attribute Certificate) attack is a type of Kerberos abuse where an attacker forges or manipulates the PAC within a Kerberos ticket to gain unauthorized access or escalate privileges in a domain environment. The attack leverages the fact that many services trust the PAC without verifying its authenticity or validating it with the Key Distribution Center (KDC).

The Diamond Ticket attack is indeed a form of exploiting and abusing the Kerberos trust by manipulating Kerberos Tickets (specifically the TGTs and the PAC) in a way that allows attackers to forge tickets and escalate their privileges in the Active Directory domain.

Attack Machnism

The attacker manipulates or forges the PAC to include elevated privileges or fake group memberships (e.g., “Domain Admins”).

A forged ticket with the modified PAC is then sent to the target service.

In the Diamond Attack, the attacker leverages the KRBTGT AES hash to decrypt a valid TGT (Ticket Granting Ticket) and modify the PAC (Privilege Attribute Certificate) inside the TGT before re-encrypting the modified TGT with the KRBTGT AES hash again to make it appear legitimate.

This attack is essentially a TGT modification attack. The attacker doesn’t need to steal the original TGT or create a completely new one; they simply manipulate the PAC within an existing TGT.

Steps Involved in the Diamond Attack:

• Obtain the AES hash of the KRBTGT account: The attacker first compromises the KRBTGT account (often by dumping hashes from the domain controller or gaining access to sensitive domain controller information).
• Decrypt the TGT using the KRBTGT AES hash: The attacker then uses the AES hash of the KRBTGT account to decrypt a valid TGT. The TGT, when decrypted, contains the PAC which includes user privileges, group memberships, and other critical information.
• Modify the PAC: After decrypting the TGT, the attacker can modify the PAC to reflect unauthorized attributes or privileges. This could include adding themselves to privileged groups like Domain Admins or changing their group memberships to escalate privileges.
• Re-encrypt the modified TGT using the KRBTGT AES hash: Once the attacker has modified the PAC as desired, they re-encrypt the TGT using the KRBTGT AES hash to create a new valid TGT. This re-encryption makes the modified TGT appear legitimate to the Kerberos infrastructure.
• Use the modified TGT: The attacker can now present the modified TGT to access resources as if they were a privileged user, bypassing normal access control mechanisms.
• GS (Service Ticket): The TGS tickets are issued based on the TGT. They do not directly store the PAC; instead, they rely on the TGT’s PAC to validate the user’s identity and permissions.
• In this attack, the manipulation occurs before the TGS is involved because the tampered TGT is used to request a service ticket with elevated privileges.

Ticket Structure

TGT (Ticket Granting Ticket) Structure

The TGT is issued by the Authentication Server (AS) and is used to request service tickets from the Ticket Granting Server (TGS). Its structure typically contains:

Header Information:Ticket version and type.

Client Information:Username and realm (e.g., [email protected]).

Session Key: A key shared between the client and the KDC, used for encryption.

PAC (Privilege Attribute Certificate):Contains details about the user:

• Group memberships.
• Privileges (e.g., admin rights).
• Account SID (Security Identifier).

Timestamp and Lifetime:Validity period of the ticket (start time, expiration time).

KRBTGT Encryption:The TGT is encrypted and signed using the KRBTGT hash (AES or RC4), ensuring only the KDC can read or validate it.

TGS (Service Ticket) Structure

The TGS ticket is issued by the Ticket Granting Server based on the TGT and is used to access specific services. Its structure includes:

Header Information:Ticket version and type.

Client Information:Username and realm.

Session Key:A unique key for secure communication between the client and the target service.

Service Information:The Service Principal Name (SPN) identifying the target service (e.g., HTTP/WEBSERVER.DOMAIN.LOCAL).

PAC (Privilege Attribute Certificate):Copied from the TGT and used by the service to verify the user’s identity and privileges.

Timestamp and Lifetime:Validity period of the service ticket.

Service Key Encryption:Encrypted using the service account’s key (password hash or key material of the SPN).

PAC Validation

Kerberos PAC (Privilege Attribute Certificate) validation ensures that the identity and privileges of a Kerberos-authenticated user are legitimate. The PAC contains information about the user’s group memberships, SID (Security Identifier), and other authorization data.

AS-REQ and AS-REP:

• The client sends an AS-REQ to the Key Distribution Center (KDC) to request a Ticket-Granting Ticket (TGT).
• The KDC issues a TGT in the AS-REP, embedding the PAC in the encrypted portion of the ticket.

TGS-REQ and TGS-REP:

• The client sends a TGS-REQ to KDC, using the TGT to request a service ticket for a specific resource.
• The KDC responds with a TGS-REP that includes the PAC.

AP-REQ (Application Request):

• The client sends the TGS (including the PAC) to the target service.

PAC Validation by the Service:

• If the service trusts the KDC, it may directly use the PAC without validation.
• If the service requires PAC validation, it sends the PAC to a domain controller (DC) for verification.

PAC Validation Details:

• The service sends the PAC to the DC using Kerberos Signature Verification.
• The DC verifies the PAC’s digital signature (created using the KDC’s private key) to ensure integrity and authenticity.
• If valid, the DC returns confirmation to the service.

AP-REP (Application Reply):

• After PAC validation, the service grants or denies access based on the user’s privileges.

Limitation of PAC Validation

The main drawback in Kerberos PAC authentication is the lack of PAC validation by services. Services often trust the PAC (Privilege Attribute Certificate) embedded in Kerberos tickets without verifying its signature with the KDC or Domain Controller (DC). This allows attackers to:

• Forge a PAC offline using stolen credentials (e.g., NTLM hash or Kerberos keys).
• Create a fake TGS (Ticket Granting Service) ticket without interacting with the KDC.
• Exploit the trust model where the service blindly accepts the ticket, granting unauthorized access.

Key Issues

• Abusing Kerberos Trust Model: Services assume the PAC is legitimate and skip validation.
• Offline Forging: Attackers bypass KDC entirely, making detection difficult.
• Key Dependency: Stolen service account keys or hashes enable ticket creation.

Prerequisites for Attack

• KRBTGT Account Hash: Essential for decrypting and re-encrypting TGTs.
• AES256 Key: Often required to modify PACs embedded within TGTs.
• Administrative Access: Initial access to a high-privilege account to extract cryptographic material.

Labsetup:

To perform this attack, create two user Raaz as domain admin and Sanjeet as Standard user in the Domain Controller.

net user raaz Password@1 /add /domain
net group raaz “Domain Admins” /add /domain

net user sanjeet Password@1 /add /domain

Remotely Diamond Attack -Linux

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, RAAZ-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/raaz:Password@[email protected] -just-dc-user krbtgt

The highlighted image shows the NTLM and AES Hashes for KRBTGT service account.

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

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 “sanjeet” with potentially elevated privileges and a valid signature, bypassing detection mechanisms such as PAC validation by the Domain Controller.

impacket-ticketer -request -domain 'ignite.local' -user 'sanjeet' -password 'Password@1' -nthash '761688de884aff3372f8b9c53b2993c7' -aesKey '8e52115cc36445bc520160f045033d5f40914ce1a6cf59c4c4bc96a51b970dbb' -domain-sid 'S-1-5-21-798084426-3415456680-3274829403' sanjeet

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

-user ‘sanjeet’: 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.

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

Pass the Ticket

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

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

export KRB5CCNAME=sanjeet.ccache; impacket-psexec ignite.local/[email protected] -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/[email protected]:The Kerberos principal name (user@realm) used for authentication:

• local is the domain.
• sanjeet 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.

Locally Diamond Attack-Windows

If the attacker has compromised the local network machine windows, then, they may use tool like Mimikatz and Rubeus.

KRBTGT Hash Extraction:

• The command extracts the NTLM hash and AES encryption keys of the KRBTGT account from the target domain.
• These hashes are used in Golden Ticket and Diamond Ticket attacks to forge Kerberos tickets.

The given command demonstrates the usage of Rubeus, a tool designed for Kerberos ticket operations in Active Directory environments. This specific command performs a Diamond Ticket Attack, allowing the attacker to impersonate a specified user.

rubeus.exe diamond /krbkey:8e52115cc36445bc520160f045033d5f40914ce1a6cf59c4c4bc96a51b970dbb /user:sanjeet /password:Password@1 /enctype:aes /domain:ignite.local /dc:dc.ignite.local /ticketuser:sanjeet /ptt /nowrap

diamond:

Indicates that this is a Diamond Ticket attack mode in Rubeus.

This attack involves forging service tickets using the KRBTGT encryption keys.

/krbkey:8e52115cc36445bc520160f045033d5f40914ce1a6cf59c4c4bc96a51b970dbb:

Specifies the KRBTGT AES key needed to encrypt and sign the Kerberos ticket.

This key is critical for crafting a valid Kerberos service ticket. 

/user:sanjeet:

Specifies the username (sanjeet) whose credentials are being used to perform the operation.

/password:Password@1:

The password for the specified user (sanjeet).

This is used to authenticate and potentially retrieve necessary encryption keys or TGTs.

/enctype:aes:

Defines the encryption type for the Kerberos ticket. In this case, AES encryption is used.

AES keys are commonly used in modern Kerberos implementations for enhanced security.

/domain:ignite.local:

Specifies the target domain (ignite.local) for which the ticket will be crafted.

/dc:dc.ignite.local:

Indicates the Domain Controller (dc.ignite.local) to interact with.

/ticketuser:sanjeet:

Specifies the target user whose identity the forged Kerberos ticket will impersonate.

This is the user for whom the crafted ticket grants access to services.

/ptt:

Stands for “Pass-The-Ticket.”

Automatically injects the crafted ticket into the current session to be used for authentication.

/nowrap:

Prevents the output from being wrapped in the console.

This option is for cleaner output readability.

It will dump a TGT ticket which will be used further to request TGS.

rubeus.exe asktgs /ticket: <paste the above copied ticket>

 /service:cifs/dc.ignite.local /ptt /nowrap

klist

This will display all the Kerberos tickets currently in the ticket cache.

The command is used in Windows to list the contents of the C: drive of the remote machine specified by the hostname or IP address

dir \\dc.ignite.local\c$

Detection Techniques

Key Event IDs

• 4769 (Service Ticket Request): Detects forged TGT use. Indicators: Unusual account names, high privileges (e.g., Domain Admins), and requests from abnormal IPs.
• 4624 (Successful Account Logon): Look for Logon Type 3 (network logons) from unexpected hosts or elevated privileges for non-admin accounts.
• 4678 (Privileges Assigned to Logon): Detects special privileges (e.g., SeDebugPrivilege) assigned to non-privileged accounts.
• 4713 (Kerberos Policy Changed): Flags changes to ticket lifetimes or other Kerberos policies.
• 4625 (Failed Logon): Repeated failures for privileged accounts or from suspicious IPs.

Detection Strategies

• Ticket Lifetime: Compare Ticket Lifetime in Event ID 4769 with policy norms to spot anomalies.
• Privilege Correlation: Track elevated privileges or sensitive SPN access by standard users.
• Unusual Encryption Types: Detect rarely used encryption like RC4 in Event ID 4769.
• TGT Usage: Monitor for identical TGTs used across multiple IPs or locations.

Proactive Measures

• Enable Kerberos logging for detailed activity.
• Audit changes to high-privilege groups (Event IDs 4728, 4732).
• Rotate KRBTGT account passwords regularly.

Example SIEM Query

index=security_logs sourcetype=wineventlog EventID=4769

| search ServiceName IN (“Domain Admins”, “Enterprise Admins”)

| stats count by AccountName, IPAddress, ServiceName

| where count > 5

Mitigation Strategies

Proactive Measures

• Rotate KRBTGT Account Passwords: Regularly reset the KRBTGT password twice to invalidate cached tickets.
• Enforce Modern Encryption: Disable legacy protocols like RC4-HMAC in favor of AES256.
• Restrict Privilege Escalation: Apply least privilege principles to minimize exposure.

Incident Response

• Invalidate Active Tickets: Immediately rotate KRBTGT keys and log out all active sessions.
• Forensic Analysis: Use tools like BloodHound to map privilege escalation paths and identify compromised accounts.

Conclusion

The Diamond Ticket attack underscores the importance of securing Kerberos authentication in AD environments. By understanding the technical underpinnings and addressing the root causes of vulnerabilities, organizations can significantly reduce their exposure to such advanced threats.

Author: Komal Singh is a Cyber Security Researcher and Technical Content Writer, she is a completely enthusiastic pentester and Security Analyst at Ignite Technologies. Contact Here