Event ID 4768: A Kerberos authentication ticket (TGT) was requested

Event ID 4768 belongs to the Audit Kerberos Authentication Service subcategory and fires on the domain controller whose KDC answered a Kerberos AS-REQ, the very first message a client sends when it wants a Ticket Granting Ticket. Nothing else produces it. A workstation, a member server, a Linux box joined with SSSD, a Mac bound to the domain: none of them log this event locally, because none of them run a KDC. It generates only on domain controllers, and Microsoft documents it as (S, F): a success audit when the TGT was issued, a failure audit when it was not.

That placement is the whole reason the event matters to a SOC. When a user unlocks a laptop, opens Outlook, or a script authenticates with a service account, the KDC sees the AS exchange whether or not the endpoint ships its own logs anywhere. An estate that has onboarded only its Windows servers still gets a complete record of who requested a TGT, for which realm, from which IP address, because that record is written on DC01, not on the laptop. Onboarding every domain controller (all of them, not just the PDC emulator, since any DC can service the AS exchange) is therefore a precondition for using this event at all. Miss one DC and you have a hole shaped like every client that happens to sit in that DC's site.

The account side is straightforward. Account Name is the principal that asked for the ticket, with computer accounts ending in a dollar sign. Supplied Realm Name is the Kerberos realm the client claimed, which can arrive as CONTOSO, contoso.local, or CONTOSO.LOCAL depending on who sent it. User ID is the SID, and Microsoft notes it shows as NULL SID in failure events, so a null User ID next to a non-zero Result Code is not corruption, it is how a rejected AS-REQ looks. Service Name is almost always krbtgt (or krbtgt/REALM on failures) because the AS exchange is by definition a request to the ticket-granting service. Ticket Options carries the requested flags, with 0x40810010 (Forwardable, Renewable, Canonicalize, Renewable-ok) the dominant value from Windows clients.

Pre-Authentication Type is the single most useful field on this page and the one general Kerberos references gloss over. Kerberos pre-authentication exists so the KDC can refuse to hand out an encrypted AS-REP to anyone who merely knows a username. Microsoft's table lists the values you will meet in an Active Directory domain:

• 0: logon without pre-authentication. The client sent no proof of identity and the KDC answered anyway.
• 2: PA-ENC-TIMESTAMP, an encrypted timestamp. This is the normal type for standard password authentication and should dominate your volume.
• 15, 16 and 17: PA-PK-AS-REP_OLD, PA-PK-AS-REQ and PA-PK-AS-REP, the smart card and certificate (PKINIT) path.
• 20: PA-SVR-REFERRAL-INFO, used in KDC referral tickets.
• 138: PA-ENCRYPTED-CHALLENGE, Kerberos Armoring (FAST), available from Windows Server 2012 DCs and Windows 8 clients.
• 11 and 19 (PA-ETYPE-INFO, PA-ETYPE-INFO2) are KDC-to-client hints that Microsoft says it has never observed in an AD environment.

Type 0 is the AS-REP roasting signal. An account with the "Do not require Kerberos preauthentication" flag set (UF_DONT_REQUIRE_PREAUTH) lets anyone who can reach a DC request its TGT unauthenticated. The AS-REP that comes back contains material encrypted with the account's password-derived key, which tools like Rubeus, Impacket's GetNPUsers.py and the hashcat 18200 mode crack offline at leisure. The domain controller sees exactly one thing during that attack: a successful 4768, Result Code 0x0, Pre-Authentication Type 0, Client Address set to whichever host ran the tool. No failure, no lockout, no 4771. If your detection logic only watches failures, this technique is invisible to it.

Microsoft's own monitoring recommendation is blunt: all accounts should use pre-authentication, and a value of 0 should be investigated. The operational refinement is to combine the field with the account's real flag state. A type 0 request for an account that genuinely has pre-authentication disabled is the attack in progress or a legacy application doing something it should not; a type 0 request for an account that does not have the flag should not be possible and points at a misread or an unusual client. Either way, the list of accounts carrying that flag should be short enough to know by name, and every 4768 with type 0 against one of them deserves a ticket.

