A domain controller logs 40 Kerberos 4769 service-ticket requests from one host, all encryption type 0x17. What do you conclude?
answer
- the KDC records issuance, not use
- one field names the crypto used
- 0x17 is not the modern one
- many service principals, one account, minutes
- the cracking happens where you cannot see
basics
~20 sOne account asked the KDC for tickets to 40 services in RC4 (0x17) — the shape of kerberoasting, which harvests tickets to crack offline. The record proves tickets were issued, not that any service was accessed.
solid answer
~50 sEvent 4769 says the key distribution centre issued a service ticket for a named service principal to a named account, and it carries the client address it saw and the ticket encryption type. 0x17 is RC4-HMAC; 0x12 is AES256. Asking for many service tickets for many different service principals inside a short window, especially in RC4, is kerberoasting (`T1558.003`): the ticket is encrypted with a key derived from the service account's password, so the attacker cracks it offline with no further traffic to your estate. What the record proves is issuance. What it cannot prove is that any ticket was used, that any service was touched, or that cracking succeeded — the use of a ticket happens at the target service and shows up there, if anywhere, as a 4624 type 3. Before escalating, check which accounts legitimately enumerate service principals, because scanners and inventory tools do exactly this.
code
text · 8 linesEvent ID: 4769 (A Kerberos service ticket was requested)
Account Name: [email protected]
Service Name: svc_sql
Service ID: CORP\svc_sql
Client Address: ::ffff:10.14.6.88
Ticket Encryption Type: 0x17
Failure Code: 0x0
...go deeper
Know that 4768 is a ticket-granting-ticket request and 4769 a service-ticket request, both written by the domain controller when it issues them.
Explain which fields matter — service name, client address, encryption type — and why a burst of RC4 service tickets across many service principals is the kerberoasting shape.
Show the limits: issuance is not use, offline cracking leaves no trace in your estate, and a forged silver ticket produces no record at all. Then describe the baseline that keeps scanners out of your alert queue.
Own the trade-off between disabling RC4 across an estate of legacy services and keeping a cheap detection signal, and decide who carries the migration work and the breakage risk that comes with it.
## Two records, two moments Kerberos produces two authentication records on the domain controller that matter here: - **4768 — a Kerberos authentication ticket (TGT) was requested.** This is the initial authentication of the account to the domain. - **4769 — a Kerberos service ticket was requested.** The account already holds a TGT and is asking for a ticket to a specific service, identified by its service principal name. Both are written by the **KDC on a domain controller**, at the moment of *issuance*. ## Fields on 4769 that carry meaning - **Account Name** — the requesting principal, usually `user@REALM`. - **Service Name / Service ID** — the service principal the ticket is for. This is the field that tells you *what* was asked for. - **Client Address** — the address the KDC saw. It may be a NAT boundary, a VPN concentrator or a proxy, and it is often rendered as an IPv4-mapped IPv6 address. It localises a request to a network vantage point, not to a machine. - **Ticket Encryption Type** — `0x17` is RC4-HMAC, `0x12` is AES256-CTS-HMAC-SHA1-96, `0x11` is AES128. - **Failure Code** — `0x0` for a successful issuance. ## Why bulk RC4 requests are the classic finding A Kerberos service ticket is encrypted with a key derived from the **service account's password**. Anyone who can request a ticket for a service principal therefore walks away with material they can attack **offline**, at their own pace, on their own hardware — with no further authentication attempts, no failed logons and no traffic to your estate at all. That is kerberoasting. RC4 matters twice over. It is cheaper to crack than AES, so an attacker prefers it; and in an estate that has moved to AES, a request that asks for RC4 is itself anomalous, because it usually means the request was deliberately downgraded. The shape to look for is **one account, many distinct service principals, a short window**, often preceded by a directory query enumerating accounts that have service principal names. ## What the record does not prove This is the discipline the source demands: - **Issuance is not use.** A 4769 says the KDC handed out a ticket. Whether the ticket was ever presented to the service is not visible on the domain controller. The service host may record a 4624 type 3 when the ticket is used — and may not, depending on its audit policy. - **Issuance is not compromise.** An offline crack may fail entirely against a long, random service-account password. The record cannot tell you whether it succeeded, and nothing else will either until the credential is used. - **Absence is not innocence.** A forged **silver ticket** is minted with the service account's key and presented straight to the service; the KDC never sees the request and no 4769 exists. Evidence for that lives on the target host — a Kerberos session for an account with no corresponding ticket request, or ticket fields that disagree with the domain. A related case on the other record: accounts flagged "do not require Kerberos pre-authentication" can be attacked without any credential at all (AS-REP roasting), visible as **4768** requests with a pre-authentication type of 0. ## Baselining before escalating Vulnerability scanners, inventory tools, monitoring agents and some administrative consoles legitimately request tickets for many service principals. The question is not "did this happen" but "does this account, from this address, at this hour, normally do this". Without that baseline the detection is an alarm on an inventory job. ## The hybrid complication On an estate with an on-premises domain **and** a cloud identity provider, the same human is three different subjects: `CORP\jsmith` in Active Directory, a user principal name plus an immutable object identifier at the identity provider, and possibly a third application-specific identifier in the SaaS audit trail. A timeline that puts Kerberos ticket requests next to cloud sign-ins is only meaningful once those identifiers are mapped to one person, and that mapping is a piece of engineering, not an assumption. Analysts who skip it produce timelines with a gap exactly where the account crossed the boundary.
- What does the Client Address field on a 4769 actually tell you?It is the address the KDC observed for the request, which may be a NAT boundary, VPN concentrator or proxy, and is often written as an IPv4-mapped IPv6 value. It places the request at a network vantage point, not on a specific machine. Pair it with endpoint telemetry or DHCP records before you name a host in a report.
- Would 4769 catch a forged silver ticket?No. A silver ticket is forged using the service account's key and presented directly to the service, so the KDC is never asked and writes nothing. You would look at the target service host instead, for a Kerberos session belonging to an account that has no matching ticket request, or ticket contents that disagree with the domain.
- Beyond crackability, why does encryption type 0x12 versus 0x17 matter?0x12 is AES256 and 0x17 is RC4-HMAC. RC4 is both weaker and cheaper to attack offline, and in an estate that has moved services to AES, an RC4 request is anomalous on its own terms because it usually means the client deliberately downgraded. The field turns a preference into a detectable behaviour.
saying these in an interview costs you the question
- Reads a service-ticket request as proof the service was accessed
- Claims the record shows whether the ticket was cracked
- Ignores the encryption type field entirely
- Treats the client address as a definitive host identification
- Assumes no 4769 means no Kerberos abuse occurred