Kerberos Second Edition
Kerberos Second Edition
AUTHENTICATION,
GOLDEN TICKET
ATTACK
Introduction to Kerberos Authentication
• Kerberos is a network authentication protocol that uses
a trusted third-party server, called a Key Distribution
Center (KDC), designed to provide strong
authentication for client/server applications using
secret-key cryptography.
• Developed by MIT a Research University, it is widely
used in various systems including Windows, UNIX, and
Linux.
Components and Terminology
• Key Distribution Center (KDC): Central authority that issues
tickets.
• Authentication Server (AS): Part of the KDC that
authenticates users.
• Ticket Granting Server (TGS): Issues service tickets.
• Principal: Entity (user or service) that participates in Kerberos
authentication.
• Ticket Granting Ticket (TGT): A ticket used to obtain service
tickets from the TGS.
• Service Ticket: A ticket that grants access to a specific
service.
KERBEROS AUTHENTICATION PROCESS
1. Initial Authentication Request (AS-REQ)
• Client to Authentication Server (AS)
• Client Request (AS-REQ)
• The client sends an Authentication Service Request (AS-REQ) to the
Authentication Server (AS).
• This request includes:
• The client's principal name.
• The requested service principal
2. Initial Authentication Response (AS-REP)
• Authentication Server (AS) to Client
• AS Response (AS-REP)
• The AS verifies the client's identity (using client secret key) and
generates a Ticket Granting Ticket (TGT).
• The AS sends back an Authentication Service Response (AS-REP), which
includes:
• The TGT, encrypted with the TGS's secret key.
• A session key, encrypted with the client's secret key (derived from the
client's password).
• Both contain a randomly generated TGS Session key.
3. Ticket Granting Service Request (TGS-REQ)
• Client to Ticket Granting Server (TGS)
• Client Request (TGS-REQ)
• The client decrypts the session key using their secret key by
entering their password.This is the step where user's password is
validated.
• The client constructs a TGS Request (TGS-REQ) to request access
to the specific service.
• This request includes:
• The TGT received from the AS.
• An User authenticator (a timestamp encrypted with the TGS
session key).
• The service principal name (the service the client wants to
access).
4. Ticket Granting Service Response (TGS-REP)
• Ticket Granting Server (TGS) to Client
• TGS Response (TGS-REP)
• The TGS decrypts (using TGS Secret key and TGS Session key)
and validates the TGT and the authenticator.
• The TGS generates a service ticket for the requested service.
• The TGS sends back a TGS Response (TGS-REP), which includes:
• The service ticket, encrypted with the service's secret
key.(which is stored in the KDC.)
• Message containing service principal name (encrypted with
TGS Session key).
• A Service session key is added to both.
5. Service Request (AP-REQ)
• Client to Service
• Client Request (AP-REQ)
• The client decrypts the message using the TGS
session key and get Service Session Key.
• The client constructs a Service Request (AP-REQ) to
access the service.
• This request includes:
• The service ticket received from the TGS.
• An authenticator (a new timestamp encrypted with
the Service session key).
6. Service Response (AP-REP)
• Service to Client
• Service Response (AP-REP)
• The service decrypts the service ticket and user
authenticator using its own secret key and Service
Session Key.
• The service validates the authenticator.
• If mutual authentication is required, the service
responds with a service authenticator encrypted with
the service session key.
Golden Ticket Attack
The Golden Ticket attack is a sophisticated Kerberos attack where an
attacker forges a Ticket Granting Ticket (TGT) after compromising a
domain controller and obtaining the KRBTGT account hash.
• The attacker exploits vulnerabilities or uses phishing attacks to
gain administrative access to a domain controller (DC).
• The attacker extracts the KRBTGT account hash from the DC, which
is used to sign and encrypt TGTs
• Using the KRBTGT hash, the attacker creates a forged TGT with
desired privileges (e.g., domain admin) using tools like Mimikatz.
• The forged TGT is signed with the KRBTGT account hash, making it
appear legitimate to the KDC.
Mitigation and Response
Detection
• Monitoring and Alerts: Implement monitoring for unusual TGT and
service ticket activities. Use SIEM systems to correlate events and detect
anomalies.
• Log Analysis: Regularly analyze logs for signs of credential dumping,
unusual logins, and abnormal use of high-privilege accounts.
Mitigation and Response
Prevention
• KRBTGT Password Rotation: Regularly change the KRBTGT account
password to invalidate any existing forged tickets.
• Patch Management: Ensure all systems are regularly patched to prevent
exploitation of known vulnerabilities.
• Least Privilege: Limit the use of high-privilege accounts and employ the
principle of least privilege.
• Multi-Factor Authentication (MFA): Implement MFA for accessing
critical systems and accounts.
Mitigation and Response
Incident Response
• Containment: Immediately isolate compromised systems and accounts.
• Investigation: Conduct a thorough investigation to understand the
extent of the breach and identify all compromised accounts and systems.
• Remediation: Reset passwords, remove malicious software, and close
exploited vulnerabilities.
• Recovery: Restore affected systems from backups and ensure that the
network is secure before returning to normal operations.