Windows Security Event IDs 4624 (Successful Logon), 4769 (Kerberos Service Ticket Request), and 4776 (NTLM Authentication) appear in every lateral movement detection guide. They appear in every lateral movement detection guide because they are genuinely relevant — but relying on individual event types without modeling authentication sequences and timing patterns produces detection rules with false positive rates that make the alerts operationally useless in most enterprise environments.
The Volume Problem with Authentication Events
A 500-user enterprise domain controller logs between 50,000 and 200,000 Security events per day, the majority of which are authentication events. Event ID 4624 (Type 3 — Network Logon) fires on every SMB authentication, every file share access, every web application authentication that uses Windows Integrated Authentication. An analyst triaging a lateral movement alert based solely on 4624 events is looking at a signal that fires tens of thousands of times daily in normal operation.
This volume is why lateral movement detection rules that threshold on individual event counts — "alert if any single account generates more than 50 4624 events in one hour" — produce significant noise for service accounts, backup systems, and software deployment agents that regularly generate authentication events far above that threshold as part of normal operations. The threshold approach conflates high-volume legitimate users with adversarial lateral movement, and the false positive cost is substantial.
The correct analytical frame for lateral movement detection is sequence modeling, not event counting. Adversarial lateral movement has a recognizable pattern: an account that has been quiescent on most systems in the environment suddenly authenticates to multiple new systems within a compressed time window, using network logon types (Type 3) rather than interactive logon types (Type 2), from a source system that is itself not a normal authentication source for those destinations.
Authentication Graph Analysis
The most effective lateral movement detection approach treats authentication events as edges in a directed graph where nodes are accounts and systems. An edge (SourceSystem → DestinationSystem, AccountName) represents an observed authentication. The baseline graph for any enterprise environment, built from 30 days of historical events, captures the normal connectivity pattern: which accounts authenticate to which systems, from which source systems, and during which time windows.
Lateral movement appears as new edges in the authentication graph — authenticated connections between pairs of nodes that have no prior relationship in the baseline window, or authenticated connections via accounts that are not normally used for remote access to the destination system. The distinguishing characteristics are:
New source-to-destination pairs: A workstation that has never previously been observed initiating SMB connections to a domain controller starts doing so. This is not individually alarming — software updates, configuration management tools, and backup agents can create new authentication paths — but it is a first-order filter that reduces the event volume to a manageable subset for further analysis.
Account authentication anomalies: A user account that normally authenticates interactively (Type 2) to one workstation begins generating network logon events (Type 3) to multiple systems. Interactive-to-network transition for a specific account on a specific day is a behavioral anomaly with reasonable specificity for credential theft followed by lateral movement using the stolen credential.
Sequential multi-hop patterns: System A authenticates to System B, and within minutes System B authenticates to System C with a different account. This pattern is consistent with token impersonation or pass-the-hash lateral movement where the attacker pivots through successive systems using credentials harvested from memory on each compromised host.
Kerberos Ticket Analysis: Beyond 4769
Event ID 4769 (Kerberos Service Ticket Request) is logged when a client requests a TGS (Ticket Granting Service) ticket to access a specific service on a specific server. The standard Kerberoasting detection rule looks for 4769 events with encryption type 0x17 (RC4-HMAC) for service accounts with Service Principal Names (SPNs) — because Kerberoasting requests RC4 tickets specifically to crack them offline, and most modern Kerberos implementations use AES encryption by default.
This detection logic is accurate for detecting standard Kerberoasting tooling but has limitations. Organizations that have not fully migrated to AES Kerberos will have legitimate RC4 service ticket requests from legacy clients, producing false positives. More importantly, Kerberoasting at scale — requesting tickets for many service accounts in rapid succession — is more reliably detected by the velocity of 4769 events for a single requesting account than by the encryption type alone.
A detection rule that fires on more than 5 Kerberos service ticket requests for different SPNs within 5 minutes from a single account, combined with an encryption type of 0x17, produces a much higher precision signal than either condition alone. The combination narrows the result to accounts that are both using RC4 encryption and requesting tickets in bulk — a pattern inconsistent with legitimate application behavior.
Pass-the-Hash and NTLM Authentication Patterns
Pass-the-hash (PTH) attacks use the NTLM hash of a credential to authenticate without knowing the plaintext password. Event ID 4776 (NTLM authentication) combined with 4624 Type 3 logon events provides the primary signal, but the key contextual indicator is the source system's credential handling context. PTH authentication from a workstation that does not normally initiate server-to-server NTLM authentication is more suspicious than PTH from a server that regularly performs service-level NTLM authentication.
Additional indicators for PTH: the authenticating account's Security Identifier (SID) appears in an 4624 event on the destination system, but the account has no corresponding interactive logon (4624 Type 2) or Kerberos authentication on the source system in the preceding 24 hours — suggesting the hash was obtained from memory rather than from a legitimate user session.
Enrichment plays a role here: when a lateral movement detection fires on an account, enriching the source system IP against the domain asset registry to determine whether it is a managed workstation, server, or unmanaged device changes the triage priority significantly. A PTH authentication from an unmanaged device or a device in an unusual network segment warrants immediate escalation; the same event from a known administrative workstation used by a domain administrator may be legitimate privileged access.
Practical SIEM Implementation Considerations
Implementing authentication graph analysis in a SIEM requires addressing three practical constraints: baseline computation overhead, event correlation join complexity, and alert noise management during baseline periods.
Baseline computation for a 500-user environment with 100,000+ authentication events per day generates a large graph. Computing baseline edge sets and maintaining rolling 30-day history requires either dedicated SIEM storage capacity or selective baselining focused on high-value systems and privileged accounts. Most SOC teams start by baselining domain controllers, servers, and accounts with administrative privileges, and expand coverage incrementally as storage and query capacity allow.
Event correlation joins in Splunk SPL or Elastic KQL for authentication graph analysis can be computationally expensive. Queries that join 4624 events against 30-day historical baselines on a per-account, per-destination basis can timeout in large environments without careful query optimization. ThreatPulsar's Sigma exports for lateral movement detection include optimized SPL and KQL versions with pre-computed lookup tables that reduce query execution time by approximately 70% compared to naive join-based implementations.
The Role of EDR in Lateral Movement Detection
Windows Security Event-based detection catches network authentication artifacts but misses the process-level context that makes lateral movement disposable. EDR telemetry from endpoint agents provides the complementary process view: which processes initiated the outbound authentication, whether those processes spawned from expected parent processes, and whether credential access tools (lsass.exe memory reads, Mimikatz-pattern process behaviors) preceded the lateral movement event.
The combination of SIEM-based authentication event correlation and EDR-based process behavior analysis produces lateral movement detection with both sequence fidelity (the authentication graph tells you what connected to what) and causal context (the EDR data tells you why the connection was made and what preceded it). As discussed in our article on why manual IOC enrichment fails at scale, this cross-source correlation is where enrichment latency matters most — the value of correlating SIEM and EDR data degrades rapidly if the connection between the two data sources requires manual analyst effort.
Conclusion
Lateral movement detection from Windows Security events requires moving beyond individual event type monitoring to authentication sequence and graph analysis. The event IDs are necessary inputs; they are not sufficient detections. The distinguishing signals — new authentication graph edges, credential type transitions, sequential multi-hop patterns, and Kerberos ticket velocity — require baseline modeling and sequence correlation that cannot be accomplished with simple threshold rules on individual event types.
The investment in building authentication baseline models and sequence correlation logic is justified by the detection improvement: authentication graph-based detection reduces false positive rate for lateral movement alerts from 45-60% (typical for individual event type thresholding) to 8-12% in environments with well-maintained baselines. The remaining false positives are primarily from legitimate privileged access activities that warrant analyst review regardless of their ultimate verdict.