AP Exchange: Using the Ticket

Why It Matters

A file server decides alone, from the ticket, with no call to a DC, so a forged service ticket to it can leave no trace on any DC. One event 4769 in a DC's Security log can also sit behind many 4624 events on the server, because the client reuses its ticket until it expires.

Where It Sits

The strip shows every step of the Kerberos sign-in, with this page's steps marked. Each of the others links to its own page, and Step Through It opens the walk-through on the topic page.

KerberosStep Through It

Step 1 of 6, AS Request, ws-017 to dc-01
Step 2 of 6, AS Reply, dc-01 to ws-017
Step 3 of 6, TGS Request, ws-017 to dc-01
Step 4 of 6, TGS Reply, dc-01 to ws-017
Step 5 of 6, AP Request, ws-017 to srv-fin-01
Step 6 of 6, AP Reply, srv-fin-01 to ws-017

What Happens

The client sends the service ticket, with a new authenticator encrypted with the service session key, inside the application's own protocol, such as the SMB session setup for a file share, an LDAP bind or an HTTP Negotiate header. srv-fin-01 opens the ticket with its own key, checks the authenticator, and builds dana's access token from the PAC. Share and file permissions then decide what she may open.

The server can check only the PAC's server signature, which its own key made, because the other signatures need the krbtgt key. Windows asks a DC to check the KDC signature (PAC validation) only for some services, and services that run as part of the operating system, the file server among them, do not ask.

In mutual authentication srv-fin-01 answers with the time from the authenticator, encrypted with the service session key, which only the real server could have read from the ticket. Both sides then share a key, which SMB uses to sign the session. Nothing is logged for the reply itself, while the logon is event 4624 in srv-fin-01's Security log, and opening the share writes event 5140 there where file share auditing is on.

A ticket opens only with the key of the account that runs the service, so unlike an NTLM answer it cannot be passed to a server run by a different account. Where signing or channel binding is not required, though, it can be relayed to a service run by the same account, and before the June 2025 updates CVE-2025-33073 let one be reflected back to the sender. Requiring SMB signing, and LDAP signing with channel binding, leaves a relayed request useless.

What Is Sent

Each part of the message is listed with what it holds and what protects it. A part sealed with a key can be read only by whoever holds that key, and a part marked In the clear has no protection of its own.

AP Requestws-017 to srv-fin-01

Part	What It Holds	Protection and Who Can Read It
The service ticket `ticket`	As dc-01 issued it, which only srv-fin-01's key opens.	Encrypted with srv-fin-01's AES keyOnly dc-01 and srv-fin-01 can open it.
A fresh authenticator `authenticator`	dana's name and the current time, proof that she holds the service session key.	Encrypted with the service session keyOnly ws-017 and srv-fin-01 can open it.

AP Replysrv-fin-01 to ws-017

Part	What It Holds	Protection and Who Can Read It
Proof of the server `enc-part`	The time from dana's authenticator and a new subkey for the session, sealed so that only the real srv-fin-01 could have made it.	Encrypted with the service session keyOnly ws-017 and srv-fin-01 can open it.

Reading Event 4624 for a Kerberos Sign-In

On the server, a Kerberos sign-in shows as event 4624 in the Security log. These fields say how it was proved, where it came from and which ticket it used.

Field	What It Tells You
Logon Type	3 for a network logon such as opening a share.
Authentication Package	Kerberos. NTLM where Kerberos is normal deserves a look.
Logon GUID	Matches event 4769 for this ticket on the DC that issued it.
Source Network Address	The machine that presented the ticket.
Impersonation Level	Delegation means the server may use the logon to reach other machines.

What Is Logged

Each event below names the log it is written to, the machine that writes it and the audit setting that switches it on, then what to read in it for this page.

Event and Log	Written On	Switch It On	What It Tells You
4624 `An account was successfully logged on` (opens in a new tab) Security log	The computer that was logged on to	Audit Logon	AP RequestLogon Type 3, Authentication Package Kerberos, Source Network Address 192.0.2.17, and the Logon GUID of the 4769 on dc-01.Reading Logon Events explains how to read it.
4627 `Group membership information` (opens in a new tab) Security log	The computer that was logged on to, beside its 4624	Audit Group Membership, with Audit Logon success on as well	AP RequestThe groups in her new token, where Audit Group Membership is on.When enabled
4672 `Special privileges assigned to new logon` (opens in a new tab) Security log	The computer that was logged on to	Audit Special Logon	AP RequestOnly when the token carries admin-level privileges, such as an administrator's sign-in, not dana's.Reading Logon Events explains how to read it.

AP ReplyNothing is logged for the reply itself. Opening the share then writes event 5140 to srv-fin-01's Security log where Audit File Share is on.

Check It on a Machine

These Windows Registry keys hold the settings this page names. Open one to see where it lives and how to read it on a machine.

Advanced Audit Policy

Attacks That Hook in Here

These attacks work through what this page describes. Each card says what the attack is and, where it uses one of these steps, what it does there.

Silver Ticket
Forges a service ticket with the service's own key, so no DC ever issues it.
At This Step The forged ticket is shown to the server here. No DC logged a 4769 for it, so a 4624 whose Logon GUID matches no DC's 4769 gives it away.
Pass-the-Ticket
Replays a Kerberos ticket copied from one machine's memory on another.
At This Step A copied service ticket and session key are shown to the server here from an address that is not ws-017's, as the server's 4624 records.
Kerberos Delegation Abuse
Uses a server trusted for delegation to reach other services in users' names.
At This Step To a server trusted for unconstrained delegation, this request also carries a copy of the user's TGT and session key, which it then holds.
Forced Authentication (Coercion)
Makes a server, a DC included, sign in to a machine the attacker controls.
At This Step Aimed at a server trusted for unconstrained delegation, a forced callback makes a DC send this request with a copy of its own TGT.