Detecting and Mitigating Pass the Ticket Attacks (T1550.003)

Pass the ticket (PtT) is a Windows lateral movement technique that uses stolen Kerberos tickets to authenticate without an account's password. MITRE tracks it as T1550.003, under Use Alternate Authentication Material.

How attackers use it

Kerberos authentication can be the first step in lateral movement to a remote system. For PtT, valid tickets for valid accounts are captured through OS Credential Dumping. Depending on the access gained, an adversary may get a user's service tickets or the ticket granting ticket (TGT).

The difference matters. A service ticket gives access to one particular resource. A TGT can request service tickets from the Ticket Granting Service for anything the user is allowed to reach.

MITRE describes two forged forms.

• A Silver Ticket, obtained for services that use Kerberos, which grants access to that resource and the system hosting it, such as SharePoint.
• A Golden Ticket, created using the NTLM hash of the KRBTGT account, which lets the adversary generate TGTs for any account in Active Directory.

Adversaries may also create a valid ticket from other user information, such as password hashes or AES keys. "Overpassing the hash" uses an NTLM hash to authenticate and also to build a Kerberos ticket.

How to detect it

MITRE's detection strategy correlates three Windows Security events: service ticket requests (Event ID 4769), the absence of matching account logons (Event ID 4624), and earlier TGT activity (Event ID 4768). The anomaly is a service ticket with no TGT request and no logon behind it.

Other signals from MITRE are service ticket chains involving unexpected users, hosts or times, suspicious ticket injection into LSASS memory, and network lateral movement with Kerberos but without the interactive logon patterns you would expect.

How to reduce the risk

MITRE lists four mitigations.

• Active Directory Configuration: to contain a previously generated golden ticket, reset the built-in KRBTGT password twice. Change it once, force replication, then change it a second time. This invalidates golden tickets made with the KRBTGT hash and other tickets derived from it. MITRE suggests considering a rotation every 180 days.
• Password Policies: give local administrator accounts complex, unique passwords.
• Privileged Account Management: limit domain admin permissions to domain controllers and a small set of servers, and delegate other admin work to separate accounts.
• User Account Management: do not let a user be a local administrator on multiple systems.

Check your own environment

• Do you have 4768, 4769 and 4624 events from your domain controllers and servers in one place, so they can be joined?
• When was the KRBTGT password last changed? Is there a documented rotation owner?
• How many accounts hold domain admin rights, and where can they log on?

Quick check

Sources

• MITRE ATT&CK, Use Alternate Authentication Material: Pass the Ticket: https://attack.mitre.org/techniques/T1550/003