Two other Pre-Authentication Type checks are cheap and worth running. Where smart cards are mandatory, a value that is not 15 (or 16 and 17) for those accounts means the policy is being bypassed with a password. Where Kerberos Armoring is enforced domain-wide, anything other than 138 is a client outside the policy.

Result Code is 0x0 when the TGT was issued. Anything else is a failure audit, and the codes you will actually see in an AS exchange are a short list:

• 0x6, KDC_ERR_C_PRINCIPAL_UNKNOWN: the username does not exist in the Kerberos database. One of these is a typo. Dozens from one Client Address in a few minutes is account enumeration, and Microsoft names it as such.
• 0x7, KDC_ERR_S_PRINCIPAL_UNKNOWN: the server principal could not be found. Rare on a pure TGT request; usually a naming or SPN problem, not an attacker.
• 0xC, KDC_ERR_POLICY: a logon restriction on the account blocked the request, typically workstation restrictions, a smart card requirement, or logon hours.
• 0x12, KDC_ERR_CLIENT_REVOKED: the account is disabled, expired, or locked out. Microsoft describes it as "explicit disabling or other restrictions in place on the account".
• 0x17, KDC_ERR_KEY_EXPIRED: the password has expired and must be changed.
• 0x1F, KRB_AP_ERR_BAD_INTEGRITY: an integrity check on a decrypted field failed, which can be network noise or tampering.
• 0x25, KRB_AP_ERR_SKEW: the client's clock differs from the KDC by more than the "Maximum tolerance for computer clock synchronization" policy, five minutes by default.

The code that trips analysts up is 0x12. It is not a bad-password code. A cluster of 0x12 against one account after a run of pre-authentication failures means the lockout threshold has already been crossed and the KDC is now refusing everything, so the interesting events are the ones just before the cluster started. A steady trickle of 0x12 for a disabled account, every few minutes from the same Client Address, is almost always a scheduled task or a mapped drive nobody cleaned up after offboarding. A 0x12 for an account that should be enabled and is not locked out is worth a call to the identity team, because something changed the account state.

0x25 is operational until it is not. A single host drifting past the skew tolerance produces a burst of 0x25 for every user on it until w32time catches up. A 0x25 from a Client Address that has never authenticated before, against several accounts, can be a tool with the wrong clock, which is a useful tell precisely because attackers rarely bother to sync time on a foothold.

The most common failure of all, the wrong password, does not appear in this event. Microsoft states that 4768 does not generate for Result Codes 0x10 (PADATA type not supported, the smart card certificate case) and 0x18 (KDC_ERR_PREAUTH_FAILED, wrong password); event 4771, Kerberos pre-authentication failed, is written instead. The logic is that pre-authentication happens before the KDC decides whether to issue a ticket. If the encrypted timestamp does not decrypt, the request never reaches the ticket-issuing step, so the failure is a pre-authentication failure, not a ticket-issue failure.

For a SOC this means brute force against Kerberos is a two-event problem. The guesses land in 4771 with 0x18. The moment the account locks, the same source starts producing 4768 with 0x12, because a locked account is refused before the timestamp is even checked. Any query that counts only 4768 failures will see the lockout tail and miss the guessing; any query that counts only 4771 will see the guessing and miss confirmation that it worked long enough to lock the account. The enumeration phase that precedes both (which usernames exist) lives entirely in 4768 as 0x6, because an unknown principal has no key to pre-authenticate with. Build the timeline across both events, keyed on Client Address.

Client Address is the IP address of the computer from which the TGT request was received. It is the login-origin pivot for this event, and it is populated for every request that crossed the network, which makes it more reliable than the WorkstationName field on endpoint logon events that can be blank or attacker-controlled. Microsoft documents three formats: a plain IPv4 or IPv6 address, an IPv4-mapped IPv6 address of the form ::ffff:10.0.0.12, and ::1 for localhost.

