0x18: Kerberos Pre-Authentication Failed (KDC_ERR_PREAUTH_FAILED) in 4771

What it means

Kerberos pre-authentication is the step where the client proves it knows the account’s key — normally by encrypting a timestamp with a key derived from the password — before the KDC will issue a TGT. Failure code 0x18, KDC_ERR_PREAUTH_FAILED, means the domain controller could not validate that proof. Microsoft’s “possible causes” text for this code is blunt: “The wrong password was provided.”

The code is carried by event 4771 (Kerberos pre-authentication failed) in the Failure Code field, and only there: the 4768 documentation states that event 4768 “doesn’t generate for Result Codes: 0x10 and 0x18. Event ‘4771: Kerberos pre-authentication failed.’ generates instead.” Microsoft notes for both events that “This event generates only on domain controllers”, so you collect them from DCs, not from member servers or workstations.

Two fields decide how you read the event. Client Address is “IP address of the computer from which the TGT request was received”, written as an IPv6 or IPv4 address, as ::ffff:IPv4_address, or as ::1 for localhost — strip the ::ffff: prefix before comparing against your IPv4 inventory. Account Name (TargetUserName) is the principal whose key failed to validate. Event 4771 also carries ServiceName (typically krbtgt/DOMAIN), IpPort, and certificate fields; for smart-card problems Microsoft points at failure code 0x10 instead, which “can help you to more quickly identify smart-card related problems with Kerberos authentication.”

Is it an attack?

Pattern	Reading
One or two 0x18 for a user, then a 4768 with result 0x0 from the same address	Mistyped password, then a correct one
0x18 for one account every few minutes from one internal host, around the clock	A saved credential — service, scheduled task, mapped drive or mobile mail client — still using the pre-reset password
Dozens of 0x18 for one account in minutes	Brute force. Microsoft’s guidance: “N events in last N minutes. This issue can indicate a brute-force attack on the account password, especially for highly critical accounts.”
One client address, 0x18 across many distinct accounts, few attempts each	Password spraying over Kerberos
0x18 mixed with 4768 result code 0x6 from the same source	Spraying with a guessed name list — 0x6 is “The username doesn’t exist”

Kerberos spraying does not have to touch a member server, so it may never produce a 4625. Detections built only on 4625 — such as the Windows 4625 password-spray rule — should be paired with a 4771 view of the domain controllers. In event 4625 and in NTLM credential validation (event 4776), the matching Windows status is 0xC000006A — a wrong password for a real account.

How to investigate

Start by ranking client addresses by how many distinct accounts each one failed against:

SecurityEvent
| where TimeGenerated > ago(1d)
| where EventID == 4771 and Status =~ "0x18"
| extend ClientIp = replace_string(IpAddress, "::ffff:", "")
| summarize Failures = count(), Accounts = dcount(TargetUserName),
            AccountList = make_set(TargetUserName, 20),
            FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
    by ClientIp, Computer
| order by Accounts desc, Failures desc

Then look for bursts against a single account, the shape Microsoft calls out for brute force:

SecurityEvent
| where TimeGenerated > ago(1d)
| where EventID == 4771 and Status =~ "0x18"
| extend ClientIp = replace_string(IpAddress, "::ffff:", "")
| summarize Failures = count() by bin(TimeGenerated, 10m), TargetUserName, TargetDomainName, ClientIp
| where Failures >= 10
| order by TimeGenerated asc

The question that sets severity is whether any of those attempts eventually succeeded — a TGT issued with result code 0x0 from the same address, after the failures:

let preauthFails = SecurityEvent
    | where TimeGenerated > ago(1d) and EventID == 4771 and Status =~ "0x18"
    | extend ClientIp = replace_string(IpAddress, "::ffff:", "")
    | summarize FailCount = count(), LastFail = max(TimeGenerated) by TargetUserName, ClientIp;
SecurityEvent
| where TimeGenerated > ago(1d) and EventID == 4768 and Status =~ "0x0"
| extend ClientIp = replace_string(IpAddress, "::ffff:", "")
| join kind=inner preauthFails on TargetUserName, ClientIp
| where TimeGenerated > LastFail
| project TimeGenerated, Computer, TargetUserName, ClientIp, IpPort, FailCount

A success following a burst means the password was guessed: reset the account, pull the service tickets requested afterwards (event 4769 from the same source), and isolate the client if it is a domain-joined host. If the source is one of your own servers and the cadence is regular, hunt for the stored credential instead. Exported Security logs can also be grouped by account and client address in the free browser log analyzer.