AS, TGS, and AP flow: The difference between a TGT and a service ticket

1. Core mechanism

Three message exchanges over TCP/UDP 88 between the Kerberos client (WS01), the domain controller (DC01) in the KDC role, and the host (FS01) on which the target service runs. The decision points are LSA/Kerberos SSP (client), KDC service (DC) and SSPI acceptance on the service side in Windows. The boundary of this lesson is the structure of the KDC response: PAC content at 06.05, SPN ownership at 06.03, pre-authentication detail at 06.04.

Interfaces and specifications

• RFC 4120 §5.4.2: AS-REP ::= [APPLICATION 11] KDC-REP, TGS-REP ::= [APPLICATION 13] KDC-REP.
• RFC 4120 §5.3: Ticket ::= [APPLICATION 1] SEQUENCE { tkt-vno, realm, sname, enc-part }.
• RFC 4120 §5.2.9: EncryptedData ::= SEQUENCE { etype [0], kvno [1] OPTIONAL, cipher [2] }.
• RFC 4120 §7.5.1 key usage: 2 (ticket enc-part, service key), 3 (AS-REP enc-part, client key), 8/9 (TGS-REP enc-part, TGS session key or authenticator subkey).
• RFC 4120 §5.5.1: AP-REQ ::= [APPLICATION 14] SEQUENCE { pvno, msg-type, ap-options, ticket, authenticator }.
• Windows Security channel: 4768 (AS), 4769 (TGS), 4771 (pre-auth error); only on domain controller.

Three exchanges, one question: who can open this message?

When the tunahan user logs into WS01, the client first executes the AS exchange and receives a TGT for krbtgt/IYELABS.EXAMPLE. Then, when it accesses public share \\FS01\, the client executes the TGS exchange using this TGT and receives a service ticket for cifs/FS01.iyelabs.example. Finally, the AP presents the ticket to FS01 at the exchange.

Realize that all three steps ask the same question to different parties: who has the key to unlock your encrypted partition? In Kerberos, what determines "who owns" a message is not the name of the message, but rather which long-term or session key protects that section.

Therefore, the difference between TGT and service tickets is not structural. Both are the same Ticket type. The difference arises in the sname field and the key that protects the enc-part: the sname of the TGT is krbtgt/REALM and the key of the krbtgt account protects the enc-part; The sname of the service ticket is the target SPN, and the enc-part is protected by the key of the account to which that SPN is registered.

In the KDC response, ticket and enc-part are sister fields

Common drawings show the KDC response as two nested envelopes. The definition in RFC 4120 §5.4.2 does not support this: ticket [5] and enc-part [6] are two adjacent fields in the same SEQUENCE.

The client can inspect ticket [5], but cannot decrypt its ticket.enc-part.cipher. It can decrypt the cipher in the client-facing reply enc-part [6] with the appropriate key. The ticket exposes tkt-vno, realm and sname. Its EncryptedData also exposes etype and, when present, kvno; cipher holds the encrypted contents. Reading those fields does not reveal the ticket’s session key or authorization-data.

The way for the client to learn the service session key Kc,s is not to open the ticket, but to open its own response section. Kc,s are placed separately both within the ticket (for the service) and in its own section of the response (for the client).

KDC-REP ::= SEQUENCE {
        pvno            [0] INTEGER (5),
        msg-type        [1] INTEGER (11 -- AS -- | 13 -- TGS --),
        padata          [2] SEQUENCE OF PA-DATA OPTIONAL,
        crealm          [3] Realm,
        cname           [4] PrincipalName,
        ticket          [5] Ticket,          -- servis anahtariyla korunur
        enc-part        [6] EncryptedData    -- istemciye ait bolum
}

EncryptedData ::= SEQUENCE {
        etype   [0] Int32,
        kvno    [1] UInt32 OPTIONAL,
        cipher  [2] OCTET STRING
}

The key that opens TGS-REP is not the user's password

The ordinary password-based AS path protects its reply enc-part with the client long-term key; RFC 4120 §5.4.2 also permits another reply key selected through pre-authentication. TGS-REP uses an authenticator subkey when supplied, otherwise the TGT session key. The AS steps here illustrate password-based authentication; the user's password is not reused to open the TGS reply.

