← 02 — Articles

Kerberos in Windows logs: reading 4768, 4769 and 4771

Detection engineering7 min read

Kerberoasting, AS-REP roasting, password spraying, forged and abused tickets: most of the well-known attacks on Active Directory identity pass through the Kerberos Key Distribution Center (KDC) on a domain controller. The KDC logs every ticket it issues and every pre-authentication it rejects. Those events are high-volume and look identical at a glance, and the difference between a normal day and an attack sits in three or four hex fields.

This article explains those fields. It is about reading the events, not a rule set: once you can read them, the detections follow, and they will fit your environment better than anything copied.

Before any of this: what must be enabled

All three events are written only on domain controllers, and only when two audit subcategories are on:

Event Audit subcategory Setting
4768 A Kerberos authentication ticket (TGT) was requested Account Logon > Audit Kerberos Authentication Service Success and Failure
4771 Kerberos pre-authentication failed Account Logon > Audit Kerberos Authentication Service Failure
4769 A Kerberos service ticket was requested Account Logon > Audit Kerberos Service Ticket Operations Success and Failure

Both are part of the domain controller baseline in Windows audit policy that detections can rely on. Collect them from every domain controller: a client talks to whichever DC answers, so a gap on one DC is a gap in your data, not a smaller sample.

Expect volume. 4769 is one of the busiest events in a domain — every access to a file share, SQL server or web application with Windows authentication requests a service ticket. Measure it per DC before you decide to send all of it to an expensive tier.

The exchange in three events

Kerberos in a Windows domain works in two steps, and the events follow them:

  1. Authentication Service (AS) exchange. A user or computer proves it knows its password (pre-authentication) and receives a ticket-granting ticket (TGT). Success is 4768; a rejected pre-authentication is 4771; other failures are 4768 with a non-zero result code.
  2. Ticket-Granting Service (TGS) exchange. With the TGT, the client asks for a service ticket for a specific service, identified by its Service Principal Name (SPN). That request is 4769, success or failure.

The service ticket is encrypted with a key derived from the service account’s password. That one fact explains why 4769 matters so much: anyone with a TGT can request a ticket for any SPN and try to crack it offline.

Fields that carry the signal

TicketEncryptionType

The encryption type of the issued ticket, in 4768 and 4769:

Value Name What it means today
0x12 AES256-CTS-HMAC-SHA1-96 the normal case
0x11 AES128-CTS-HMAC-SHA1-96 normal, less common
0x17 RC4-HMAC legacy; worth explaining every time
0x1, 0x3 DES disabled by default since Windows 7 and Server 2008 R2; should not appear
0xFFFFFFFF — failure events

Microsoft’s own monitoring guidance for 4769 is to watch for anything other than 0x11 and 0x12. RC4 matters because RC4-encrypted tickets are much faster to crack offline than AES ones, which is why Kerberoasting tools traditionally ask for RC4.

ServiceName and the account behind it

In 4769, ServiceName is the account the ticket is for. Computer accounts end in $ and have long random passwords managed by Windows. A ticket for a user account — svc_backup, sql_prod — is a ticket encrypted with a password a human chose and may not have changed in years. krbtgt appears when tickets are renewed or requested against the TGT itself.

PreAuthType (in 4768 and 4771)

How the client proved its identity:

Value Meaning
0 no pre-authentication
2 encrypted timestamp — the normal password logon
15, 16 smart card / certificate (PKINIT)
138 encrypted challenge (Kerberos armoring, FAST)

0 means the account has Do not require Kerberos preauthentication set. The KDC then hands out material encrypted with the account’s key to anyone who asks — the basis of AS-REP roasting. Accounts with that flag should be rare enough to list by name.

Status — the failure code

The codes that explain most failures:

Code Event Meaning
0x6 4768 user name does not exist
0x12 4768, 4771 account disabled, expired or locked
0x17 4771 password expired
0x18 4771 wrong password
0x25 any clock skew too great
0x20 4769 ticket expired — routine, ignore

IpAddress and TargetUserName

