SSOGEN / Free tools / Event ID 4776: Decode an NTLM Credential Validation, Free in Your Browser
Free tool
Event ID 4776: Decode an NTLM Credential Validation, Free in Your Browser
Event ID 4776 means a computer tried to validate an account's credentials using NTLM. Paste the event into this free decoder for the Error Code in plain words and what to check next, in your browser, with nothing uploaded.
Paste an event and read it
Paste the text from Event Viewer, or the XML from its Details tab. To see the output first, select the “NTLM validation failed (4776)” sample, or load any other Acme sample.
From Event Viewer: open the event, then copy the General text, or the XML from the Details tab (XML View). Events 4624, 4625, 4634, 4647, 4648, 4672, 4740, 4768, 4769, 4771 and 4776 are recognized.
Private by design. Decoding happens in this page and nothing is sent anywhere. Event text holds account names, host names and IP addresses: use a copy you are allowed to look at, and remove anything you must not share.
Free, in your browser. No sign-up and no limit. The page makes no network request when you decode, so the event never leaves your computer.
Event text still contains account names and host names, so use a copy you are allowed to view. The decoder needs JavaScript; without it, the tables below give the same code meanings.
What event 4776 records
Event ID 4776 is the Windows Security log entry “The computer attempted to validate the credentials for an account”. Windows writes it every time credentials are checked with NTLM. It records three things:
- Account. The account whose credentials were checked.
- Source. The computer the attempt came from.
- Error Code. A value of 0x0 means the check passed; any other value is a failure, and the code gives the reason.
This free decoder reads a pasted event and translates the code.
What NTLM validation is, and how it differs from Kerberos
NTLM. A family of Windows challenge-response authentication protocols: the client proves it knows the password without sending it.
Who verifies. Per Microsoft (NTLM overview in Windows Server on Microsoft Learn, read 2026-10-09), the server that has to verify the identity sends the check to the domain controller for a domain account.
Local accounts. For a local account, the server checks its own local account database.
Kerberos. The other protocol in a Windows domain, which Microsoft calls the preferred method for Active Directory environments. It uses tickets from the domain controller instead of a challenge sent to the server.
Kerberos events. Kerberos logs different events: 4768 and 4771 for the ticket request, and 4769 for a service ticket. For the full picture, read what Kerberos is.
When 4776 appears. A 4776 appears only when NTLM did the checking. A 4776 for a domain account in a domain that prefers Kerberos means something fell back to NTLM.
Where event 4776 is logged
Per Microsoft (event 4776, read 2026-10-09), the event occurs only on the computer that is authoritative for the credentials:
| Account type | Where 4776 is written |
|---|---|
| Domain account | The domain controller |
| Local account | The local computer that holds the account |
The domain controller is therefore the best single place to see every NTLM attempt by domain accounts, in Microsoft’s words “when NTLM authentication was used”.
Each domain controller logs only the validations it handled, so in a domain with several you may have to check them all.
Three more facts from the same page help when you search:
- Source only. The event shows only the source computer. If a user goes from CLIENT-1 to SERVER-1, it shows CLIENT-1; the destination is not recorded.
- Locked workstation. It is also generated when a user returns to a locked workstation.
- Local logon to a domain controller. It is not generated when a domain account logs on locally to a domain controller.
For local account logons, Microsoft says event 4624 is the better source because it carries more detail.
It also says a local logon always uses NTLM when the account logs on to the device that stores it, so local 4776 events are normal.
The fields in event 4776
| Field | What it holds |
|---|---|
| Authentication Package | The package used for the check. Microsoft says it is always MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 for this event. |
| Logon Account | The account whose credentials were validated. It can be a user name, a computer account such as WIN81$, or a well-known account such as Local Service. |
| Source Workstation | The computer the logon attempt came from. |
| Error Code | 0x0 for success. For a failure, the reason, from the table below. |
The Authentication Package value never changes, so it tells you nothing. Work from Logon Account, Source Workstation and Error Code.
Error Code: what each value means
Microsoft’s table lists the “most common error codes” for this event, and the descriptions below are Microsoft’s.
The last column, what to check, is our own suggestion, not a Microsoft rule.
| Error Code | Microsoft’s description | What to check |
|---|---|---|
| 0x0 | No errors | Nothing: the validation succeeded. |
| 0xC0000064 | The username you typed does not exist. Bad username. | A typo, or a run of different names from one source. |
| 0xC000006A | Account logon with misspelled or bad password. | A mistyped or stale saved password. |
| 0xC000006D | Generic logon failure. Causes include an invalid user name or password, or a LAN Manager Authentication Level mismatch between source and target computers. | Check the password first, then the LAN Manager authentication level on both ends. |
| 0xC000006F | Account logon outside authorized hours. | The account’s logon hours. |
| 0xC0000070 | Account logon from unauthorized workstation. | The account’s permitted workstations. |
| 0xC0000071 | Account logon with expired password. | The user must change the password. |
| 0xC0000072 | Account logon to account disabled by administrator. | Whether the account should be disabled. |
| 0xC0000193 | Account logon with expired account. | Extend or retire the account. |
| 0xC0000224 | Account logon with “Change Password at Next Logon” flagged. | The user must set a new password, and a service or script using the old one will fail until then. |
| 0xC0000234 | Account logon with account locked. | Find what keeps sending the wrong password. |
| 0xC0000371 | The local account store does not contain secret material for the specified account. | A local account problem on the computer that logged the event. |
The decoder knows these codes and a few more.
One you may meet is 0xC000006E, which is not in Microsoft’s table.
Microsoft’s NTSTATUS reference (MS-ERREF, read 2026-10-09) calls it STATUS_ACCOUNT_RESTRICTION: the user name and credentials are valid, but an account restriction, such as a time-of-day limit, blocked the logon.
For a code it does not know, the decoder says so. Microsoft’s own wording is “most common”, so the table is not the full list.
The sample event on Microsoft’s page shows 0xc0000234, a locked account.
Worked example. Select the sample button.
The event names the account maria.lopez, the source workstation WS-FIN-014 and the Error Code 0xC000006A: the account exists, but the password was wrong.
A single event like this is usually a typo or a stale saved password. Before you escalate, count how many arrive and from which workstation.
Why NTLM still shows up
Microsoft’s NTLM overview gives the practical reasons:
- NTLM authentication “must be used” for Windows authentication with systems configured as a member of a workgroup, so a machine outside the domain uses it.
- It is used for local logon on computers that are not domain controllers.
- An application, from Microsoft or another vendor, might still use NTLM even where Kerberos is preferred.
Microsoft also says that to reduce NTLM, you first need to know what your deployed apps need from it, and then configure the environment to use other protocols.
The 4776 events are the symptom; the cause is a client, server or app on that list.
Do not treat each one as an attack. Most come from old software and unmanaged machines.
How to find who is using NTLM
Start with the log you already have, then add auditing.
-
Use 4776 on the domain controllers. Group the events by Logon Account and Source Workstation. Microsoft says this event lets you collect all NTLM authentication attempts in the domain. Start with any source that keeps showing up.
-
Turn on NTLM auditing without blocking. Microsoft’s setting Network security: Restrict NTLM: Audit NTLM authentication in this domain makes a domain controller log NTLM sign-in attempts the way the restriction setting would, “but it doesn’t actually block any traffic”.
The possible values are Disable, Enable for domain accounts to domain servers, Enable for domain accounts, Enable for domain servers and Enable all.
Set on a domain controller, it logs only traffic to that domain controller.
-
Read the NTLM operational log. Audit and block events from these settings go to the operational log under Applications and Services Log\Microsoft\Windows\NTLM on that computer.
Microsoft adds that no security audit event policy shows output from the setting, so the events are not in the Security log.
Watch the size of the operational log during testing.
-
Audit incoming traffic on member servers. For the Restrict NTLM: Incoming NTLM traffic setting, Microsoft says to set the matching audit setting first, then review the operational log to see which client apps use NTLM.
Microsoft’s order is assess first, then restrict.
Its page on the incoming-traffic setting warns that restricting can make “numerous NTLM authentication requests” fail and hurt productivity.
Use the audit results to build an exception list of servers.
Before you change any of this on a live domain, test the plan and read Microsoft’s archived guide “Introducing the Restriction of NTLM Authentication”.
Its NTLM overview names that guide as the place to learn how to analyze and restrict NTLM.
4776 next to 4625 and 4740
One failed sign-in leaves different traces on different computers. The table shows how to read them together, based on what Microsoft’s pages say each event records.
| Event | Written on | What it adds |
|---|---|---|
| 4776 | The computer that is authoritative for the credentials | The NTLM check itself: account, source workstation, error code. No destination. |
| 4625 | The computer where the logon attempt was made | The logon type, a Status and Sub Status, and the source address. See event ID 4625. |
| 4740 | The place where the lockout is recorded | The account locked out and the caller computer that sent the attempts. |
A 4776 with 0xC0000234 on the domain controller means the account was already locked. The 4740 tells you which computer caused the lockout.
The 4776 does not name the server the user was trying to reach. To find it, look for the 4625 on that server.
Its codes (0xC0000064, 0xC000006A, 0xC0000234 and the rest) overlap with those above, so read them the same way.
The event ID 4625 page walks through a full morning of linked events and shows how to copy an event out of the log.
Reading a pattern
No single event proves intent. Microsoft’s monitoring advice for 4776 treats counts as the signal:
- Bad user name. Several events in a short time can point to account enumeration.
- Bad password. Several events can point to brute-force guessing.
- Locked account. A locked account can point to a brute-force attack.
- Odd hours or workstation. A logon outside authorized hours, or from an unauthorized workstation, can point to a compromised account.
Microsoft adds that all of this matters most for highly critical accounts. Those lines are Microsoft’s.
The decoder tells you what one event says, and you supply the count. For a related risk, valid passwords reused from other breaches, read about credential stuffing.
NTLM, Kerberos and web sign-in
Route off NTLM. The usual route for moving apps off NTLM is Kerberos for Windows-integrated sign-in.
Where to read. SSOGEN’s Kerberos authentication page and Kerberos SSO for web applications explain how a browser on a domain-joined computer proves who the user is. The Windows desktop sign-in guide covers setup.
When NTLM appears. SSOGEN’s Windows desktop sign-in uses Kerberos. When a browser offers NTLM instead, the usual cause is a service name that is not registered, is registered on two accounts, or was reached by another host name.
Scope. These are SSOGEN’s own sign-in paths, separate from your Windows event logs.
What is event ID 4776?
Is event ID 4776 a failed logon?
Where do I find event 4776?
What does error code 0xC000006A mean in event 4776?
What does error code 0xC000006E mean in event 4776?
What is the difference between event 4776 and 4625?
How do I stop NTLM events in my domain?
Where to go next
- Free tools. Browse the other free tools.
- Failed logons. Decode one with the event ID 4625 decoder.
- Kerberos. Read about Kerberos.
Sources, all read 2026-10-09: Microsoft Learn on event 4776, Restrict NTLM: Audit NTLM authentication in this domain and Restrict NTLM: Incoming NTLM traffic. Also read 2026-10-09 and cited in the text without links: the NTLM overview and the NTSTATUS values reference (MS-ERREF). Microsoft and Windows are trademarks of their owner; SSOGEN is not affiliated with Microsoft.
When a process supplies its own credentials, the attempt is logged as event ID 4648 before the validation shows up here.