The same paragraph also gives a formal trace: There is no kvno field in the TGS-REP response section. This is due to the rule in RFC 4120 §5.2.9; kvno is only meaningful for messages encrypted with long-lived keys. The session key has no version because the session key is already specific to that exchange.

Key usage numbers quantify this distinction (RFC 4120 §7.5.1): 2 for ticket enc-part, 3 for AS-REP response part, 8 if TGS session key is used for TGS-REP response part, 9 if authenticator subkey is used. So even if it is the "same AES key", different derived keys are used for different purposes.

Practical result: when the user changes his password, the existing TGT remains valid and new service tickets can continue to be received with that TGT. Because the TGS exchange does not touch the user's long-term key at all.

When AP changes, two locks are opened sequentially

When FS01 receives an AP-REQ, it first decrypts the ticket with its own key. RFC 4120 §3.2.3 enforces this order: the ticket is resolved, the session key is extracted from the resolved EncTicketPart, then the authenticator is resolved with that session key.

The order is important because the service learns the key to unlock the authenticator only after opening the ticket. So if the service key is wrong, the error is in the integrity error family (KRB_AP_ERR_BAD_INTEGRITY), if the authenticator time is out of tolerance, the error is KRB_AP_ERR_SKEW. The two are the fault of different stages and cannot be put in the same box.

The ticket's kvno field also works here: the service reads from external fields which key version the ticket is encrypted with. If the key for that version is no longer available, KRB_AP_ERR_BADKEYVER is returned per RFC 4120 §3.2.3. This error is expected behavior if the password for the service account has been changed recently.

Sending AP-REQ and accepting it on the service are different operations. FS01 processes the ticket and authenticator locally; for example, its time check can reject the request with KRB_AP_ERR_SKEW. Rejection in this instrument marks the local decision. In the protocol, KRB-ERROR is a separate reply, not the sent AP-REQ bouncing back.

Buying a ticket does not mean getting authorization

RFC 4120 §1.4 and §10 are clear on this: just because a service ticket has been issued does not mean that the client is authorized to use that service. Kerberos verifies identity; Authorization is a separate decision.

In Windows, this distinction is clearly visible. tunahan can get tickets for cifs/FS01.iyelabs.example; FS01 can verify the ticket successfully; and still access to the file may be denied in DACL evaluation. The result of the Kerberos layer answers the question "who", the result of AccessCheck answers the question "what can it do".

Therefore, success record 4769 and file access are not the same event. Keeping them separate in telemetry ensures an accurate reading of the end of the single sample we watch throughout the lecture.

AP-REP is not required in every exchange

If the client sets mutual-required, the service replies with AP-REP. With that option off, this mutual-authentication reply can be omitted. Resource permission is evaluated separately in either case; receiving AP-REP does not grant READ.

RFC 4120 §3.2.4 protects the AP-REP enc-part with Kc,s extracted from the ticket. Even when the AP authenticator contains an optional subkey, that subkey does not protect AP-REP. By contrast, a TGS-REP uses the authenticator subkey when supplied (§5.4.2).

The instrument’s field-opening controls inspect key access for the selected observer. They perform no cryptography. Previous, direct step selection and changing observer send no messages; the nine explanatory flow paragraphs below do not map one to one to the instrument’s eight states.

KDC rejection and resource denial are different decisions

A valid TGT and a registered SPN do not guarantee success. If the example KDC policy rejects TGS-REQ, the result is KDC_ERR_POLICY (12 / 0x0C), and no service ticket is issued. FS01 has not validated a ticket or evaluated file permission. In contrast, READ denial after successful issuance and AP validation is a resource decision on FS01. Compare the two scenario locations in the instrument; these are fixed teaching outcomes, not a running KDC policy engine.

Connecting to the next mechanism

02.03 establishes how a process token is created. PAC information in a ticket is not the same object as the target access token; target-context creation and requested-right checks are separate steps. 08.01 compares why a later directory-membership change does not automatically recreate that context.

