How to Detect Lateral Movement and Pass-the-Hash Attacks in Windows Event Logs
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.
Pass-the-Hash allows attackers to authenticate to Windows systems using an NTLM hash extracted from LSASS memory: no plaintext password required. After dumping credentials with Mimikatz or similar tools, an attacker can move laterally across an entire Windows network without knowing any actual password. The detection is visible in event logs: PtH generates characteristic NTLM authentication events with specific logon types and source patterns that stand out from legitimate network traffic. This guide covers building detection rules that catch lateral movement before attackers reach domain controllers.
Understand How PtH Appears in Event Logs
Pass-the-Hash authentication generates a distinctive event log signature. On the source host (where the attacker initiates the connection), Mimikatz's sekurlsa::pth creates a new process and triggers Event ID 4648 (logon with explicit credentials). On the destination host (the target being accessed laterally), Event ID 4624 appears with Logon Type 3 (Network) and AuthenticationPackageName of NTLM. In Kerberos-enabled domain environments, legitimate network authentications use Kerberos by default: NTLM on Logon Type 3 is already suspicious. The PtH pattern specifically shows: source IP does not match the SubjectUserName's typical workstation, the target is a high-value server (DC, file server, jump host), and the timing follows a credential dump event on the source host. Event ID 4776 on domain controllers records NTLM authentication validation requests: a wave of 4776 events from unusual source IPs indicates an NTLM-based attack campaign.
Build the Core Detection Query
Detect NTLM-based network logons in environments where Kerberos is expected. KQL for Microsoft Sentinel:
SecurityEvent
| where EventID == 4624
| where LogonType == 3
| where AuthenticationPackageName == "NTLM"
| where AccountName !endswith "$" // Exclude machine accounts
| where IpAddress !in ("127.0.0.1", "::1", "-")
| summarize Count=count(), Targets=make_set(Computer), by AccountName, IpAddress, bin(TimeGenerated, 1h)
| where array_length(Targets) > 3 // Same account authenticating to 3+ distinct systems
| order by Count desc
The array_length(Targets) > 3 condition is the lateral movement signal: legitimate users don't authenticate via NTLM to 5 different servers within an hour. Splunk equivalent:
index=wineventlog EventCode=4624 Logon_Type=3 Authentication_Package=NTLM NOT Account_Name="*$"
| stats count as ntlm_count, dc(host) as target_count, values(host) as targets by Account_Name, Source_Network_Address
| where target_count > 3
| sort - ntlm_count
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Detect Explicit Credential Use (Event ID 4648)
Event ID 4648 is generated when a process authenticates using credentials different from the logged-on user: the explicit credential use that PtH and RunAs operations trigger. Detection query for PtH-style 4648 events:
SecurityEvent
| where EventID == 4648
| where TargetServerName !in ("localhost", "127.0.0.1")
| where LogonGuid != "{00000000-0000-0000-0000-000000000000}" // Exclude local
| summarize Count=count(), Targets=make_set(TargetServerName) by SubjectUserName, IpAddress=TargetInfo, bin(TimeGenerated, 30m)
| where Count > 5 or array_length(Targets) > 2
Correlate 4648 events with Mimikatz process creation. Event ID 4688 (Process Creation) with CommandLine containing sekurlsa::pth or sekurlsa::logonpasswords on the source host, followed within 5 minutes by 4624 Type 3 NTLM events on destination hosts, is the highest-fidelity PtH detection. Requires Process Creation audit with command line logging enabled: auditpol /set /subcategory:"Process Creation" /success:enable and HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit\ProcessCreationIncludeCmdLine_Enabled = 1.
Hunt for Lateral Movement Patterns
Beyond PtH specifically, look for these lateral movement patterns in Windows event logs. (1) New admin logons to uncommon systems: Event ID 4624 Type 3 where the target computer has never seen that account authenticate before. Build a baseline of normal logon patterns per account and alert on first-seen authentications to high-value servers. (2) Authentication from impossible geolocations: same user authenticated from two locations within a time window that makes travel impossible. (3) Service installations on remote hosts: Event ID 7045 (new service installed) on a remote host immediately following a network logon from an external IP: PsExec creates a service on the target host. (4) Named pipe authentication: Event ID 4624 Type 3 with LogonProcessName of 'NtLmSsp' and TargetLinkedLogonId of 0 indicates named-pipe lateral movement (e.g., PsExec, Cobalt Strike SMB beaconing). (5) After-hours privileged account network logons: a domain admin account generating Type 3 NTLM logons at 3:00 AM when that user is never active at that time.
Detect Mimikatz Process Creation
Mimikatz is the primary PtH enablement tool. Detection requires Process Creation logging with command-line capture. Enable: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit\ProcessCreationIncludeCmdLine_Enabled = 1 (DWORD). KQL detection for Mimikatz-related process behavior:
SecurityEvent
| where EventID == 4688
| where CommandLine has_any ("sekurlsa", "lsadump", "privilege::debug", "token::elevate", "pth", "pass-the-hash")
| project TimeGenerated, Computer, SubjectUserName, NewProcessName, CommandLine
Also detect Mimikatz via indirect indicators: Event ID 4673 (sensitive privilege use) where PrivilegeName is SeDebugPrivilege requested by a non-system process: Mimikatz requires SeDebugPrivilege to access LSASS memory. Combine: EventID == 4673 and PrivilegeName == "SeDebugPrivilege" and SubjectLogonId != "0x3e7" (0x3e7 is SYSTEM). A non-system process requesting SeDebugPrivilege is highly suspicious and warrants immediate investigation.
Reduce NTLM in Your Environment
Detection is necessary but the long-term fix is eliminating NTLM. Use Group Policy to restrict NTLM: Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Network Security: Restrict NTLM. Set 'Incoming NTLM traffic' to 'Deny all accounts' on domain controllers (forces Kerberos for DC authentication). Set 'NTLM authentication in this domain' to 'Deny all' only after thorough testing: many legacy applications break. Intermediate steps: set to 'Audit all' first to identify NTLM-dependent applications without breaking them. Event ID 8004 on DCs (NTLM authentication blocked) identifies affected applications. Once you block NTLM, PtH attacks become impossible in the domain environment since NTLM hashes are only useful for NTLM authentication. Complement with Credential Guard (virtualization-based security for LSASS) and Protected Users security group membership for privileged accounts: Protected Users forces Kerberos and prevents NTLM auth for group members.
The bottom line
PtH detection centers on Event ID 4624 Logon Type 3 with NTLM authentication in environments where Kerberos is expected, correlated with Event ID 4648 (explicit credential use) and Event ID 4688 with Mimikatz command-line signatures. Alert on a single account authenticating via NTLM to 3 or more distinct systems within an hour. Long-term mitigation: restrict NTLM via Group Policy after auditing dependencies, enable Credential Guard, and add privileged accounts to the Protected Users security group.
Frequently asked questions
What Windows event IDs detect Pass-the-Hash attacks?
Pass-the-Hash detection uses three primary event IDs: Event ID 4624 with Logon Type 3 and AuthenticationPackageName NTLM on the destination host (the target being accessed laterally), Event ID 4648 on the source host (explicit credential use by a process), and Event ID 4688 with command-line logging capturing Mimikatz sekurlsa::pth arguments. On domain controllers, Event ID 4776 captures NTLM validation requests and a spike from unusual source IPs indicates an active NTLM attack campaign.
How do I distinguish legitimate NTLM logons from Pass-the-Hash in event logs?
Legitimate NTLM logons in domain environments are rare because Kerberos handles most authentication. Suspicious PtH indicators include: the same account generating NTLM Type 3 logons to 3 or more distinct systems within one hour, NTLM logons to high-value targets (domain controllers, file servers) from workstation IPs, timing correlation with credential dump events (SeDebugPrivilege requests) on a source host, and NTLM logons during off-hours when the account is normally inactive. Baseline normal NTLM usage per account first to distinguish anomalies.
What is Mimikatz and which specific commands are used for Pass-the-Hash?
Mimikatz is an open-source Windows credential extraction tool written by Benjamin Delpy. The specific command for Pass-the-Hash is `sekurlsa::pth /user:<username> /domain:<domain> /ntlm:<NTLM-hash> /run:cmd.exe` — this opens a new command prompt running in the context of the target user with only their NTLM hash (no password required). Other commonly abused Mimikatz commands: `sekurlsa::logonpasswords` (extracts plaintext credentials and hashes from LSASS memory), `lsadump::dcsync` (DCSync attack to pull password hashes from Active Directory without running on the DC), and `kerberos::golden` (creates Golden Tickets). Mimikatz detection: Event ID 4656 with object name 'lsass.exe' and access mask 0x1010, or EDR process access events showing non-standard processes accessing LSASS.
How does Credential Guard prevent Pass-the-Hash attacks?
Windows Credential Guard moves NTLM hashes and Kerberos tickets into an isolated Virtual Trust Level (VTL1) environment protected by Hyper-V virtualization, inaccessible to the normal Windows OS layer (VTL0). When Credential Guard is active, Mimikatz's sekurlsa::logonpasswords cannot extract hashes from LSASS because the hashes are not stored in the VTL0 memory space that LSASS operates in. Credential Guard requirements: UEFI Secure Boot, Virtualization-Based Security (VBS), 64-bit Windows 10/11 or Server 2016+. Enable via Group Policy: Computer Configuration > Administrative Templates > System > Device Guard > Turn on Virtualization Based Security = Enabled, with Credential Guard configuration = Enabled with UEFI lock. Note: Credential Guard does not protect service account credentials stored in LSA secrets or credentials for accounts that use wdigest authentication.
What network-level controls prevent lateral movement via Pass-the-Hash?
Network-level PtH prevention: (1) Block workstation-to-workstation SMB (TCP 445) — PtH via PsExec requires SMB; if workstations cannot reach each other on port 445, lateral movement via this technique fails. (2) Enforce SMB signing — prevents NTLM relay attacks that leverage stolen hashes. (3) Restrict NTLM authentication: Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Network security: Restrict NTLM: NTLM authentication in this domain = Deny all accounts. (4) Enable Protected Users security group membership for all privileged accounts — Protected Users accounts cannot use NTLM authentication at all (only Kerberos), making their credentials unusable in PtH attacks even if stolen. These controls are additive: each layer raises the attacker's cost independently.
How do you build a baseline of normal NTLM usage in your environment before writing PtH detection rules?
Baselining NTLM usage before deploying detection rules prevents high false positive rates that cause alert fatigue from day one. Enable Windows Event ID 4776 collection on all domain controllers and Event ID 4624 Type 3 collection on member servers, then run the collection passively for 14-21 days without any alerting. Query the results to enumerate the complete set of source-destination-account combinations that generate NTLM Type 3 logons: group by `AuthenticationPackageName == 'NTLM'` and aggregate by AccountName, IpAddress, and Computer (destination). Identify the legitimate NTLM sources: these commonly include older network printers, legacy web applications that do not support Kerberos, backup agents, monitoring tools using WMI with NTLM fallback, and workstations authenticating to file shares via NetBIOS name resolution. Add these source IP and account combinations to a SIEM watchlist or lookup table. When you activate PtH detection rules, exclude watchlist entries from the alert threshold calculation while still logging them. Revisit the watchlist quarterly and after any infrastructure changes: new applications and network changes frequently introduce new legitimate NTLM consumers that would otherwise generate false positive alerts.
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.