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.

This is the rule that decides whether your SIEM sees the event at all. Event 4776 is generated only on the computer that is authoritative for the credentials being validated. For a domain account, that is a domain controller. For a local account, that is the workstation or member server whose SAM database holds the account.

For domain accounts the mechanics run through NTLM pass-through authentication. The member server that received the NTLM handshake cannot verify the response itself, so it forwards the challenge and response to a domain controller over its Netlogon secure channel. The DC does the validation and writes the 4776. The member server writes nothing under this event ID, only its own 4624 or 4625. Any DC that holds a secure channel with that server can answer the request, so a single account's NTLM history is spread across every domain controller in the site, and collection has to cover all of them rather than the PDC emulator alone.

For local accounts the event stays on the box. A local administrator logging into a workstation, or an attacker trying local admin passwords against a file server over SMB, produces 4776 on that workstation or file server. If you only forward domain controller logs, you will see none of that, and local account attacks are exactly where NTLM is guaranteed to be in play.

The destination of the authentication is never recorded. Microsoft's example is precise about this: authenticate from CLIENT-1 to SERVER-1 with a domain account and the DC logs Source Workstation CLIENT-1 with no mention of SERVER-1. The target has to be reconstructed from the destination host's own logon events.

Every failure carries an NTSTATUS value in Error Code. The codes below are the ones Microsoft documents for this event, and they are the same values that appear as SubStatus in 4625, so an analyst who knows one table knows both.

For triage the codes fall into three groups. 0xC000006A and 0xC0000234 are the guessing codes: bad password and, once the threshold is crossed, locked account. Their count and their distribution across accounts is what separates a spray from a typo. 0xC0000064 is the enumeration code: a name that does not exist means someone is testing usernames, and a burst of distinct nonexistent names from one workstation is a wordlist being run. The policy-block codes (0xC000006F, 0xC0000070, 0xC0000072, 0xC0000193) mean the password may well have been right but a control stopped the logon; a disabled or expired account that suddenly produces these from a new source is a stronger signal than any single bad password, because someone has a credential they should not have.

0xC000006D deserves a note of its own. It is generic, and in practice it frequently means an NTLM version mismatch (a client offering LM or NTLMv1 to a target that requires NTLMv2) rather than a wrong password. A cluster of 0xC000006D from one old appliance is a hardening ticket, not an incident.

Source Workstation is the only outward-pointing field in the event, so every hunt built on 4776 groups by it. The value is a NetBIOS-style computer name, which is convenient when it resolves to a known asset and useless when it does not.

Two limits matter. First, the value is supplied by the client inside the NTLM AUTHENTICATE message. The domain controller does not verify it. Attack tooling can send an empty string, a random name, or the name of a legitimate host it wants to hide behind. Empty Source Workstation is also common in legitimate traffic from non-Windows clients (Linux SMB stacks, network devices, some VPN concentrators) that simply do not populate the field. Empty is therefore not malicious by itself, but a workstation name that does not exist in your asset inventory, or one that changes between attempts against the same account, is worth pulling on.

Second, the field is a name, not an address. Resolving it means matching against the destination host's 4624/4625 (which carries the IP), against DHCP leases, or against your EDR's device inventory. Treat it as a lead that needs corroboration, never as attribution on its own.

The benign shapes repeat. Cached credentials on a phone, a mapped drive, or a service after a password rotation produce a slow, regular drip of 0xC000006A for one account from one workstation until someone updates the stored secret. Workstation unlocks produce steady successful 4776s for an account against its own machine. Legacy applications that authenticate by IP produce successful 4776s that look like NTLM downgrade but are simply the application being old. An appliance with the wrong LAN Manager level produces 0xC000006D at fixed intervals forever.

The malicious shapes differ in distribution rather than raw count. Many distinct Logon Account values with 0xC000006A from one Source Workstation inside a short window is a spray. Many 0xC0000064 values from one source is enumeration, often the reconnaissance step before the spray. A single privileged account with repeated 0xC000006A from a workstation that has never authenticated as that account before is targeted guessing. A successful 4776 (0x0) for a tier-0 admin account whose policy says Kerberos-only, from a workstation outside the admin tier, is either a policy gap or credential use by someone who only has the hash; both need a look. And a failure code that says disabled or expired, arriving from a fresh source, means the attacker had a real password and simply arrived too late.

One more pattern worth calling out is 4776 on a member server or workstation where the Logon Account is a local account and Source Workstation is not that same machine. Microsoft's guidance flags exactly this: a local account that should only be used locally, being validated from somewhere else, is lateral movement with a local admin credential until proven otherwise.

A mid-shift alert fires from a correlation rule: 47 distinct accounts, one Source Workstation named FS-SCAN02, all 0xC000006A, inside eleven minutes, on two of the site's three domain controllers. The analyst pulls the raw events and notes that the account list is alphabetical, that each account got exactly one attempt, and that three of the 47 returned 0xC0000234 instead of 0xC000006A, meaning they were already locked from a previous round.

FS-SCAN02 exists in the asset inventory as a vulnerability scanner appliance. That is a plausible benign source: scanners do authenticate to many hosts. But the scanner's authenticated scans use a dedicated service account, not 47 user accounts, and the scan schedule shows nothing running. The analyst pivots to the destination side and searches 4625 across member servers for the same eleven minutes with AuthenticationPackageName NTLM. The events show up on a single file server, LogonType 3, with an IpAddress that does not belong to FS-SCAN02's known interface. The workstation name was spoofed.

That flips the verdict. The IP belongs to a contractor VLAN. EDR shows an interactive session on that host running a Python process with the SMB library loaded. The case moves to containment with the hostname, the IP, the account list, and the 4776 timestamps as the evidence chain. The three already-locked accounts get a 4740 check to confirm the earlier round, and the correlation rule that caught it gets a note: the Source Workstation field named a real asset and was still wrong.