State and data flow

1. WS01 sends AS-REQ at login; KDC returns AS-REP and the response section containing TGT (sname=krbtgt/IYELABS.EXAMPLE) and Kc,tgs.
2. In this password-based example, the client opens the AS reply part with its long-term key and obtains Kc,tgs without opening the TGT. Other pre-authentication paths may select another reply key.
3. When the user accesses public path \\FS01\, the client prepares TGS-REQ: AP-REQ carrying TGT in padata and authenticator encrypted with Kc,tgs, sname=cifs/FS01.iyelabs.example in req-body.
4. KDC opens the TGT with the krbtgt key, verifies the authenticator with Kc,tgs, and resolves the directory to which account the requested SPN is registered.
5. KDC produces a new Kc,s; It encrypts the enc-part of the service ticket with the key of the FS01 account, and the TGS-REP enc-part with the Kc,tgs or provided subkey. DC01 produces 4769 at this point.
6. Client opens TGS-REP enc-part, receives Kc,s; Stores the service ticket without opening it.
7. The client presents the ticket with AP-REQ and a new authenticator encrypted with Kc,s to FS01.
8. FS01 first opens the ticket with its own key, retrieves Kc,s from it, then verifies the authenticator; If mutual authentication is requested, AP-REP is returned.
9. Once authenticated, FS01 issues a separate authorization decision for the requested access; This decision is not a Kerberos message.

2. Exploitation

Broken trust assumption

The false assumption is that the TGS grants access to the target resource. A principal with a valid TGT can request a service ticket for a registered SPN without having permission on that resource. Issuance is nevertheless conditional: KDC policy, supported request options and encryption types can cause rejection. In a successful standard TGS exchange, the target account’s long-term key protects the ticket’s encrypted contents; authentication and authorization at the resource service occur later.

Technical prerequisites

• A domain account and a valid TGT. Privileged membership is not itself required; the KDC must also accept the request under its policy and protocol checks.
• 88/tcp access to DC01.
• The target SPN is registered to an account via the servicePrincipalName attribute; If there is no SPN, KDC returns KDC_ERR_S_PRINCIPAL_UNKNOWN (0x7).
• The target account's key is based on a guessable password. If this condition is not met, offline testing on the resulting ciphertext will not yield meaningful results.
• Having the target account willing to issue a ticket with a weak etype such as RC4 speeds up the attempt; A configuration that only accepts AES makes the job significantly more difficult.

Exploitation mechanism

The mechanism is not a vulnerability, but a misunderstanding of the protocol's design. The ticket [5] field of TGS-REP is a ciphertext encrypted with the target account's long-term key and under key usage 2. This ciphertext can be retrieved from the network and password candidates can be tried offline; Once the right candidate is found, the key to the target account is obtained. What is gained is not access, but the ability to assume the identity of that account. No rules have been broken from Kerberos perspective; What's being violated is the "service account password can be chosen by human" assumption.

Why a ticket request is not an authorization check

KDC does not look at the target resource's DACL when generating a ticket. Nor can it: the permission decision on the resource is made on the host hosting that resource, along with the desired access mask and security context. KDC does not have any of this information.

Therefore, seeing Status 0x0 in the 4769 record does not indicate that the client can reach the target. Likewise, denying access does not necessarily 4769 fail.

For the attacker, this means obtaining a ciphertext based on the target's key material without ever touching the target. The target service will not be notified of this request; registration is in DC.

Which areas make the job easier?

The etype field of EncryptedData in the ticket directly determines the cost of the offline attempt. Older RC4 based etypes are much cheaper to try than AES based ones.

The kvno field tells which key version is used. If the service account's password has recently been rotated, running on the old ciphertext will not yield the current key.

The sname field explicitly writes the target. This area is not encrypted; Therefore, it is not clear which account the resulting ciphertext belongs to.

Where is it ineffective?

If the target account's key is not derived from a human-chosen password, the mechanism will not work. For group managed service accounts, passwords are automatically generated and rotated regularly; In this case, offline testing is no longer a practical option.

SPNs registered to machine accounts are in a similar situation because machine account passwords are automatically managed.

