Event ID 4768 records a Kerberos TGT request, the first authentication step of any domain logon. Only domain controllers write it, which makes it the authoritative record of where a logon began even when the client is not onboarded. Read the Result Code, the Pre-Authentication Type and the Client Address together.
| Field | What it tells you | Simulated value |
|---|---|---|
TargetUserName | The account for which the TGT was requested. Computer accounts end with a $ character. | a.chen |
TargetDomainName | The Kerberos realm the client claimed for the account; arrives as NETBIOS name, lowercase or uppercase FQDN depending on the client. | corp.socsimulator.example |
TargetSid | SID of the account for which the TGT was requested. Shows NULL SID in failure events. | S-1-5-21-424242-603855 |
ServiceName | The service the request was sent to; krbtgt for TGT requests, krbtgt/REALM in failure events. | simulated-servicename-7451AF |
ServiceSid | SID of the krbtgt service account, the built-in S-1-5-21-DOMAIN-502 principal. NULL SID in failure events. | simulated-servicesid-CE2757 |
IpAddress | IP address the TGT request was received from. Formats: IPv4 or IPv6, IPv4-mapped ::ffff:a.b.c.d, or ::1 for local requests on the DC. | 198.51.100.202 |
IpPort | Source port of the client connection; 0 for local requests. Values between 1 and 1023 indicate a well-known port was used as source. | 42248 |
TicketOptions | Requested ticket flags in hex; 0x40810010 (Forwardable, Renewable, Canonicalize, Renewable-ok) is the common Windows client value. | 0x8701DC49 |
Status | Hex result of the TGT issue operation; 0x0 on success, otherwise a Kerberos error code such as 0x6, 0x12 or 0x25. | 0x0 |
TicketEncryptionType | Cipher suite of the issued TGT; 0x12 (AES256) and 0x11 (AES128) expected, 0x17 is RC4, 0xFFFFFFFF appears in failure events. | 0x586D3914 |
PreAuthType | Numeric pre-authentication type used in the request; 2 is the normal encrypted timestamp, 0 means no pre-authentication, 15 to 17 are smart card, 138 is Kerberos Armoring. | simulated-preauthtype-D1ACD1 |
CertIssuerName | Certification authority that issued the smart card certificate; populated only for PKINIT logons. | simulated-certissuername-304E07 |
CertSerialNumber | Serial number of the smart card certificate used for the request, when applicable. | simulated-certserialnumber-804DF7 |
CertThumbprint | Thumbprint of the smart card certificate used for the request, when applicable. | simulated-certthumbprint-FDCBB3 |
Click a code to see what it means during triage and when it points at something worth escalating.
A representative Security entry for Event 4768, generated deterministically by our telemetry engine so every field holds a realistic, internally consistent value.
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Microsoft-Windows-Security-Auditing" />
<EventID>4768</EventID>
<Version>0</Version>
<Level>0</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x8020000000000000</Keywords>
<TimeCreated SystemTime="2025-10-26T19:56:11.000Z" />
<EventRecordID>567777</EventRecordID>
<Channel>Security</Channel>
<Computer>WS-SIM-001.corp.socsimulator.example</Computer>
<Security />
</System>
<EventData>
<Data Name="TargetUserName">a.chen</Data>
<Data Name="TargetDomainName">corp.socsimulator.example</Data>
<Data Name="TargetSid">S-1-5-21-424242-603855</Data>
<Data Name="ServiceName">simulated-servicename-7451AF</Data>
<Data Name="ServiceSid">simulated-servicesid-CE2757</Data>
<Data Name="IpAddress">198.51.100.202</Data>
<Data Name="IpPort">42248</Data>
<Data Name="TicketOptions">0x8701DC49</Data>
<Data Name="Status">0x0</Data>
<Data Name="TicketEncryptionType">0x586D3914</Data>
<Data Name="PreAuthType">simulated-preauthtype-D1ACD1</Data>
<Data Name="CertIssuerName">simulated-certissuername-304E07</Data>
<Data Name="CertSerialNumber">simulated-certserialnumber-804DF7</Data>
<Data Name="CertThumbprint">simulated-certthumbprint-FDCBB3</Data>
</EventData>
</Event>Successful requests with Pre-Authentication Type 0. Join against your list of accounts with the no-preauth flag; any account not on it, or any Client Address that is not the legacy system the flag was set for, is the finding. Lucene is the base filter; sort and enrich in Kibana.
index=wineventlog EventCode=4768 Pre_Authentication_Type=0 Result_Code=0x0 | rex field=Client_Address "^(::ffff:)?(?<src_ip>[0-9a-fA-F:.]+)$" | stats count min(_time) as first_seen max(_time) as last_seen values(src_ip) as sources by Account_Name | lookup no_preauth_accounts.csv Account_Name OUTPUT expected_source | where isnull(expected_source) OR mvcount(sources) > 1 OR NOT match(sources, expected_source)
Counts distinct Account Name values per normalized source in a short window, keeping the 0x6 versus 0x0 split so you can see enumeration turn into validated logons. Exclude your DCs and monitoring probes before tuning the threshold. Lucene is the base filter; aggregate in your SIEM.
index=wineventlog EventCode=4768 | rex field=Client_Address "^(::ffff:)?(?<src_ip>[0-9a-fA-F:.]+)$" | bucket _time span=10m | stats dc(Account_Name) as distinct_accounts count(eval(Result_Code="0x6")) as unknown_users count(eval(Result_Code="0x0")) as successes values(Account_Name) as accounts by _time, src_ip | where distinct_accounts >= 15 | sort - distinct_accounts
Finds accounts refused as revoked several times from one source in a short window, then pulls the 4771 pre-authentication failures from the same source in the preceding 15 minutes so the guessing phase is on the same screen as the lockout. Lucene is the base filter; run the sequence join in your SIEM.
index=wineventlog (EventCode=4768 Result_Code=0x12) OR (EventCode=4771 Failure_Code=0x18) | rex field=Client_Address "^(::ffff:)?(?<src_ip>[0-9a-fA-F:.]+)$" | transaction Account_Name src_ip maxspan=15m startswith=(EventCode=4771) endswith=(EventCode=4768) | where eventcount >= 5 | table _time, Account_Name, src_ip, eventcount, duration
Normalizes Client Address and tests it against the internal ranges. Replace the CIDR list with your own address plan, and expect VPN pools and cloud-hosted DCs to need their own entries. Elastic's source.ip is already normalized, so the Lucene range works without prefix handling.
index=wineventlog EventCode=4768
| rex field=Client_Address "^(::ffff:)?(?<src_ip>[0-9a-fA-F:.]+)$"
| where src_ip!="::1" AND NOT cidrmatch("10.0.0.0/8", src_ip) AND NOT cidrmatch("172.16.0.0/12", src_ip) AND NOT cidrmatch("192.168.0.0/16", src_ip)
| stats count values(Account_Name) as accounts values(Result_Code) as results by src_ip
| sort - countCompares today's successful TGT requests with the account-to-address pairs seen in the previous 30 days, scoped to a privileged account list so the output stays reviewable. Lucene cannot express the baseline diff; the query returns the raw pairs for a scheduled aggregation or an ML job.
index=wineventlog EventCode=4768 Result_Code=0x0 earliest=-30d | rex field=Client_Address "^(::ffff:)?(?<src_ip>[0-9a-fA-F:.]+)$" | lookup privileged_accounts.csv Account_Name OUTPUT is_privileged | where is_privileged="true" | stats min(_time) as first_seen max(_time) as last_seen count by Account_Name, src_ip | where first_seen >= relative_time(now(), "-1d@d") | convert ctime(first_seen) ctime(last_seen)
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.
Event 4768 telemetry feeds detections for these ATT&CK® techniques:
Reading about a kerberos authentication ticket (tgt) was requested is one thing. Working the detection inside a live console is another. These free SOCSimulator operations cover the attack techniques Event 4768 helps you detect:
A finance analyst's Microsoft Entra account is accessed without MFA from Moldova 18 minutes after their normal London sign-in. Impossible travel confirmed. The unauthorized session reads the inbox via Graph and adds an external recovery address. Work the Entra audit trail to identify the attacker IP, the compromised mailbox, and the persistence mechanism.
A password-spray campaign targets the Halcyon Freight SSL-VPN portal from two rotating source IPs, submitting credentials across many accounts to stay under per-account lockout thresholds. One account eventually matches. Reconstruct the spray, identify the compromised account and the operator IP that opened the active session, and trace the first move the attacker made over the tunnel.
“Event description (generates only on domain controllers, Audit Kerberos Authentication Service subcategory), the statement that result codes 0x10 and 0x18 generate 4771 instead, field descriptions including the ::ffff: Client Address formats, Table 3 TGT/TGS issue error codes, Table 5 Kerberos Pre-Authentication types, and the security monitoring recommendations for Pre-Authentication Type 0 and Client Address.”
“The Audit Kerberos Authentication Service subcategory that must be enabled (Success and Failure) on domain controllers for 4768 to be written.”
“T1558.004 AS-REP Roasting: adversaries request AS-REP messages for accounts with Kerberos pre-authentication disabled and crack the returned material offline; ATT&CK's own detection guidance points at 4768 with Pre-Authentication Type 0.”
“Microsoft Sentinel's SecurityEvent table exposes the 4768 event data as TargetUserName, IpAddress, PreAuthType, Status and TicketEncryptionType columns, which the KQL queries on this page use.”
Event ID 4769 explained for Kerberoasting detection: Service Name, ticket encryption type 0x17 vs 0x12, failure codes, a…
Read more Event IDEvent ID 4776 logs every NTLM credential validation on the DC or local host. Error codes, the Source Workstation pivot, …
Read more Event IDEvent ID 4625 explained: every Status/SubStatus failure code, TP/FP triage logic, and SPL/KQL/Lucene detection queries. …
Read more GlossaryA brute force attack systematically tries large numbers of username and password combinations, or decryption keys, until…
Read more GlossaryMulti-Factor Authentication (MFA) requires a user to prove their identity with two or more independent factors, somethin…
Read more GlossarySecurity Information and Event Management (SIEM) is a platform that aggregates, normalizes, and correlates log data from…
Read more GlossaryAlert triage is how a SOC sorts each alert: a Tier 1 analyst checks its context and severity, then calls it a true, fals…
Read more Career PathTier 1 SOC Analysts are the front line. You monitor alert queues, triage incoming detections, classify them as true or f…
Read more Career PathTier 2 SOC Analysts handle the investigations that Tier 1 escalates. You dig into multi-stage attacks, coordinate contai…
Read more TechniqueThis technique subverts Kerberos by stealing tickets from memory or forging them from domain secrets, enabling Pass-the-…
Read more TechniqueBrute Force covers any guess-driven path to credentials: classic password guessing, password spraying a few common passw…
Read more ComparisonSOCSimulator wins on operational realism. You get multi-tool shift simulation with SLA pressure, noise injection, and al…
Read more