Windows Security Log · Event 4776

Event 4776: NTLM credential validation on a domain controller

A domain controller checked a password using NTLM and recorded whether it matched. It is the place NTLM sign-in failures land when the machine the user actually touched is not one you collect logs from, which makes it the widest net you have for failed authentication.

Also written as 4776Event ID 4776NTLM validation 4776

How oftenFires often
Vendor calls itAudit Success / Audit Failure
LogSecurity
SourceMicrosoft-Windows-Security-Auditing

What it means for you

On a personal computer

This only appears on Windows Server domain controllers in a business network. A home PC does not produce it.

For an analyst

The Error Code field maps to the same NTSTATUS values as the 4625 SubStatus, so triage transfers directly. Its advantage over 4625 is coverage — every NTLM authentication in the domain reaches a DC, so you catch failures from machines you have no agent on. Its weakness is the Source Workstation field, which is client-supplied and trivially forged.

What it looks like

Sanitised. Addresses come from the RFC 5737 documentation ranges.

Sample

The computer attempted to validate the credentials for an account.

Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
Logon Account:  jbrooks
Source Workstation: LAPTOP-J7X2
Error Code:  0xC000006A

The fields that decide it

Everything else in the log line is context.

TargetUserName: The account whose password was being checked. Recorded without the domain prefix.
Workstation: The name the client machine claimed. It is supplied by the client, so treat it as a hint rather than evidence.
Status: The result of the credential check. 0x0 means the password matched.
PackageName: The NTLM variant used. MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 is the usual value.

Ordinary reasons this happens

Most of the time it is one of these.

Ordinary sign-ins from machines and applications that use NTLM rather than Kerberos.
Access by IP address rather than hostname, which forces a fallback from Kerberos to NTLM.
Legacy line-of-business applications and appliances that only speak NTLM.
A user mistyping a password, producing a single 0xC000006A.
A stale saved credential on a phone or a mapped drive, producing 0xC000006A on a steady schedule.

When it is not ordinary

Password spraying across the domain.

What gives it awayMany distinct TargetUserName values with 0xC000006A from one Workstation value, or from a blank one, spread out over hours.

ATT&CK T1110.003

Username enumeration before an attack.

What gives it awayA sequence of 0xC0000064 failures. The attacker is learning which account names are real.

ATT&CK T1589.002

Brute force against one account.

What gives it awayOne account, high volume of 0xC000006A, usually ending in a 4740 lockout.

ATT&CK T1110.001

Authentication from an unexpected source through a VPN or published service.

What gives it awayA blank Workstation value paired with accounts that never authenticate remotely.

ATT&CK T1078

What to do next

Filter to Status values other than 0x0 first. Successes are the bulk of the volume and rarely the question.
Read the status code. 0xC0000064 and 0xC000006A mean very different things about what the other side already knows.
Count distinct TargetUserName values per Workstation over the last day. More than a handful is spraying.
Treat the Workstation value as a lead, not proof — it is whatever the client claimed.
Cross-check against 4624 on the same account to see whether anything eventually succeeded.
If NTLM volume is high in a domain that should be using Kerberos, work out which application is forcing the fallback.

Queries to run

kql Spraying expressed as distinct accounts per claimed workstation.

SecurityEvent | where EventID == 4776 and Status != '0x0' | summarize attempts = count(), accounts = dcount(TargetUserName) by Workstation, bin(TimeGenerated, 1h) | where accounts > 5 | order by accounts desc

kql Username enumeration — a burst of attempts against accounts that do not exist.

SecurityEvent | where EventID == 4776 and Status == '0xC0000064' | summarize count() by Workstation, bin(TimeGenerated, 30m) | where count_ > 10

splunk

index=wineventlog EventCode=4776 Error_Code!=0x0 | stats count dc(Logon_Account) as accounts by Source_Workstation | where accounts > 5

Common questions

What is the difference between Event 4776 and Event 4625?

They record the same failure from different vantage points. 4625 is written on the machine the sign-in was aimed at; 4776 is written on the domain controller that checked the password. 4776 is more useful for domain-wide hunting because every NTLM authentication reaches a DC, even from machines you do not collect logs from.

What does error code 0xC000006A mean in Event 4776?

The username exists and the password was wrong. It is the ordinary mistyped-password result, and also what password guessing produces — the difference is volume and how many different accounts are involved.

Why is the Source Workstation field blank in Event 4776?

The client supplies that name, and plenty of legitimate paths do not set it — VPN concentrators, load balancers, and some appliances all authenticate without one. Attacker tooling often omits it too, so a blank value is worth noting but is not evidence by itself.

Should I be seeing Event 4776 at all if my domain uses Kerberos?

Some, yes. Windows falls back to NTLM when a service is reached by IP address instead of hostname, when an application only supports NTLM, and for local account authentication. A large and growing NTLM share is worth investigating as a configuration problem rather than an attack.

Mentioned by

Event 4768: A Kerberos ticket (TGT) was requested

Vendor documentation

Last reviewed 28 August 2026