Event ID 4776: The computer attempted to validate the credentials for an account

Event ID 4776 belongs to the Audit Credential Validation subcategory of the Account Logon category, and it is generated every time a credential validation happens through NTLM authentication. The provider is Microsoft-Windows-Security-Auditing, the channel is Security, and the event has existed in this shape since Windows Server 2008 and Vista (event version 0, no later revisions). You need the subcategory enabled for both Success and Failure to get the full picture, and most environments that audit account logon at all already have it on.

The event is deliberately thin. It carries four data values: the authentication package (always MICROSOFT_AUTHENTICATION_PACKAGE_V1_0, so it is a constant rather than a signal), the Logon Account whose credentials were checked, the Source Workstation the request claims to have come from, and the Error Code. Success events carry 0x0. Anything else is a failure and the hex value tells you why.

A few generation rules from Microsoft's own documentation shape how you read volume. The event also fires on workstation unlock, because unlocking a session re-validates the cached credential over NTLM. It does not fire when a domain account logs on locally at a domain controller console. And it only covers NTLM: a Kerberos logon leaves no 4776 behind at all, which is why a domain that has moved most traffic to Kerberos still sees a steady trickle of these events from the corners that have not.

Those corners are predictable. Local account logons always use NTLM, since there is no Kerberos realm for a local SAM account. Anything that authenticates by IP address instead of hostname falls back to NTLM because there is no SPN to request a ticket for. Old SMB clients, some network appliances, printers, RADIUS front-ends, and applications that were coded against LogonUser with a plaintext credential all end up here. Every one of those paths produces a 4776 on the authoritative machine, and that inventory of "who still talks NTLM" is itself a finding worth keeping.

Windows records domain authentication on two separate rails. Kerberos authentication is logged on the domain controller as 4768 (a ticket-granting ticket was requested; success or failure with a Kerberos result code) and 4771 (Kerberos pre-authentication failed, which is the Kerberos analogue of a bad password). NTLM authentication is logged as 4776. An account will land on one rail or the other depending on how the client negotiated, never both for the same attempt.

The practical difference is where the useful fields live. 4768 and 4771 carry a Client Address, an IP the DC saw on the wire, plus ticket options and encryption type. 4776 carries only a workstation name that the client supplied in its NTLM AUTHENTICATE message. There is no IP address in 4776. If you need an address for an NTLM attempt, you have to pull it from the 4624 or 4625 on the destination server, where LogonType 3 and AuthenticationPackageName NTLM will match up with the 4776 by account name and timestamp.

That brings up the relationship with 4625. Event 4625 is written by the machine where the logon session was attempted, and it describes the session: logon type, source IP and port, logon process, and a Status/SubStatus pair. Event 4776 is written by the machine that holds the account's password hash, and it describes the credential check. When a user types a wrong domain password into a member server over NTLM, the server writes a 4625 and the domain controller writes a 4776, both for the same failed attempt, each carrying part of the story. When the failing logon is a local account on a workstation, both events land on that same workstation. Neither one is a substitute for the other, and Microsoft explicitly recommends 4624 over 4776 for monitoring local account logons because 4624 has more context.