Windows Authentication Attacks — Credential, Kerberos & NTLM Detection Hub

MITRE ATT&CK

Security Relevance

Credential attacks are the single most common attack path in Windows environments — present in virtually every ransomware incident, APT intrusion, and internal threat case. Windows authentication events (the 4600–4800 range) form the most valuable security data source available: they are generated natively, cover both NTLM and Kerberos protocols, and capture both successes and failures. Understanding the relationships between these events — which events the DC generates vs. member servers, NTLM vs. Kerberos, TGT vs. TGS — is the foundation of Windows incident response.

Indicators of Malicious Use

• ⚑Failed logon spike: 20+ Event 4625 events within 5 minutes from a single source IP — automated credential attack threshold.
• ⚑Password spray pattern: 1–2 failures per account across many different accounts from a single IP in 10 minutes — staying below lockout threshold.
• ⚑Pass-the-hash: Event 4624 Type 3 logon using NTLM (Authentication Package = NTLM) to a domain controller for a domain account — Kerberos is expected; NTLM to a DC = hash, not password.
• ⚑Kerberoasting: Event 4769 with Ticket Encryption Type 0x17 (RC4) for multiple service accounts with SPNs from a single source — offline hash cracking setup.
• ⚑Golden Ticket: Event 4769 for a non-existent account name, or Event 4770 renewal with no corresponding 4768 TGT, or ticket lifetime far beyond domain policy.
• ⚑NTLM relay: Event 4776 success where Workstation Name does not match the expected host for that account — relay host is impersonating the victim.
• ⚑Account lockout spike: multiple 4740 events in rapid succession across different accounts — confirms password spray crossed the lockout threshold.

Example Log Entry

# Example: Pass-the-Hash detection chain
# Step 1 — 4776 on DC: NTLM validation for domain admin from unexpected workstation
Event ID: 4776
  Authentication Package: NTLM
  Logon Account:          CORP\Administrator
  Source Workstation:     DESKTOP-ATTACKER    ← not a known admin workstation
  Error Code:             0x0                 ← success

# Step 2 — 4624 on target server: Type 3 network logon using NTLM
Event ID: 4624
  Logon Type:             3 (Network)
  Account Name:           Administrator
  Authentication Package: NTLM               ← domain accounts should use Kerberos
  Source Network Address: 192.168.1.50       ← attacker IP
  Workstation Name:       DESKTOP-ATTACKER

# Example: Kerberoasting — RC4 ticket requests for multiple SPNs
Event ID: 4769
  Account Name:           jsmith@CORP.LOCAL
  Service Name:           MSSQLSvc/sqlserver.corp.local
  Ticket Encryption Type: 0x17               ← RC4, should be 0x12 (AES256)
  Client Address:         192.168.1.50       ← same IP, multiple SPNs = Kerberoasting

Investigation Steps

1. 1.Determine the attack type first using the event pattern: 4625 volume spike = brute force/spray; 4776 NTLM success from unexpected host = pass-the-hash; 4769 RC4 bulk = Kerberoasting; 4768 RC4 from unexpected IP = overpass-the-hash. Each type has a dedicated detection guide — navigate to the specific guide from the Related Detections section below.
2. 2.For any credential attack, check whether it succeeded: find 4624 events from the same source IP within the attack window. Success after failures = the attacker has valid credentials and may already be active.
3. 3.Identify the affected accounts: which accounts saw the most 4625 failures, which 4624 logons followed, and what privileges those accounts hold (correlate with 4672 special privileges assigned).
4. 4.For NTLM attacks (4776, 4625 Type 3): determine if NTLM is expected for these accounts. Domain accounts should use Kerberos; NTLM for a domain account to a DC is always suspicious. Check if NTLM can be blocked or restricted via policy.
5. 5.For Kerberos attacks (4768, 4769, 4771): check the encryption type field — RC4 (0x17) for modern accounts is the primary signal. Cross-reference service account SPNs if Kerberoasting is suspected.
6. 6.Check for lateral movement after a successful credential attack: look for Type 3 logons from the attacker's IP to multiple systems within 10–30 minutes of the 4624 success.

Common False Positives

• ◎Legacy applications using NTLM — older applications that don't support Kerberos generate 4776 events legitimately; maintain a baseline of known NTLM sources.
• ◎Monitoring and RMM tools — some management tools generate bulk authentication events; correlate with known agent workstation names.
• ◎Account lockouts from mobile devices or cached credentials — a user's phone with a stale password can generate 4625 spikes that look like brute force.

Remediation

• ✓Enable multi-factor authentication on all internet-facing authentication endpoints (VPN, OWA, RDP gateway) — eliminates the majority of credential attack success.
• ✓Restrict NTLM usage via Group Policy — block NTLM for domain accounts to domain controllers; force Kerberos for sensitive account authentication.
• ✓Deploy Protected Users security group for privileged accounts — forces AES Kerberos, prevents NTLM, disables cached credentials, and blocks RC4 ticket encryption.
• ✓Enable fine-grained password policies — implement lockout thresholds that trigger lockout for spray (30 failures per day) without locking out real users.
• ✓Monitor 4768 and 4769 for RC4 encryption type — alert when RC4 appears for accounts in Protected Users or for privileged accounts where AES is enforced.

Related Event IDs

Related Detection Guides

Frequently Asked Questions

Where should I start when investigating a potential credential attack?

Start with the event pattern: if you see a spike of 4625 events, go to the Failed Logon Spike guide for brute force vs spray analysis. If you see 4769 events with RC4 encryption for service accounts, go to Kerberos Attacks for Kerberoasting. If you see 4624 Type 3 NTLM logons to a domain controller from unexpected hosts, go to Pass-the-Hash. If you see 4768 with RC4 from an unexpected IP, go to Overpass-the-Hash. The first step in every case is determining whether the attack succeeded: find 4624 success events from the same source IP within the attack window.

What is the difference between NTLM and Kerberos authentication in Windows event logs?

Kerberos is the default domain authentication protocol — it generates 4768 (TGT request on DC), 4769 (service ticket on DC), and 4624 with Authentication Package = Kerberos on member servers. NTLM is the legacy fallback — it generates 4776 on the DC (credential validation) and 4624 with Authentication Package = NTLM on member servers. From a security perspective: Kerberos is more auditable (the DC logs every ticket request), while NTLM is more attack-friendly (pass-the-hash, relay attacks). Seeing NTLM where Kerberos is expected — domain account to a DC, or from a modern workstation — is the primary NTLM attack signal.

How do I tell the difference between a Golden Ticket and a normal Kerberos session?

Three signals distinguish Golden Tickets from legitimate sessions: (1) A 4769 or 4770 event exists with no corresponding 4768 TGT issuance in the same logon session — the TGT was forged, not issued by the KDC. (2) The ticket uses RC4 encryption (0x17) for an account that should be using AES256 in a modern environment. (3) The Account Name in the 4769/4770 does not exist in Active Directory — attackers can forge tickets for non-existent users. Resetting the krbtgt password twice (with a 10-hour gap) invalidates all existing Golden Tickets.