The impact is limited to the scope of the compromised service account. The phrase "service account has been compromised" alone does not mean that the domain has been compromised; The memberships of that account, the SPNs it is registered with and the object rights on it are evaluated separately.

3. Defense & Detection

Telemetry scope

• The Audit Kerberos Service Ticket Operations subcategory produces Success: 4769 records. The Failure setting produces 4769 failed instances.
• Audit Kerberos Authentication Service subcategory: 4768 and 4771. In order not to confuse the AS and TGS stages, they are opened together.
• Both events occur only on the domain controller. No object SACL required; these are KDC transaction records, not directory object access control.
• Source-side access evidence comes from a separate source: logon and object access control on FS01. It is treated as a separate observation point within the scope of this course.
• 4769 volume is high. If the collection decision, retention period, and filtering are not planned in advance, records become too large to analyze.

Events and relevant fields

• 4769 / ServiceName: the account or computer name where the ticket was issued. Machine accounts end with $.
• 4769 / ServiceSid: SID of the target account. NULL SID may be seen in failed registrations.
• 4769 / TargetUserName: client in normalized UPN format. This field is not a literal value of the account's userPrincipalName attribute.
• 4769 / TicketEncryptionType: etype of the issued service ticket, i.e. the algorithm of the section protected by the key of the service account. 0x12 = AES256-CTS-HMAC-SHA1-96, 0x17 = RC4-HMAC.
• 4769 / SessionKeyEncryptionType: Found in the Version 2 record and is the etype of the session key. The fact that these two areas can be different directly demonstrates the key distinction of the lesson in telemetry.
• 4769 / Status: KDC result. 0x0 no error; 0x20 KRB_AP_ERR_TKT_EXPIRED is routine and usually has no security significance.
• 4769 / LogonGuid: can be used for correlation with records 4624, 4648 and 4964 on the target computer. When not captured, zero GUID appears.
• 4769 / Version: classic record 0, 2 on Windows Server 2016+ that has received the security update on January 14, 2025 and later. The version difference determines which fields exist; Queries should be written without assuming this.

Identify which record answers which question

A successful 4768 records TGT issuance; a successful 4769 records service-ticket issuance. A failed 4769 records a TGS request failure, while 4771 records a pre-authentication failure. These concern processing at the KDC, not proof of access at the target resource.

To see that an access has actually occurred, it is necessary to look at the source side. Session and object access records on DC 4769 and on FS01 are different observation points and may not match exactly due to time difference, record latency, and collection coverage.

The LogonGuid field is designed to connect these two points, but it may not be filled in every record. If it is not captured, a zero GUID appears and the correlation is established over time and with less precision.

A ticket-issuance record on DC01 does not by itself confirm AP validation or the file access decision on FS01. For clock skew, the relevant boundary is the service’s AP check; for READ denial, it is resource permission. The instrument illustrates the distinction and generates no Windows events.

Two etype fields, two different keys

In the current 4769 record, TicketEncryptionType and SessionKeyEncryptionType are separate fields. The first is the algorithm of the part of the ticket protected by the service key; The second is the algorithm of the session key.

This distinction is the telemetry equivalent of the core idea of ​​the lesson: there are multiple keys in the same answer, and they do not all belong to the same party. When measuring hardening it is necessary to know which area to monitor.

Version 0 records do not have SessionKeyEncryptionType. If the query considers this field mandatory, it will silently return nothing on old records. Missing field behavior should be written as part of the query.

Observation point     Record           Question
--------------------  ---------------  ------------------------------------
DC01 (KDC)            4768 success     Was a TGT issued?
DC01 (KDC)            4769 success     Was a ticket issued for this account?
DC01 (KDC)            4769 failure     Did the TGS request fail?
DC01 (KDC)            4771             Did pre-authentication fail?
FS01 (resource host)  logon/access     Was resource access granted?

Why does a ServiceName count differ from an SPN count?

In a synthetic example, suppose svc_files holds the SPNs cifs/FS01 and cifs/files. Requests for the two different SPNs can appear in 4769 with the same svc_files ServiceName. A distinct ServiceName count treats this as one target account, not two SPNs. Directory inventory can show which SPNs belong to the account; this record alone does not reconstruct the exact requested SPN.

