Tracking Kerberos & NTLM Authentication Failures and Investigation
- Oct 18
- 7 min read
Updated: Oct 20
When investigating intrusion attempts or suspicious login activity in Windows environments, one of the most overlooked sources of truth lies in the authentication failure logs — specifically,
Kerberos Event ID 4771 and NTLM Event ID 4776.
These tiny events, often lost in the noise of massive log volumes, can tell a deep story:
Was someone trying to guess passwords?
Was an attacker using a stolen hash?
Or was it just a misconfigured system clock?
Kerberos Pre-Authentication Failures (Event ID 4771)
Kerberos is the default authentication protocol in modern Windows domains, but when things go wrong, it leaves behind a clear trail. Whenever Kerberos “pre-authentication” fails, Windows logs Event ID 4771 on the authentication server — usually the domain controller. This event contains the date, time, username, client IP address, and most importantly, an error code that tells you why authentication failed.
There are more than 40 possible Kerberos failure codes, but a few valuable for incident responders. Let’s translate the most common ones into plain language:
Error Code | Meaning | What It Often Means in Real Life |
0x6 | Invalid or non-existent account | Someone tried logging in with an account that doesn’t exist — could be enumeration or stale credentials |
0x7 | Requested server not found | Usually a replication issue, but sometimes points to attempts to reach decommissioned hosts |
Policy restriction | Account tried to log in outside allowed hours or from a restricted device | |
0x12 | Account locked, disabled, or expired | May indicate brute-force or password-guessing attacks |
0x17 | Password expired | User simply needs a reset — or an attacker tried with an old credential dump |
0x18 | Invalid password | The classic — could be typos or password spraying |
0x25 | Clock skew too large | Indicates a mismatch in system time; Kerberos rejects tickets when clocks differ too much |
If you see a cluster of 0x18 errors across multiple accounts from a single source IP, it’s not a coincidence — it’s likely someone is testing passwords or performing a brute-force or password spray attack.
NTLM Authentication Failures (Event ID 4776)
Although Kerberos is dominant, NTLM hasn’t disappeared — it still pops up in remote logins, local account authentications, and pass-the-hash attacks. When NTLM authentication fails, you’ll find Event ID 4776 logged on the system where the authentication was attempted.
This event is a goldmine because it records both the username and the reason why
authentication was denied, using NTSTATUS-style error codes.
Here are some of the most useful ones for IR:
Error Code | Meaning | IR Insight |
0xC0000064 | Account doesn’t exist | Enumeration attempt — attacker probing usernames |
0xC000006A | Wrong password, username valid | Password guessing — if repeated from one host, suspect brute-force |
0xC000006F | Account not allowed to log in now | Account policy restriction triggered |
0xC0000070 | Not allowed from this computer | Attempt to access restricted host — possible lateral movement |
0xC0000071 | Password expired | Legit user or old credential reuse |
0xC0000072 | Account disabled | Attackers sometimes test disabled accounts from old dumps |
0xC0000193 | Account expired | Expired service or user account reused |
0xC0000234 | Account locked | Brute-force or repeated login attempts triggered lockout policy |
Pro Tip: The same error codes also appear in Event ID 4625 (Failed Logon). So cross-referencing 4625 with 4776 helps you see where the login happened and why it failed.
A pattern of multiple 0xC000006A and 0xC0000234 events coming from a single workstation is a clear red flag — it usually means someone (or something) is trying stolen passwords or hashes in bulk.
Tracking Account & Group Enumeration (Event IDs 4798 & 4799)
Once attackers gain a foothold, they rarely move blind. The next step is reconnaissance — mapping out what accounts and groups exist, and more importantly, who the Domain Admins are.
Windows 10 and Server 2016 introduced new logging capabilities to make this easier to detect:
Event ID 4798: A user’s local group membership was enumerated.
Event ID 4799: A security-enabled local group membership was enumerated.
Why These Events Matter for Defenders
Enumeration happens early in the attack lifecycle. That means if you spot 4798 or 4799 events tied to suspicious processes, you’ve caught the attacker before they’ve escalated privileges or exfiltrated data.
---------------------------------------------------------------------------------------------------------
When You Log In with a Local Account (NTLMv2 in Action)
So imagine this — you’re on your workstation and try to access a shared folder on a remote server using a local account (not a domain one).
Maybe you run:
net use S: \\198.30.0.0\Share
Boom — that’s a remote access attempt using NTLMv2.
Here’s what happens behind the scenes:
The client says to the server: “Hey, I want to log in with this username.”
The server replies: “Cool, prove it. Here’s a random challenge.”
The client encrypts that challenge using the hash of your password and sends it back — this is the NTLM Response.
At this point, the server checks if that encrypted response matches what it expects. If it does — you’re in.
Now, from a forensic point of view — here’s what we care about 👇
Event ID | Location | Meaning |
4776 | On the server | NTLM authentication attempt |
4624 | On the server | Authorization success — user logged in |
(Type 3 or 10) | Type 3 = network login, Type 10 = RDP |
So if you’re investigating a lateral movement, and you see 4624 (Type 3) on a file server using a local account, that’s a huge red flag — someone might be using local creds to hop around.
2. When You Log In with a Domain Account (NTLMv2)
Now, let’s change the scene — you’re using a domain account to connect to that same file share.
Here’s where the Domain Controller (DC) jumps in — because that’s where your account actually lives.
The client still sends an authentication request to the server.
The server says, “Wait, I don’t store your password hash — let me ask the DC.”
The server forwards that challenge/response to the domain controller.
The DC checks if your response is correct (using the NT hash in the NTDS.dit).
The DC says “All good,” and the server logs you in.
From a log perspective:
Event ID | Where it appears | What it means |
4776 | Domain Controller | Authentication check (NTLMv2 validation) |
4624 (Type 3) | Server | Authorization success — you got in via SMB |
4624 (Type 10) | Server | Authorization success — you got in via RDP |
Tip: If you ever see net use \IPaddress\share — that’s likely NTLMv2, not Kerberos. Kerberos needs proper Service Principal Names (SPNs), and those don’t work well with raw IPs unless someone configured it manually (which 99% of orgs don’t).
3. Kerberos — The Smart Guy in the Room
Kerberos is the default in modern domains, and it’s way more efficient (and secure) than NTLM. But it’s also a bit more talkative in logs.
Let’s picture when someone logs in locally with a domain account.
Step 1: The Ticket-Granting Ticket (TGT) — “Let me in the club!”
The client asks the Domain Controller (DC) for a TGT.
The DC logs: 4768 — AS Request / Reply (If it fails, you might see 4771 — Pre-authentication failed)
Step 2: The Service Ticket — “Now let me access this service.”
Once you have your TGT, the client says to the DC:
“Hey, I want to access this specific machine/service.”
The DC responds with a TGS (Ticket Granting Service) Ticket — and logs:4769 — TGS Request / Reply
Now the client can use that service ticket to log in locally or remotely.
Step 3: Local Authorization
The client logs:4624 (Type 2) → interactive logon (user at keyboard)
The DC also logs:4624 (Type 3) → network logon when the ticket is presented back to it.
By the end of this process, you’ll see a flurry of 4768, 4769, and 4624 events across both client and DC.
Bonus tip: If you’re ever analyzing logs and see multiple 4769 tied to krbtgt or service accounts, it usually means the client is requesting tickets for various services — like LDAP, CIFS, or even group policy updates.
4. Kerberos in Remote Logons
If the logon happens remotely (like accessing a file share or RDP server):
The client requests a service ticket from the DC — 4769 on the DC.
The client presents that ticket to the server — and the server logs 4624 (Type 3) if it’s successful, or 4625 if it’s denied.
So when investigating:
4769 on the DC tells you who asked for access.
4624 on the server tells you who actually got in.
That’s gold for tracking lateral movement.
-------------------------------------------------------------------------------------------------------------
Putting It All Together
Here’s how you can think of it:
Scenario | Who Logs What | Key Events |
Local Account Logon | Target system | 4776, 4624 |
Domain Account (NTLMv2) | DC (auth), Server (access) | 4776 (DC), 4624 (Server) |
Domain Account (Kerberos) | DC + Client + Server | 4768, 4769, 4624 |
Think of it like this:
Authentication (Who are you?) → DC
Authorization (Can you come in?) → Server or Client
-------------------------------------------------------------------------------------------------------------
5. Why This Matters in Investigations
During lateral movement or credential abuse:
You’ll often see 4624 (Type 3) events lighting up on multiple systems.
Pair them with 4768/4769 from the DC to map out exactly how the attacker moved.
Combine IPs, usernames, and timestamps to build your attack path timeline.
And when the logs aren’t centralized — you’ll have to collect from multiple endpoints.
Quick DFIR Tip
If you’re working offline and can’t access a SIEM, start with:
Get-WinEvent -LogName Security | ? {$_.Id -eq 4624 -or $_.Id -eq 4769 -or $_.Id -eq 4776} | Select TimeCreated, Id, Message
And then pivot by username and IP address — you’ll quickly map authentication relationships.
-------------------------------------------------------------------------------------------------------------
Final Thought
Once you understand where each event lives — DC, server, or client — the logs start to tell a story. You can see who authenticated, how, from where, and what access they gained.
The fun part? Attackers leave breadcrumbs across all three — and now you know exactly where to look.
-----------------------------------------------Dean----------------------------------------------
Comments