IpAddress is the client, often in the form ::ffff:10.0.4.17; ::1 means the request came from the domain controller itself. TargetUserName is the requesting account in 4768 and 4771, and the requester in 4769 (where it appears as user@REALM).

What attacks look like in these fields

Without turning this into a rule set, these are the shapes to recognize:

  • Kerberoasting (T1558.003). 4769 for a user account with an SPN, with TicketEncryptionType 0x17, often several different service accounts requested by one user within a short time. On a domain where everything negotiates AES, a single RC4 service ticket for a user account stands out.
  • AS-REP roasting (T1558.004). 4768 with PreAuthType 0 for an account that should not have pre-authentication disabled, especially from a workstation that has no business with it.
  • Password spraying (T1110.003). 4771 with 0x18 across many different accounts from one IpAddress, a few attempts each — the opposite of the stale-credential pattern, which is one account failing repeatedly from one machine. Where the failed logons on your domain controllers come from covers how to tell them apart.
  • Enumeration. 4768 with 0x6 (user does not exist) for many names from one source.

Each of these has legitimate look-alikes: old applications that only speak RC4, a vulnerability scanner, an administrator testing accounts. That is why each shape needs tuning against your own environment before it becomes an alert.

What changed in 2025 and 2026

Two changes make older guides partly out of date.

New fields in 4768 and 4769. On Windows Server 2016 and later, the January 14, 2025 security update or later produces an updated version of these events. Among the new fields: the encryption types the requesting account, the service and the domain controller support (AccountSupportedEncryptionTypes, ServiceSupportedEncryptionTypes, DCSupportedEncryptionTypes), which keys each of them actually has (…AvailableKeys), what the client advertised (ClientAdvertizedEncryptionTypes) and the SessionKeyEncryptionType. They answer the question every RC4 investigation used to require a separate lookup for: could this ticket have been AES? A service account whose ServiceAvailableKeys lists only RC4 has never had its password changed since AES keys started being generated, and that is a finding on its own. Parsers written for the old event version may not extract the new fields: check yours.

RC4 is being turned off by default. Microsoft’s KB5073381 (CVE-2026-20833) changes the KDC’s default so that accounts without an explicit msDS-SupportedEncryptionTypes value get AES-SHA1 only. It was rolled out in phases through 2026, with audit events on domain controllers for accounts that still depend on RC4 by default. Once enforcement is in place in your domain, RC4 service tickets should only exist for accounts where someone explicitly allowed RC4 — which makes every remaining 0x17 easier to explain or remove. Check which phase your domain controllers are in before you assume either state.

Testing what you collect

You can generate each event safely on a test domain or on your own account:

  • klist purge and then accessing a file share produces a 4768 and a 4769 for your account.
  • klist get cifs/SRV-APP01.corp.example requests a specific service ticket and shows its encryption type locally, which you can compare with the 4769 on the DC.
  • A deliberate wrong password at a domain logon produces 4771 with 0x18.

Find each event in your SIEM and confirm that TicketEncryptionType, PreAuthType, Status and IpAddress are parsed as fields, not left inside the raw message. Emulating actual attack techniques belongs in a lab, with the domain owner’s approval.

Limitations

  • These events show requests to the KDC. Use of a forged ticket that never touched the KDC (a golden ticket presented directly to a service) does not appear here; it shows up, if at all, on the target system.
  • 4769 volume can make long retention expensive. Short retention limits how far back you can look when you find a compromised service account.
  • Not every failure is logged by default. Some 4769 failure codes appear only with additional KDC logging enabled.

Adapting this to your environment

  • ADAPT the list of accounts with SPNs: Get-ADUser -Filter {ServicePrincipalName -like "*"} -Properties ServicePrincipalName lists user accounts that can be Kerberoasted. Every one of them should have an owner and a long, rotated password — or be replaced by a group managed service account.
  • ADAPT the RC4 picture: list the accounts that still receive 0x17 tickets, and the systems requesting them, before the defaults change under you.
  • ADAPT the pre-authentication list: Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} should return nothing, or a short list someone can justify.

Questions and corrections: hello@entropywatch.dev.