Detection logic · Sigma

title: Successful TGS records - candidate selection for target account correlation
id: 5f3f0f2a-0b2e-4f5b-9c11-06e0b2a0c102
status: experimental
description: >
  Selects successful 4769 records. ServiceName names the target account or computer,
  not the full requested SPN. Time windows and distinct ServiceName counts must be
  implemented outside this selection. It is not an alarm or proof of attack by itself.
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4769
    Status: '0x0'
  filter_machine_accounts:
    ServiceName|endswith: '$'
  filter_krbtgt:
    ServiceName|startswith: 'krbtgt'
  condition: selection and not 1 of filter_*
fields:
  - TargetUserName
  - ServiceName
  - ServiceSid
  - TicketEncryptionType
  - IpAddress
  - LogonGuid
falsepositives:
  - Inventory, backup and monitoring agents
  - Application servers connecting to many services
level: low

Query assumptions

• This Sigma selection chooses successful records for correlation; it performs no time-window grouping or distinct count. Grouping by IpAddress and TargetUserName, counting distinct ServiceName values and applying a threshold must be implemented separately in the backend.
• ServiceName names the account or computer for which the ticket was requested; it is not a direct SPN or service-instance count. ServiceSid and directory inventory can enrich account context, but one ServiceName value does not identify the SPN used in the request.
• Field names are EventData names in the Windows Security channel. If the backend uses different naming (for example, a normalized schema), field mapping should be done separately.
• The status field is stored as an integer in some backends, and as text in the format '0x0' in others. The match type must be validated against the target schema.
• Machine calculus and krbtgt filters reduce noise but also narrow the scope; SPNs registered to the machine account are not visible with this rule.
• This rule was not run on a real SIEM in this session. Only field names and event semantics were verified against the primary source.

False positives

• Backup, inventory and monitoring agents may request tickets for different service accounts in a short period. Compare increases in records with normal behavior.
• Batch connecting an application server to backend services produces the same pattern.
• At user login, the client requests tickets to several services in sequence; Logging in alone may also resemble the pattern.
• Negative example: if the target account's key is already obtained, the attacker does not need to request a new ticket and this rule sees nothing. The rule is a scope limit, not a proof.

Hardening

• First inventory: which SPN is registered in which account, which account's password is human-managed? Etype or account changes made without removing this list will result in a service interruption.
• Move human-managed service accounts to account types whose passwords are automatically generated and returned. This leaves the offline trial mechanism untargeted.
• Gradually harden etype policy: first measure current usage with TicketEncryptionType distribution, then implement in pilot scope, keep path back ready. Turning off RC4 directly across the domain may break dependent applications.
• Purge unused SPN records. A ticket cannot be generated for an unregistered SPN.
• Plan 4769 collection on the audit side: if volume, storage and filter rules are not determined in advance, the record will either not be collected or will become unusable.
• Verification step: repeat the same workflow after the change and see that the TicketEncryptionType value in the 4769 records has changed to the expected level and Status remains 0x0.

Read the examples

