Event ID 4776: NTLM Credential Validation and Its Error Code

What it records

Event 4776 belongs to the Audit Credential Validation subcategory, and Microsoft’s scope statement is narrow: “This event generates every time that a credential validation occurs using NTLM authentication.” Kerberos activity is logged elsewhere (4768, 4769, 4771), so everything in 4776 was checked by NTLM.

Where the event lands matters as much as what it says: “This event occurs only on the computer that is authoritative for the provided credentials. For domain accounts, the domain controller is authoritative. For local accounts, the local computer is authoritative.” The event names only the source: “It shows only the computer name (Source Workstation) from which the authentication attempt was performed (authentication source). For example, if you authenticate from CLIENT-1 to SERVER-1 using a domain account you’ll see CLIENT-1 in the Source Workstation field.” The destination server is not in the event, and neither is an IP address or a logon type.

Four data fields carry everything: Authentication Package (always MICROSOFT_AUTHENTICATION_PACKAGE_V1_0), Logon Account, Source Workstation and Error Code. Success and failure are both recorded; “If a credential validation attempt fails, you’ll see a Failure event with Error Code parameter value not equal to ‘0x0’.”

Microsoft’s table of the most common error codes:

Error Code	Microsoft’s description
0x0	”No errors.”
0xC0000064	”The username you typed does not exist. Bad username.”
0xC000006A	”Account logon with misspelled or bad password.”
0xC000006D	Generic logon failure — an invalid username and/or password, or a LAN Manager Authentication Level mismatch between source and target
0xC000006F	”Account logon outside authorized hours.”
0xC0000070	”Account logon from unauthorized workstation.”
0xC0000071	”Account logon with expired password.”
0xC0000072	”Account logon to account disabled by administrator.”
0xC0000193	”Account logon with expired account.”
0xC0000224	Account logon with “Change Password at Next Logon” flagged
0xC0000234	”Account logon with account locked.”
0xC0000371	”The local account store does not contain secret material for the specified account.”

Two generation quirks are worth remembering: the event “also generates when a workstation unlock event occurs”, and it “does not generate when a domain account logs on locally to a domain controller”. For local account logons Microsoft recommends event 4624 instead, because it “contains more details and is more informative”.

When it matters

Microsoft’s own framing: “The main advantage of this event is that on domain controllers you can see all authentication attempts for domain accounts when NTLM authentication was used.” That makes 4776 the cheapest domain-wide view of NTLM credential guessing.

Pattern	Microsoft’s reading
Repeated 0xC0000064 for one source	”an indicator of an account enumeration attack, especially relevant for highly critical accounts”
Repeated 0xC000006A for one account	”an indicator of a brute-force password attack”
0xC000006F, logon outside authorized hours	”Can indicate a compromised account”
0xC0000070, logon from unauthorized workstation	”Can indicate a compromised account”
0xC0000072 for a disabled account	”an indicator of an account compromise attempt”
0xC0000234, account locked	”Can indicate a brute-force password attack”

The monitoring guidance adds targets worth standing queries: high-value Logon Accounts (database and domain administrators, service accounts, domain controller accounts); accounts that should never be used, such as disabled or guest accounts; accounts outside an allowlist; Logon Account plus Source Workstation pairs for out-of-hours use; and account names that break your naming conventions. For a machine that stores local accounts, Microsoft suggests monitoring “for all events where Source Workstation and Computer (where the event was generated and where the credentials are stored) have different values” when a local account should only be used locally.

How to investigate

In Log Analytics the EventData names map to the SecurityEvent columns: TargetUserName is Logon Account, Workstation is Source Workstation, Status is the Error Code, and Computer is the authoritative machine that logged it. Start by grouping failures by source:

SecurityEvent
| where TimeGenerated > ago(24h)
| where EventID == 4776
| where Status !~ "0x0"
| summarize Attempts = count(), Accounts = dcount(TargetUserName),
            AccountList = make_set(TargetUserName, 20), Codes = make_set(Status, 10)
    by Workstation, Computer
| order by Accounts desc, Attempts desc

Many accounts from one Source Workstation is the spray shape; many attempts against one account is brute force. A blank Source Workstation still tells you which authoritative computer saw the traffic.

Then ask the question that sets severity — did the credentials eventually validate?

let badpass = SecurityEvent
    | where TimeGenerated > ago(24h) and EventID == 4776 and Status =~ "0xc000006a"
    | summarize Failures = count(), LastFail = max(TimeGenerated) by TargetUserName, Workstation;
SecurityEvent
| where TimeGenerated > ago(24h) and EventID == 4776 and Status =~ "0x0"
| join kind=inner badpass on TargetUserName, Workstation
| where TimeGenerated > LastFail
| project TimeGenerated, Computer, TargetUserName, Workstation, Failures, LastFail
| order by TimeGenerated asc

On a member server that is authoritative only for its own local accounts, validations whose Source Workstation is a different machine are the pattern Microsoft calls out for local accounts that should stay local:

SecurityEvent
| where TimeGenerated > ago(7d)
| where EventID == 4776
| extend HostShort = tolower(tostring(split(Computer, ".")[0]))
| where isnotempty(Workstation) and tolower(Workstation) != HostShort
| summarize Attempts = count(), Codes = make_set(Status, 10), Sources = make_set(Workstation, 20)
    by Computer, TargetUserName
| order by Attempts desc

Because 4776 holds no IP address or logon type, finish the pivot on the destination: 4625 for the matching failures with Logon Type and Source Network Address, 4624 for a session that was created, 4740 for a lockout that followed, and 4768/4769/4771 for the same account’s Kerberos side on the DC. The Windows 4625 password-spray rule covers the same grouping on the destination events. Without a SIEM, export the Security log as XML from Event Viewer and load it into the free browser log analyzer.