Pass-the-Ticket
Also calledPtT, Ticket replay
Replays a Kerberos ticket copied from one machine's memory on another.
- Technique
- MITRE ATT&CK T1550.003: Use Alternate Authentication Material: Pass the Ticket (opens in a new tab)
- Needs
- TGTorService Ticket
- Gives
- Account AccessandLocal Admin
How the Attack Works
A Kerberos ticket is a bearer token. Whoever presents it with its session key is treated as the account it names until it expires. Tickets and their session keys sit in LSASS wherever the account signed in at the console or by Remote Desktop, so admin rights there are enough to copy them to another machine. Nothing in a Windows ticket ties it to the machine it was issued to, so the DC and the services honour it from anywhere.
Read first Authentication and Authorisation, Credentials on a Running Machine, AS Reply: The TGT, TGS Request, Kerberos Delegation
How It Plays Out
The attack step by step. Each step shows which machines take part, what travels, the keys and tickets each side now holds, what is logged and what a defender can see.
ws-017 Client
- dana's key
- TGT
- TGT session key
srv-app-01 Foothold
dc-01 Domain controller
- dana's key
- krbtgt key
- srv-fin-01 key
srv-fin-01 File server
- srv-fin-01 key
Step 1 of 5: TGT Copied
On ws-017 Client
With admin rights on ws-017, dana's TGT and its session key are copied out of LSASS, where her sign-in left them.
Logged
10 ProcessAccess
On ws-017, in the Microsoft-Windows-Sysmon/Operational log When enabled
A process opening lsass.exe on ws-017
What Defenders See
On ws-017, the signs of LSASS access show in two logs. The Microsoft-Windows-Sysmon/Operational log has Sysmon event 10, and the Microsoft-Windows-Windows Defender/Operational log has the ASR rule's events and Defender's detections.
Hooks into Kerberos AS Reply
Step 2 of 5: Ticket Loaded
On srv-app-01 Foothold
On srv-app-01 the copied TGT and session key are loaded into a logon session, which now acts as dana for Kerberos.
Keys and Tickets
- srv-app-01 now holds TGT (new at this step) TGT session key (new at this step)
What Defenders See
Little shows on srv-app-01 itself, because a ticket added to a session writes no sign-in event to its Security log. What shows is the ticket's use, in the Security logs on dc-01 and srv-fin-01.
Step 3 of 5: TGS Request as dana
srv-app-01 Foothold to dc-01 Domain controller
Request for a service ticket as dana
KRB_TGS_REQKerberos, port 88srv-app-01 sends dana's TGT with a fresh authenticator, made with the stolen session key, and asks for srv-fin-01.
What Travels in This Step
The TGT
dana's name and groups, exactly as the DC issued them
Encrypted with the krbtgt AES key Only dc-01 can open it.
An authenticator
dana's name and the time
Encrypted with the TGT session key Only ws-017, srv-app-01 and dc-01 can open it.
The service wanted
snamecifs/srv-fin-01.corp.example
In the clear Anyone who sees the traffic can read it.
Logged
4769 A Kerberos service ticket was requested
On dc-01, in the Security log
Account Name dana@CORP.EXAMPLE, Client Address ::ffff:192.0.2.25
TGS Reply: The Service Ticket explains how to read it.
What Defenders See
The Security log on dc-01 shows event 4769 for dana from 192.0.2.25, while the event 4768 for her TGT came from 192.0.2.17. The same Request ticket hash comes from two addresses.
Hooks into Kerberos TGS Request
Step 4 of 5: Service Ticket
dc-01 Domain controller to srv-app-01 Foothold
Reply with the service ticket
KRB_TGS_REPKerberos, port 88dc-01 opens the TGT with the krbtgt key, finds it valid and issues the ticket as it would to dana.
What Travels in This Step
The service ticket
dana's name and groups, for srv-fin-01
Encrypted with srv-fin-01's AES key Only dc-01 and srv-fin-01 can open it.
The service session key
A new key for talking to srv-fin-01
Encrypted with the TGT session key Only ws-017, srv-app-01 and dc-01 can open it.
Keys and Tickets
- srv-app-01 now holds service ticket (new at this step) service session key (new at this step)
What Defenders See
The reply adds nothing to the Security log on dc-01 beyond the event 4769 above.
Step 5 of 5: AP Request as dana
srv-app-01 Foothold to srv-fin-01 File server
Service ticket shown to the server
KRB_AP_REQSMB, port 445srv-app-01 presents the ticket to srv-fin-01, which builds dana's token and opens the share to her rights.
What Travels in This Step
The service ticket
dana's name and groups
Encrypted with srv-fin-01's AES key Only dc-01 and srv-fin-01 can open it.
An authenticator
dana's name and the time
Encrypted with the service session key Only srv-app-01 and srv-fin-01 can open it.
Keys
- srv-fin-01 now holds service session key (new at this step)
Logged
4624 An account was successfully logged on
On srv-fin-01, in the Security log
Logon Type 3, Authentication Package Kerberos, Source Network Address 192.0.2.25
Reading Logon Events explains how to read it.
What Defenders See
The Security log on srv-fin-01 shows event 4624 with Logon Type 3 and Kerberos for dana from 192.0.2.25, a machine she never signs in from.
Hooks into Kerberos AP Request
Needs First
What the attacker must already hold for this attack to be possible.
- A TGT or A Service TicketA TGT or service ticket with its session key, from a machine where the account is signed in.
Comes From
Gives the Attacker
What running it hands the attacker to use next.
- Access as Another AccountAccess as the ticket's account until it expires, anywhere for a TGT and one service for a service ticket.
- Local Admin RightsAdmin rights wherever the ticket's account is an administrator.
Leads To
What Defenders See
What this attack leaves for a defender to find, and what to read in each. None of it is proof on its own, so treat each as a lead and confirm it against the rest.
| Event and Log | Written On | Look For | Switch It On |
|---|---|---|---|
| 4769 A Kerberos service ticket was requested (opens in a new tab) Security log | Domain controllers | Service tickets for the account from an address its TGT was not issued to, with the same Request ticket hash from two Client Addresses.TGS Reply: The Service Ticket explains how to read it. | Audit Kerberos Service Ticket Operations |
| 4768 A Kerberos authentication ticket (TGT) was requested (opens in a new tab) Security log | Domain controllers | Where the account's TGT was really issued, the Client Address to compare every later 4769 with.AS Reply: The TGT explains how to read it. | Audit Kerberos Authentication Service |
| 4770 A Kerberos service ticket was renewed (opens in a new tab) Security log | Domain controllers | A TGT renewed (Service Name krbtgt) from an address other than the one its 4768 came from. | Audit Kerberos Service Ticket Operations |
| 4624 An account was successfully logged on (opens in a new tab) Security log | The computer that was logged on to | Kerberos network logons for the account on machines it never reaches, from a source it does not use.Reading Logon Events explains how to read it. | Audit Logon |
What It Looks Like
One event from the worked example, decoded field by field, so you can see what to read in it and what each value means.
4769 A Kerberos service ticket was requested
In the Security log on dc-01,
dana's TGT, issued to ws-017, used from srv-app-01 to ask for a ticket to srv-fin-01.
dana, in the user@REALM form 4769 uses.
As Windows writes it:
Account Namedana@CORP.EXAMPLEThe account that runs the service asked for, the file server.
As Windows writes it:
Service Namesrv-fin-01$srv-app-01, not ws-017, where her TGT was issued at sign-in, so the TGT has moved to another machine.
As Windows writes it:
Client Address::ffff:192.0.2.25AES. Nothing is wrong with the ticket itself, only with the machine using it.
As Windows writes it:
Ticket Encryption Type0x12The DC honoured the TGT, as it does any valid one.
As Windows writes it:
Failure Code0x0The same value as the Response ticket hash in dana's 4768 from 192.0.2.17, so one TGT is in use on two machines.
As Windows writes it:
Request ticket hash(a hash of the TGT sent)
Defender for Identity Alerts
Where Defender for Identity runs, its sensors raise these from what they read on the servers they are installed on, domain controllers above all. Each names what it flags, which is a lead to confirm, not proof on its own.
- Suspected identity theft (pass-the-ticket) (opens in a new tab)
- Suspected pass-the-ticket attack (opens in a new tab)
Blind Spots
Where this attack leaves little or nothing to see, so a quiet log is not read as an all-clear.
- Address checks are leads, not proof. VPN and DHCP move innocent users too, and a ticket reused on the machine it came from shows no new address, so look on that machine for how it was taken.
- A stolen service ticket goes straight to its service and never touches a DC, so only the target's own logon events show it.
Hunt It
The query to run in each tool, and how well each one sees this attack. Pick the tool you use, and the others load their query when you open them.
Needs Defender for Identity sensors on every DC. Its classic alert fires when one Kerberos ticket is seen on two or more computers. It shows the reuse, not how the ticket was taken, so check LSASS on the computer it came from.
// Defender for Identity pass-the-ticket alerts, with the accounts and machines in themAlertInfo| where Timestamp > ago(How to Prevent It
The controls that break this attack, each with how it helps here and, where the Registry topic has it, where to check it on a machine.
Credential Guard (opens in a new tab)
Turn on Credential Guard, so TGTs sit in an isolated process and cannot be copied out of LSASS.
Check it on a machine: Credential Guard (LsaCfgFlags)Protected Users group (opens in a new tab)
Add privileged accounts to Protected Users, so their TGTs last four hours and cannot be renewed past that, which shortens any replay.
Remote Credential Guard (opens in a new tab)
Use Remote Credential Guard for admins' Remote Desktop sessions, so no TGT of theirs is left on the server.
Check it on a machine: Restricted Admin ModeTiered administration (opens in a new tab)
Keep admin tickets off ordinary machines, where they could be copied.
Sources
- MITRE ATT&CK T1550.003: Use Alternate Authentication Material: Pass the Ticket (opens in a new tab)
- RFC 4120 section 5.3: Tickets (opens in a new tab)
- [MS-KILE]: AP exchange (opens in a new tab)
- Microsoft Learn: Event 4769 (opens in a new tab)
- Microsoft Learn: Credential Guard overview (opens in a new tab)