6d 81 b4 30 81 b1 a0 03 02 01 05 a1 03 02 01 0d
a3 11 1b 0f 49 59 45 4c 41 42 53 2e 45 58 41 4d
50 4c 45 a4 14 30 12 a0 03 02 01 01 a1 0b 30 09
1b 07 74 75 6e 61 68 61 6e a5 63 61 61 30 5f a0
03 02 01 05 a1 11 1b 0f 49 59 45 4c 41 42 53 2e
45 58 41 4d 50 4c 45 a2 27 30 25 a0 03 02 01 02
a1 1e 30 1c 1b 04 63 69 66 73 1b 14 46 53 30 31
2e 69 79 65 6c 61 62 73 2e 65 78 61 6d 70 6c 65
a3 1c 30 1a a0 03 02 01 12 a1 03 02 01 03 a2 0e
04 0c a5 5a a5 5a 01 02 03 04 05 06 07 08 a6 17
30 15 a0 03 02 01 12 a2 0e 04 0c f0 0f f0 0f 09
0a 0b 0c 0d 0e 0f 10

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-a5ba-3e3b0328c30d}" />
    <EventID>4769</EventID>
    <Version>2</Version>
    <Level>0</Level>
    <Task>14337</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8020000000000000</Keywords>
    <TimeCreated SystemTime="2026-09-28T09:14:31.7420000Z" />
    <EventRecordID>10486</EventRecordID>
    <Correlation />
    <Execution ProcessID="712" ThreadID="1048" />
    <Channel>Security</Channel>
    <Computer>DC01.iyelabs.example</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="TargetUserName">tunahan@IYELABS.EXAMPLE</Data>
    <Data Name="TargetDomainName">IYELABS.EXAMPLE</Data>
    <Data Name="ServiceName">FS01$</Data>
    <Data Name="ServiceSid">S-1-5-21-111111111-222222222-333333333-1108</Data>
    <Data Name="TicketOptions">0x40810000</Data>
    <Data Name="TicketEncryptionType">0x12</Data>
    <Data Name="IpAddress">::ffff:192.0.2.21</Data>
    <Data Name="IpPort">51477</Data>
    <Data Name="Status">0x0</Data>
    <Data Name="LogonGuid">{8f2a4c11-5d90-4a37-9be2-71c4ad0f3e55}</Data>
    <Data Name="TransmittedServices">-</Data>
    <Data Name="SessionKeyEncryptionType">0x12</Data>
  </EventData>
</Event>

Two reality checks

Assumption: If I can buy a ticket for a service, I can access that service.

In fact: No. RFC 4120 §1.4 and §10 clearly state that issuing a ticket should not be considered authorization; The application server must make a separate authorization decision. On Windows, this decision is made on the source host via DACL with the desired access mask and security context. Practical result: Accessing the file with the 4769 Status 0x0 record are two separate events; The former is not evidence of the latter.

Assumption: The key derived from the user's password is required to open the encrypted part of the TGS-REP; Therefore, when the password is changed, the existing tickets are useless.

In fact: The enc-part of the TGS-REP is encrypted with the sub-session key in the authenticator in accordance with RFC 4120 §5.4.2, or otherwise with the session key of the TGT; The user's long-term key is not used. The formal trace also confirms this: this EncryptedData does not contain the kvno field, because per §5.2.9 kvno is only meaningful for long-lived keys. Therefore, after changing the password, a new service ticket can be purchased with the existing TGT; Ticket life is limited by its own endtime and renew-till values, not by password change.

Sources

• RFC 4120 · The Kerberos Network Authentication Service (V5)
  §5.4.2 KRB_KDC_REP (ticket [5] and enc-part [6]; TGS-REP enc-part is protected with the sub-session key or the TGT session key, no kvno), §5.2.9 EncryptedData/kvno, §5.3 Ticket and EncTicketPart, §7.5.1 key usage 2/3/8/9, §3.2.3 AP-REQ validation order and KRB_AP_ERR_BADKEYVER, §1.4 and §10 authorization distinction, §6.2 NT-PRINCIPAL/NT-SRV-INST.; §§3.2.3–3.2.5 local AP validation, mutual-required and AP-REP encrypted with ticket session key (not AP authenticator subkey).
• Microsoft · 4769(S, F) A Kerberos service ticket was requested
  Subcategory Audit Kerberos Service Ticket Operations; Task 14337; Version 0 and Version 2 Event XML examples; EventData field definitions (ServiceName, ServiceSid, TicketEncryptionType, SessionKeyEncryptionType, Status, LogonGuid); etype table 0x12 and 0x17; Failure Code 0x0 and 0x20.
• Microsoft · Kerberos authentication overview
  Placement of the KDC role on a domain controller in Windows and the product terminology counterpart of the AS/TGS distinction.
• Microsoft · How DACLs control access to an object
  The access decision being made on the resource with the requested access rights and security context; a separate step from authentication.
• Microsoft Service principal names
  Service instance identifiers, aliases/multiple SPNs, registration on account object