Event ID 4771 is a Windows Security audit event for Kerberos pre-authentication failure on a domain controller. It appears when the Key Distribution Centre cannot issue a ticket, such as after a wrong or expired password or a missing smart card certificate. Review failure codes, client addresses and account names for attack patterns.
What Event ID 4771 Tells You About Kerberos Failures
Event ID 4771 is more than a generic failed login record. It marks a Kerberos pre-authentication failure on a domain controller, which means the KDC could not validate the request well enough to issue a ticket and the failure may reflect either user error or hostile probing.
Because the event is generated at the authentication boundary, it is useful for separating ordinary password mistakes from repeated, patterned failures that may indicate password spraying, credential stuffing, or attempts to identify valid accounts. The failure code is often the fastest clue to whether the problem is an expired password, a bad secret, or a certificate-related issue.
Why 4771 Appears in Windows Security Logs
Windows records this event when Kerberos pre-authentication does not succeed during the ticket request process. In practice, that can happen when the supplied password is wrong, the account secret is out of date, or the client cannot satisfy pre-authentication requirements such as a smart card certificate.
The event is especially important on domain controllers because it sits close to the trust decision that precedes ticket issuance. That makes it a high-signal audit artifact for authentication health, account validation problems, and suspicious repetition against the same user, host, or source address.
How to Read the Event in Context
Useful triage starts with the failure code, client address, and account name. Those fields help you distinguish a single user mistake from a distributed pattern across many accounts or a concentrated pattern from one source. They also help you link the event to other logon activity, directory changes, or ticket requests around the same time.
Context matters because one 4771 event is rarely decisive on its own. A burst of failures from the same address, repeated failures against many usernames, or failures that coincide with unusual source geographies or devices all increase the likelihood that the event is part of an attack sequence rather than routine authentication noise. See the Windows Event Log Guide for the broader Windows audit model that places 4771 alongside other core logon and account events.
Detection, Response, and Identity Impact
Event ID 4771 is often a leading indicator rather than a final verdict. It can support early detection of credential attacks, but it also appears during legitimate user friction, so response should be shaped by repetition, distribution, and correlation with other authentication events. If exploitation is confirmed, the relevant identity impact is usually the same set of secrets that make Kerberos work: passwords, smart card credentials, and any accounts that were tested or abused.
That is why 4771 is useful in both security monitoring and post-incident review. It helps determine whether an account was merely mistyped, whether a password policy issue is causing repeated failure, or whether a real adversary is enumerating and validating credentials before moving to ticket-based abuse or broader domain activity.
For the Kerberos-specific attack paths that commonly sit behind repeated pre-authentication failures, the Kerberos Security Guide explains the ticketing context, while the Password Spraying and Credential Stuffing Defence Guide covers the failure patterns and defensive response that often show up around repeated 4771 events.
Risk and Threat Considerations
Repeated 4771 events can signal that an attacker is validating credentials at scale, probing for weak passwords, or testing whether an account can satisfy Kerberos pre-authentication. That matters because the event sits at the front door of domain authentication, where repeated failures may precede account compromise, ticket abuse, or broader movement inside the directory environment.
Failure mechanism: The KDC rejects the pre-authentication data, which can be caused by bad passwords, expired secrets, missing certificate material, or deliberate guessing activity against valid accounts.
Impact: If the pattern is malicious, it can expose weak accounts, create noisy but low-cost attack telemetry, and provide an attacker with a reliable way to identify valid targets before attempting escalation or persistence.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1110 — Brute Force | 4771 often reflects repeated credential validation against Kerberos pre-authentication. |
| Recommendation — Correlate clustered 4771 failures with T1110-style credential attacks and investigate source patterns. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | 4771 is an audit event that needs review and correlation for suspicious authentication behavior. |
| IA-5 — Authenticator Management | The event can indicate weak, expired, or misused authenticators affecting Kerberos pre-authentication. | |
| IA-2 — Identification and Authentication (Organizational Users) | Kerberos pre-authentication is part of organizational user authentication on domain controllers. | |
| Recommendation — Review 4771 telemetry with AU-6 to detect repeated failure patterns and escalate anomalies. Apply IA-5 to manage password and authenticator lifecycle issues that surface as 4771 failures. Use IA-2 to enforce strong authentication and investigate abnormal failed pre-authentication attempts. | ||
| CIS Controls v8 | CIS-5 — Account Management | Repeated 4771 failures often involve account validation, lockout, and credential hygiene decisions. |
| Recommendation — Use CIS-5 to monitor account authentication failures and manage lockout and review processes. | ||
Practitioner Guidance
What to watch for: Treat 4771 as a correlation event, not a standalone incident. Investigate clusters by account, source address, and failure code, and compare them with successful logons, ticket requests, and any sign of repeated attempts across many usernames. A single user error is common; a patterned burst is operationally different.
Governance implication: Make sure your monitoring rules and triage runbooks distinguish normal authentication friction from attack-shaped repetition. That keeps 4771 useful as an early warning signal instead of letting it drown in the background noise of ordinary failed logons.