TGS Reply: The Service Ticket

KRB_TGS_REP

The DC returns a ticket only the service can read, and a session key for using it.

  • Kerberos
  • Domain controller to client
  • Kerberos, port 88

Why It Matters

A service ticket is sealed with the key of the account that runs the service, so it is only as strong as that account's password. Event 4769, written to the DC's Security log for this step, is where RC4 tickets and Kerberoasting show up.

Where It Sits

The strip shows every step of the Kerberos sign-in, with this page's step 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
  1. Step 1 of 6, AS Request, ws-017 to dc-01
  2. Step 2 of 6, AS Reply, dc-01 to ws-017
  3. Step 3 of 6, TGS Request, ws-017 to dc-01
  4. Step 4 of 6, TGS Reply, dc-01 to ws-017
  5. Step 5 of 6, AP Request, ws-017 to srv-fin-01
  6. Step 6 of 6, AP Reply, srv-fin-01 to ws-017

What Happens

The reply carries the service ticket, encrypted with the key of the account that owns the SPN. It also carries the service session key, encrypted with the TGT session key (or a subkey the client chose) so only the client can read it. The ticket holds dana's name, a copy of her PAC, the same service session key and the validity times, and by default it lasts ten hours.

A computer account's password is long, random and changed by Windows every thirty days by default, so a ticket sealed with its key cannot realistically be guessed. A service run by a user account, such as svc-backup, is only as strong as the password someone chose, and a ticket to it can be guessed offline, where nothing is logged. A group managed service account, or a long random password where one cannot be used, gives it the same protection, and AES alone does not save a weak password.

The ticket is sealed in a type the service account's msDS-SupportedEncryptionTypes allows, so no RC4 ticket is issued for an account limited to AES. Since the 2026 updates, accounts with no msDS-SupportedEncryptionTypes set count as AES-only too, unless a DC sets its own default. An RC4 ticket (0x17) therefore points at an account, or a DC default, set to allow RC4, and a request that offered nothing but RC4 deserves a closer look.

One event 4769 is written per ticket, to the Security log of the DC that issued it, so collect every DC. Its Logon GUID reappears in event 4624 in the Security log of the server where the ticket is used, which joins the two records. A decoy account with an SPN that nothing legitimate uses makes any 4769 for it worth an alert.

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.

PartWhat It HoldsProtection and Who Can Read It
The service ticket ticketdana's name, a copy of her PAC, the service session key and its times, in a type srv-fin-01's account supports.Encrypted with srv-fin-01's AES keyOnly dc-01 and srv-fin-01 can open it.
ws-017's part enc-partThe same service session key and the times. Where the authenticator carried a subkey, that subkey seals this part instead.Encrypted with the TGT session keyOnly ws-017 and dc-01 can open it.

Reading Event 4769 After the January 2025 Updates

Event 4769 in the domain controller's Security log records every service ticket issued or refused. These are its fields as updated DCs write them, and what each one tells you.

FieldWhat It Tells You
Account NameWho asked, as name@REALM, where names ending in $ are computer accounts.
Service NameThe account that owns the SPN, whose key sealed the ticket.
Client AddressThe address the request came from.
Ticket Encryption TypeThe ticket itself, 0x12 normally and 0x17 for RC4.
Session Encryption TypeThe service session key.
MSDS-SupportedEncryptionTypes, Available KeysWhat the service account supports and the keys it holds.
Failure Code0x0 for a ticket issued. The TGS Request page lists the failures.
Transited ServicesThe services passed through under constrained delegation.
Logon GUIDThe same value as in event 4624 on the server where the ticket is used.
Request ticket hash, Response ticket hashIdentify the TGT presented and the service ticket issued.

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 LogWritten OnSwitch It OnWhat It Tells You
4769 A Kerberos service ticket was requested (opens in a new tab) Security logDomain controllersAudit Kerberos Service Ticket OperationsAccount Name dana@CORP.EXAMPLE, Service Name SRV-FIN-01$, Client Address ::ffff:192.0.2.17, Ticket Encryption Type 0x12, Failure Code 0x0 and a Logon GUID.

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.

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.

  • Kerberoasting

    Asks for service tickets, then guesses the service account's password offline.

    At This Step This reply's ticket is sealed with the service account's key. A person-chosen password can be guessed offline, faster in RC4 (type 0x17).

  • Silver Ticket

    Forges a service ticket with the service's own key, so no DC ever issues it.

    At This Step A silver ticket replaces this reply, because the ticket is made with the service's key, so dc-01 never sends it and logs no 4769 for it.

Sources