The mapped form is the one that breaks queries. Windows DCs log IPv4 clients as ::ffff:a.b.c.d in the raw event, so a naive IpAddress == "10.0.0.12" filter matches nothing, a CIDR function fed the raw string errors out, and an allow-list join on a clean IPv4 column silently produces zero matches. Normalize the field before you do anything else: strip the ::ffff: prefix in the query (every example below does this), or normalize at ingest. Elastic's Windows Security integration already writes the cleaned value to source.ip, which is why the Lucene queries here prefer that field. Splunk's Windows TA surfaces the raw string as Client_Address; Microsoft Sentinel's SecurityEvent table keeps it as IpAddress.

Two Client Address patterns Microsoft calls out are worth standing rules. Requests where the value is ::1 are local authentication on the DC itself, so any Account Name in that set that is not permitted to log on to domain controllers is a violation. And requests where Client Port is above 0 but below 1024 used a well-known port as the source, which normal Windows clients do not do.

The benign floor for 4768 is enormous. Every domain user produces one at the start of the day and again whenever a TGT expires (ten hours by default), every computer account produces them on boot and on service restarts, and every DC produces them for other DCs. Successes with Pre-Authentication Type 2 from a Client Address inside the corporate range are the water the SOC swims in, and no rule should page on them.

What makes a true positive is a combination, never a single field. Pre-Authentication Type 0 on an account known to carry the no-preauth flag, from a Client Address that is a workstation rather than the legacy application server the flag was set for, is a real AS-REP roasting attempt. A single Client Address requesting TGTs for many distinct Account Names inside a short window, with a mix of 0x6 and 0x0, is enumeration followed by validation, whatever the source claims to be. A privileged account's first ever TGT request from a Client Address it has never used, especially a VPN pool address or a jump host outside its tier, is the one to escalate before waiting for volume.

The false positives cluster around infrastructure. A new DHCP scope or a VPN concentrator migration shifts every user's Client Address at once, which floods a first-seen rule for a day. A monitoring platform that authenticates as a service account from every probe node looks like one account requesting from many addresses. A domain-joined Linux host with an old SSSD configuration can request without pre-authentication or with a non-2 type and is a config bug, not an intrusion, though it still needs fixing because it is exactly the gap an attacker would prefer you leave open. Clock skew (0x25) after a VM snapshot restore is noise; the same code from an address with no asset record is not.

A Tuesday at 14:20 the analyst on shift gets a low-severity alert from the type 0 rule: one 4768, Result Code 0x0, Pre-Authentication Type 0, Account Name svc_legacyfax, Client Address ::ffff:10.40.7.213. The account is on the known no-preauth list, so the rule fires at low priority by design. The analyst strips the prefix, resolves 10.40.7.213 to a marketing laptop, and that is already wrong, because svc_legacyfax is only ever used from the fax gateway at 10.20.1.50.

Widening to every 4768 from 10.40.7.213 in the last hour turns up the shape of the thing: at 14:11 to 14:14, forty-one requests with Result Code 0x6 against names like admin, backup, helpdesk and svc_sql, then six 0x0 successes with Pre-Authentication Type 2 for real user accounts, then the single type 0 request. That is a username list being validated, followed by a credential the attacker already had being confirmed, followed by an AS-REP roast against the one account whose flag makes it crackable offline. Pulling 4771 for the same address shows no 0x18 at all; nothing was guessed, which fits a tool that only tests what it knows and roasts what it can.

The laptop goes to containment, svc_legacyfax gets a long random password and the pre-authentication flag re-enabled with the fax vendor on the phone, and the six validated user credentials are reset. The whole picture came from one domain controller's Security log and one normalized Client Address. The laptop itself had never been onboarded to the SIEM.