Lateral Movement Detection: Windows Event IDs, KQL Queries, and MITRE ATT&CK Coverage
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Lateral movement is the phase of an attack where everything that was gained through initial access gets leveraged into domain-wide compromise. An attacker who lands on a single workstation has very little. An attacker who can move from that workstation to a domain controller has everything. The gap between those two states is determined almost entirely by whether your detection program catches the movement techniques before the attacker reaches their target. This guide covers the six most common lateral movement techniques, the exact Windows Event IDs that fire for each one, and the KQL queries you can deploy in Microsoft Sentinel today.
Enable the Audit Policies Required for Lateral Movement Detection
Before any lateral movement detection is possible, the right event logs must be flowing. Many default Windows audit configurations do not log the events that expose attacker activity. Enable via Group Policy (Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy): Audit Logon Events (Success + Failure), Audit Account Logon Events (Success + Failure), Audit Process Creation (Success), Audit Detailed File Share (Success), Audit Kerberos Service Ticket Operations (Success + Failure), Audit Kerberos Authentication Service (Success + Failure). Enable command-line logging separately: Computer Configuration > Administrative Templates > System > Audit Process Creation > Include Command Line. Without command-line logging, Event ID 4688 entries for wmiprvse.exe or wmic.exe will not include the arguments that distinguish attacker use from legitimate administration. All events must forward to your SIEM within minutes. Detection latency longer than 15 minutes gives attackers enough time to complete lateral movement and establish persistence before any alert triggers.
Audit Logon Events (4624, 4625, 4634, 4648)
Captures all authentication success and failure events including the logon type (2=interactive, 3=network, 10=RDP) that distinguishes lateral movement from local activity.
Audit Kerberos Service Ticket Operations (4769, 4770, 4771)
Required for detecting Kerberoasting (RC4 downgrade in TGS requests) and Pass-the-Ticket attacks. Without this, Kerberos-based lateral movement is invisible.
Audit Process Creation with Command Line (4688)
Captures process launches with full argument strings. Required for detecting WMI lateral movement (wmiprvse.exe spawning attacker commands) and PsExec-style tooling.
Audit Detailed File Share (5140, 5145)
Captures SMB share access events. Required for detecting lateral movement via file share traversal and for confirming PsExec execution paths.
System Event Log: Service Control Manager (7045, 7036)
Captures new service installations. PsExec and many lateral movement tools install a temporary service on the destination system. Event 7045 is the most reliable PsExec indicator.
RDP Lateral Movement: Event IDs and Detection
Remote Desktop Protocol (RDP) is the most visible lateral movement vector because it generates distinct logon type markers that differentiate it from all other authentication events. Event ID 4624 with Logon Type 10 (RemoteInteractive) fires every time an RDP session is established. Event ID 4648 fires when credentials are supplied explicitly (different from the account that owns the current session). Event ID 1149 in the Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational log records the source IP and username at RDP connection time, before authentication completes. Detection focus: accounts that have never used RDP to a given system, RDP sessions outside of business hours, and lateral chains where the source of an RDP session is itself a workstation (not a jump server). KQL for Sentinel: SecurityEvent | where EventID == 4624 and LogonType == 10 | where WorkstationName !endswith 'JMP' and WorkstationName !endswith 'JUMP' | summarize count() by TargetUserName, WorkstationName, IpAddress, bin(TimeGenerated, 1h) | where count_ >= 3 | order by count_ desc.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Pass-the-Hash: Event IDs and Detection
Pass-the-Hash (PtH) allows an attacker with a credential dump (from LSASS, SAM database, or domain controller) to authenticate to remote systems using the NTLM hash directly, without knowing the plaintext password. Tools implementing PtH include Mimikatz sekurlsa::pth, Impacket wmiexec.py and psexec.py, and CrackMapExec. Detection relies on the combination of authentication package and logon type: Event ID 4624 with Logon Type 3 (Network) and AuthenticationPackageName NtLmSsp indicates NTLM network authentication. The key anomaly pattern is NTLM authentication volume: a single NTLM network logon is normal; five or more from the same source within minutes indicates automated lateral movement tooling. Event ID 4776 fires at the domain controller when NTLM credential validation is performed, providing a centralized view of all NTLM authentication requests. KQL for Sentinel: SecurityEvent | where EventID == 4624 and LogonType == 3 and AuthenticationPackageName == 'NTLM' and TargetUserName !endswith '$' | summarize ntlm_logons=count(), dest_systems=dcount(Computer) by TargetUserName, IpAddress, bin(TimeGenerated, 10m) | where ntlm_logons > 5 or dest_systems > 3.
Kerberoasting: Event IDs and Detection
Kerberoasting is a pre-lateral movement credential attack where an attacker requests Kerberos service tickets for accounts with Service Principal Names (SPNs) registered, then cracks them offline. The attack itself does not require any special privileges: any domain user can request service tickets for any SPN. Detection: Event ID 4769 (Kerberos service ticket request) with TicketEncryptionType 0x17 (RC4-HMAC) is the primary indicator. Modern environments should use AES256 (0x12) exclusively; RC4 requests against service accounts are anomalous in well-configured environments. Secondary signal: multiple 4769 events from the same account requesting tickets for diverse service SPNs in a short window indicates enumeration. KQL for Sentinel: SecurityEvent | where EventID == 4769 and TicketEncryptionType == '0x17' and ServiceName !endswith '$' and TargetUserName !endswith '$' | summarize rc4_requests=count(), services=make_set(ServiceName) by TargetUserName, IpAddress, bin(TimeGenerated, 1h) | where rc4_requests > 2 | order by rc4_requests desc. False positive baseline: some legacy applications legitimately use RC4. Identify these before alerting on every 0x17 event.
WMI Lateral Movement: Event IDs and Detection
Windows Management Instrumentation (WMI) is a legitimate administrative interface that attackers abuse for remote command execution because it uses standard Windows communication channels and generates less noise than tools like PsExec. Attackers use wmic.exe from the command line (wmic /node:TARGET process call create 'cmd.exe /c PAYLOAD') or PowerShell Invoke-WmiMethod. On the destination system, the WMI provider host (wmiprvse.exe) executes the command, spawning a child process. Detection: Event ID 4624 with Logon Type 3 from an unusual source, immediately correlated with Event ID 4688 showing wmiprvse.exe as the parent process and an unexpected child process. The parent-child process chain wmiprvse.exe > cmd.exe, wmiprvse.exe > powershell.exe, or wmiprvse.exe > any non-WMI tool is the primary detection signal. KQL for Sentinel: SecurityEvent | where EventID == 4688 and ParentProcessName contains 'wmiprvse.exe' and NewProcessName !contains 'mofcomp' and NewProcessName !contains 'wmiprvse' | project TimeGenerated, Computer, ParentProcessName, NewProcessName, CommandLine, SubjectUserName.
PsExec and Remote Service Execution: Event IDs and Detection
PsExec and similar tools (Sysinternals, Impacket psexec.py) execute commands on remote systems by copying a binary to the target's administrative share (ADMIN$), installing it as a service, executing it, and then removing the service. This sequence leaves a reliable trail across multiple event logs. Event ID 5145 fires when the PSEXESVC binary is written to the ADMIN$ share. Event ID 7045 (Service Control Manager) fires when the PSEXESVC service is installed. Event ID 4624 with Logon Type 3 fires when the authentication to the target occurs. The sequence of these three events within a short window from the same source IP is a high-confidence PsExec indicator. KQL for Sentinel: let psexec_services = SecurityEvent | where EventID == 7045 and ServiceFileName contains 'PSEXE'; let share_writes = SecurityEvent | where EventID == 5145 and ShareName contains 'ADMIN$'; psexec_services | join kind=inner (share_writes) on Computer | summarize by Computer, TimeGenerated, ServiceName. Impacket's psexec.py uses a randomly named binary, but still installs a service; detect by Event 7045 where ServiceFileName contains a temp path (TEMP, Users\Public) combined with Event 4624 Logon Type 3 from the same source.
SMB Lateral Movement and File Share Abuse
SMB (Server Message Block) lateral movement uses Windows file sharing protocols to access systems, transfer tools, or execute payloads via UNC paths. Event ID 5140 fires when a network share is accessed. Event ID 5145 fires when a specific file in a share is accessed. The high-value detection targets are access to administrative shares (ADMIN$, C$, IPC$) from unexpected accounts or workstations, and access to share paths that contain executable extensions from accounts that should not be deploying binaries. Detection pattern: Event 5140 with ShareName ADMIN$ or C$ where the source is a workstation (not a known management server or jump host). KQL for Sentinel: SecurityEvent | where EventID == 5140 and (ShareName endswith 'ADMIN$' or ShareName endswith 'C$') | where SubjectUserName !endswith '$' | join kind=leftouter (SecurityEvent | where EventID == 4624 and LogonType == 3 | project LogonTime=TimeGenerated, Computer, IpAddress) on Computer | where abs(datetime_diff('minute', TimeGenerated, LogonTime)) < 5 | project TimeGenerated, Computer, SubjectUserName, IpAddress, ShareName.
The bottom line
Lateral movement detection is not one rule. It is a set of correlated signals across authentication logs, process events, service installation records, and file share access that collectively expose the attacker's path. The Event IDs above are the starting point. The real capability comes from correlating them: NTLM network logon followed by service install followed by share access from the same source IP within five minutes is a high-confidence attack chain, not three separate low-confidence alerts. Build your Sentinel rules to surface the chain, not the individual events. Start with the two highest-signal indicators, Pass-the-Hash and PsExec, because they generate the fewest false positives and the clearest attacker patterns. Add WMI and Kerberoasting detection after you have established baselines for your environment's legitimate NTLM and Kerberos traffic. Review the full Lateral Movement Mitigation Guide to close the access gaps that make these techniques possible in the first place.
Frequently asked questions
What is lateral movement in cybersecurity?
Lateral movement is the phase of a cyberattack where an adversary with an initial foothold on one system progresses through a network to reach additional systems, higher-value targets, or domain controllers. After gaining initial access (typically through phishing, exploited vulnerabilities, or purchased credentials), attackers use lateral movement to escalate privileges and reach the data or systems required for their objective. MITRE ATT&CK classifies lateral movement as Tactic TA0008 and documents techniques including Remote Desktop Protocol (T1021.001), Pass-the-Hash (T1550.002), Pass-the-Ticket (T1550.003), Windows Management Instrumentation (T1047), and Exploitation of Remote Services (T1210). Detecting lateral movement before attackers reach domain controllers or sensitive data stores is the primary goal of threat detection programs in enterprise environments.
How do you detect lateral movement in Active Directory?
Detecting lateral movement in Active Directory requires monitoring four event categories: (1) Authentication events: Event ID 4624 with Logon Type 3 (network) or Type 10 (remote interactive) from unusual sources; 4648 for explicit credential use; 4769/4771 for Kerberos anomalies including RC4 downgrade attacks. (2) Process creation events: Event ID 4688 with command-line logging enabled, looking for wmiprvse.exe, wmic.exe, or PsExec with remote targets. (3) Service installation events: Event ID 7045 for unexpected service installs, particularly PSEXESVC. (4) Network share events: Event IDs 5140 and 5145 for SMB share access from unexpected accounts or systems. Correlate across these four categories to distinguish attacker lateral movement from legitimate administrative traffic.
What Windows Event IDs indicate lateral movement?
The primary Event IDs for lateral movement detection are: 4624 (successful logon) with Logon Type 3 (Network/NTLM) or Type 10 (RDP) for remote authentication; 4648 (logon with explicit credentials) indicating credential stuffing or pass-the-hash; 4769 (Kerberos service ticket request) with Ticket Encryption Type 0x17 (RC4) indicating Kerberoasting; 4771 (Kerberos pre-auth failure) for brute force or spray; 4776 (NTLM credential validation at DC) for pass-the-hash; 7045 (new service installed) for PsExec or remote service abuse; 5140/5145 (SMB share access) for file share-based movement; 4688 (process creation) with command-line logging for WMI and remote shell activity. For each: you need the corresponding audit policy enabled and logs forwarding to your SIEM.
What is Pass-the-Hash and how do you detect it?
Pass-the-Hash is a lateral movement technique where an attacker uses the NTLM password hash of a compromised account to authenticate to remote systems without knowing the plaintext password. Tools like Mimikatz, Impacket, and CrackMapExec implement this by injecting the hash directly into the authentication process. Detection: look for Event ID 4624 with Logon Type 3 (Network), AuthenticationPackageName of 'NTLM' (not Kerberos), TargetUserName not a machine account, and the source IpAddress being a workstation (not a server). A single occurrence is weak signal; 5+ NTLM network logons from the same source within a few minutes strongly indicates automated lateral movement tooling. Mitigation: enforce Kerberos authentication where possible, disable NTLM v1, enable Protected Users security group for privileged accounts, and deploy Microsoft Defender Credential Guard to prevent credential theft from LSASS.
What is Kerberoasting and how is it different from lateral movement?
Kerberoasting is a credential attack that extracts Kerberos service tickets for offline cracking, rather than a lateral movement technique itself. An attacker with any valid domain account requests service tickets (TGS) for accounts with Service Principal Names (SPNs) registered. These tickets are encrypted with the service account's NTLM hash, allowing offline brute-force without interacting with the target system. If the cracked password belongs to a high-privilege service account, it enables subsequent lateral movement. Detection: Event ID 4769 with Ticket Encryption Type 0x17 (RC4) rather than 0x12 (AES256), requested from a non-service account, for a service with an unusual SPN. Modern Kerberoasting also targets AES-encrypted tickets (0x12) using tools like Rubeus; detection requires anomaly baselines on service ticket request volumes per account.
How do attackers use WMI for lateral movement?
Windows Management Instrumentation (WMI) enables remote command execution through a legitimate Windows administrative interface, making it a preferred lateral movement tool for attackers who want to blend into normal IT traffic. Attackers use wmic.exe or PowerShell Invoke-WmiMethod to execute commands on remote hosts using stolen credentials. The remote system logs Event ID 4624 (Logon Type 3) for the authentication and Event ID 4688 showing wmiprvse.exe spawning the attacker's command. Detection: correlate 4624 with Logon Type 3 from an unusual source, immediately followed by 4688 showing wmiprvse.exe as the parent process and an unexpected child process. False positives are common in environments with legitimate WMI-based management tools (SCCM, monitoring agents). Baseline your legitimate WMI traffic by source account and destination system before deploying this as a high-severity alert.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.