Windows Event ID 4776 — NTLM Credential Validation

MITRE ATT&CK

Why It Matters

Pass-the-hash exploits the NTLM protocol's design: an attacker who has captured an NTLM hash can authenticate as that account without knowing the plaintext password. The DC validates the NTLM hash directly — and 4776 records this validation. A successful 4776 for a privileged account from an unexpected workstation, with no preceding user interaction, is a strong pass-the-hash indicator. NTLM relay attacks (where an attacker forwards NTLM authentication from one system to another) also generate 4776 events on the DC, often with the Workstation field pointing to an unexpected relay host.

Key Fields

Investigation Tips

1. 1.Pass-the-hash signal: successful 4776 (Error Code 0x0) for a privileged account (Domain Admin, service account) from a workstation that account doesn't normally access. Cross-reference the Workstation field against the account's known logon history in 4624 events — an unfamiliar workstation is the key indicator.
2. 2.NTLM to a DC is abnormal: domain accounts authenticating to domain resources should use Kerberos. NTLM to a DC for a domain account means either a legacy application, a misconfiguration, or an attacker using a captured hash. Alert on all successful NTLM authentications to DCs from non-standard sources.
3. 3.NTLM relay: bulk 4776 events from a single Workstation for multiple different Account Names in quick succession, all succeeding — especially if that workstation is not a known admin host. An NTLM relay host forwards captured authentications to the DC, appearing to authenticate as multiple victims.
4. 4.Brute-force: repeated 4776 failures (Error Code 0xC000006A) from the same Workstation targeting the same Account Name. NTLM brute-force on a DC is less common than on endpoints (most NTLM auth routes through the endpoint's 4625) but does occur with tools that target the DC directly.
5. 5.Account enumeration: 4776 failures with Error Code 0xC0000064 (username does not exist) in volume from one Workstation. The attacker is validating which account names are valid before launching credential attacks.
6. 6.Consider enforcing NTLMv2 minimum via GPO (Network security: LAN Manager authentication level) and disabling NTLM on domain controllers entirely where Kerberos is sufficient — this eliminates the entire attack surface for NTLM-based pass-the-hash at the DC level.

Detection Logic

// Successful NTLM validation — filter to privileged account names
SecurityEvent
| where EventID == 4776
| where Status == "0x0"
| where TargetAccount !endswith "$"
| project TimeGenerated, TargetAccount, WorkstationName, Computer
| sort by TimeGenerated desc

// Relay recon: bulk "account doesn't exist" errors from one workstation
SecurityEvent
| where EventID == 4776
| where Status == "0xC0000064"
| summarize Count=count(), Accounts=make_set(TargetAccount)
    by WorkstationName, bin(TimeGenerated, 10m)
| where Count >= 5
| sort by TimeGenerated desc

Related Event IDs

Frequently Asked Questions

Why am I seeing so many Event ID 4776 events on my domain controller?

Event 4776 fires on the DC every time it validates an NTLM credential — which includes every NTLM network logon in the domain. In most environments, even with Kerberos as the default, NTLM is still used for local account authentication, some legacy applications, and workgroup devices. A DC in a mid-size environment can generate thousands of 4776 events per day. The security value is not in the volume but in the Error Code (0xC0000064 = account doesn't exist, 0xC000006A = wrong password, 0x0 = success) and the Workstation Name — NTLM validation for a domain account from an unexpected workstation is the pass-the-hash signal.

Is Event ID 4776 always a sign of pass-the-hash?

No. 4776 fires for all NTLM credential validations, most of which are legitimate: local accounts, legacy applications, workgroup devices, and some system services. Pass-the-hash shows up as a 4776 success (Error Code 0x0) for a privileged domain account from a workstation that does not normally authenticate that account. The key distinguishing fields are: Workstation Name (is this a known machine for this account?) and the account type (domain admins should never NTLM-authenticate from a random workstation). A 4776 success for Administrator from a workstation that has been generating 4625 failures is a near-certain pass-the-hash.

What is the difference between Event ID 4776 and Event ID 4625?

Both can show authentication failures, but from different protocol perspectives and locations. Event 4625 fires on the machine where the logon was attempted — for NTLM, this is the workstation or server being accessed. Event 4776 fires on the domain controller that validated the NTLM credential — it is the DC-side view of the same authentication. For domain accounts, 4776 on the DC paired with 4625 on the member server gives you the complete picture: the member server shows the failed logon, the DC shows the failed credential validation that caused it. For local accounts, 4776 never fires on the DC — NTLM validation for local accounts happens on the local machine itself.

How do I detect NTLM relay attacks using Event ID 4776?

NTLM relay shows up as a 4776 success event on the DC where the Workstation Name is a different machine than the one that actually initiated the connection — the relay host is impersonating the victim. The attacker intercepts an NTLM authentication challenge from machine A, relays it to machine B, and the DC validates it as if machine A authenticated directly. Detection: look for 4776 success events where the Workstation Name does not match the expected source for that account, especially in rapid succession across multiple hosts. Correlate with Sysmon network connections from the relay host. Mitigate by enabling SMB signing and disabling NTLMv1 (which cannot be protected by modern relay defenses).