Overview

Pass the Hash (PtH) is a credential-based lateral movement technique where an attacker uses a captured NTLM password hash — rather than the plaintext password — to authenticate to remote systems. Because Windows NTLM authentication accepts the hash directly as proof of identity, an attacker who has dumped hashes from memory or the SAM database can impersonate any user whose hash they possess, including domain administrators, without ever cracking the password.

Every security team needs reliable detection for this technique because it is a cornerstone of nearly every serious Windows intrusion. Once an attacker successfully passes a hash, they can pivot silently across the environment, access file shares, execute remote services, and reach domain controllers — often within minutes of initial compromise. Without visibility into anomalous NTLM authentication patterns, these movements are nearly invisible to defenders relying solely on perimeter controls.

Attacker Perspective

After obtaining initial access and dumping credentials, attackers use stolen NTLM hashes to authenticate laterally across Windows systems without ever needing to know the user’s actual password.

• Mimikatz sekurlsa::pth: The most common method — the attacker runs sekurlsa::pth /user:Administrator /domain:CORP /ntlm:<hash> /run:cmd.exe to spawn a new process (typically cmd.exe or PowerShell) running under the target user’s security context with injected credentials.
• Impacket psexec/wmiexec/smbexec: Attackers use tools like psexec.py CORP/[email protected] -hashes :<NTLM_hash> from a Linux or Windows pivot box to authenticate over SMB or WMI and execute commands remotely without touching LSASS on the target interactively.
• CrackMapExec (CME): Attackers spray a single hash across an entire subnet with crackmapexec smb 192.168.1.0/24 -u Administrator -H <NTLM_hash> to identify all systems where that account is valid, rapidly mapping the attack surface.
• Overpass-the-Hash with Rubeus: Attackers use Rubeus.exe asktgt /user:Administrator /rc4:<NTLM_hash> /ptt to convert an NTLM hash into a Kerberos TGT, enabling Kerberos-based lateral movement that blends with normal authentication traffic.

PtH is attractive to attackers because it requires no password cracking, works silently within legitimate Windows authentication protocols, and can be executed entirely in memory with no files written to disk.

Detection Strategy

Required Telemetry

• Windows Security Event Log — Logon Events (Event ID 4624): Enable via GPO: Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy Configuration → Logon/Logoff → Audit Logon → Success and Failure. This is the primary signal for PtH; you must collect it from every Windows endpoint and server, not just domain controllers.
• Windows Security Event Log — Failed Logon Events (Event ID 4625): Enabled with the same policy as 4624. Required to detect hash-spraying attempts that fail on most targets.
• Windows Security Event Log — Special Privileges Assigned (Event ID 4672): Enable via Audit Special Logon → Success. This fires when a privileged account (e.g., SeDebugPrivilege, SeTcbPrivilege) logs on and should be correlated with 4624 events to flag high-value account usage.
• Windows Security Event Log — Explicit Credential Logon (Event ID 4648): Enable via Audit Logon → Success. Fires when a process authenticates using explicitly supplied credentials (e.g., RunAs or Mimikatz-spawned processes), which is a direct behavioral indicator of PtH tooling.
• Windows Security Event Log — New Logon Session on DC (Event ID 4768/4769/4771): Enable via Audit Kerberos Authentication Service → Success and Failure on domain controllers. Required to detect Overpass-the-Hash (RC4 downgrade in 4769 where Ticket Encryption Type = 0x17).
• Sysmon Event ID 1 (Process Create): Deploy Sysmon with a configuration that captures full command lines and parent process GUIDs. This is critical for seeing Mimikatz invocations and unusual processes spawned under an injected security context. Enable via Sysmon config: <ProcessCreate onmatch="include"></ProcessCreate>.
• Sysmon Event ID 10 (Process Access): Captures LSASS memory access attempts. Configure Sysmon to alert when TargetImage contains lsass.exe and GrantedAccess matches known credential-dumping access masks (e.g., 0x1010, 0x1410). This detects the credential harvesting step that precedes PtH.
• Sysmon Event ID 3 (Network Connection): Captures outbound connections from suspicious processes. Required to correlate a Mimikatz-spawned cmd.exe connecting to a remote host over SMB (port 445).
• Windows Security Event Log — Object Access — File Share (Event ID 5140/5145): Enable via Audit File Share → Success and Failure and Audit Detailed File Share. Captures SMB share access that frequently follows a successful PtH authentication.
• PowerShell Script Block Logging (Event ID 4104): Enable via GPO: HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging → EnableScriptBlockLogging = 1. Required to catch PowerShell-based PtH tools such as Invoke-TheHash.
• Network/Firewall Logs: Collect SMB (port 445), WMI (port 135 + dynamic RPC), and WinRM (port 5985/5986) connection logs from your EDR, network TAP, or firewall. These provide the east-west movement picture that SIEM log ingestion alone may miss.

Key Indicators

• NTLM Network Logon with no interactive session (Event ID 4624): In the Security log, look for LogonType = 3 (Network) combined with AuthenticationPackageName = NTLM and LogonProcessName = NtLmSsp. Legitimate domain-joined systems strongly prefer Kerberos for network logons; NTLM network logons to domain resources are suspicious, especially for privileged accounts.
• Null or blank Workstation Name with NTLM logon (Event ID 4624): Check WorkstationName = - or empty combined with AuthenticationPackageName = NTLM. Tools like Impacket often fail to populate this field correctly, leaving it blank — a reliable low-noise indicator of non-native tooling.
• Privileged account using NTLM network logon (Event IDs 4624 + 4672): Correlate a 4624 with LogonType = 3 and AuthenticationPackageName = NTLM with a nearly simultaneous 4672 for the same SubjectLogonId. Domain admin accounts authenticating via NTLM over the network are high-fidelity indicators of PtH.
• Mimikatz process creation (Sysmon Event ID 1): Alert on Image containing mimikatz.exe or CommandLine matching patterns like sekurlsa::pth, sekurlsa::logonpasswords, or lsadump::sam. Attackers often rename the binary, so also alert on the parent-child relationship where a non-standard process spawns cmd.exe or powershell.exe immediately after LSASS access.
• LSASS memory access from unexpected processes (Sysmon Event ID 10): Alert when TargetImage = C:\Windows\System32\lsass.exe and SourceImage is not in an approved list (e.g., not MsMpEng.exe, svchost.exe, csrss.exe). Access masks 0x1010, 0x1410, 0x143a are specifically associated with credential dumping tools.
• Rubeus or overpass-the-hash Kerberos RC4 downgrade (Event ID 4769): On domain controllers, look for TicketEncryptionType = 0x17 (RC4-HMAC) in service ticket requests from accounts that normally use AES encryption (0x12). A user account suddenly using RC4 for Kerberos service tickets is a strong Overpass-the-Hash indicator.
• CrackMapExec-style NTLM authentication spray pattern: Look for a single source IP or hostname generating Event ID 4624 (LogonType 3, NTLM) or 4625 failures across 5 or more distinct destination hosts within a short window (e.g., 5 minutes). Field to check: IpAddress in the 4624 event; correlate across multiple target hosts’ Security logs.
• Invoke-TheHash or PowerShell-based PtH (Event ID 4104): In PowerShell script block logs, search for strings like Invoke-TheHash, Invoke-WMIExec, Invoke-SMBExec, or -Hash combined with an IP address or hostname parameter.
• Lateral SMB connection immediately after 4648 explicit credential logon (Sysmon Event ID 3 + Event ID 4648): Correlate a 4648 event (explicit credential use) on a host with an outbound Sysmon network connection to port 445 from the process that received the new logon session within a short time window.

Detection Logic

Rule 1: NTLM Network Logon for Privileged Account (High Sensitivity / Broad)
IF EventID = 4624 AND LogonType = 3 AND AuthenticationPackageName = "NTLM" AND TargetUserName IN [domain_admin_group_members] AND NOT IpAddress IN [known_legacy_servers_requiring_ntlm] THEN alert

This rule catches any privileged account authenticating to a Windows host via NTLM over the network — the core behavior of PtH. It will fire on legitimate legacy systems using NTLM; expect moderate volume initially. Build and refine the exclusion list for known-good NTLM sources (legacy printers, old servers) over the first two weeks of deployment.

Rule 2: NTLM Network Logon with Blank Workstation Name (Medium Precision)
IF EventID = 4624 AND LogonType = 3 AND AuthenticationPackageName = "NTLM" AND (WorkstationName = "-" OR WorkstationName = "") AND NOT TargetUserName LIKE "%$" THEN alert

Impacket and similar offensive frameworks often leave the WorkstationName field blank or set to a hyphen, which native Windows clients never do. Excluding machine accounts (those ending in $) reduces noise significantly. Expect low-to-medium alert volume; false positives are primarily non-domain-joined devices and some service accounts.

Rule 3: LSASS Access Followed by NTLM Network Logon from Same Host (High Precision)
IF Sysmon_EventID = 10 AND TargetImage LIKE "%lsass.exe" AND GrantedAccess IN ["0x1010","0x1410","0x143a","0x1438"] THEN within 300 seconds on same host: IF EventID = 4624 AND LogonType = 3 AND AuthenticationPackageName = "NTLM" THEN alert(priority=HIGH)

This rule chains credential dumping behavior (LSASS access) directly to NTLM lateral movement authentication on the same host, dramatically increasing precision. Alert volume should be very low; nearly every alert in this rule represents a true positive or a legitimate security tool (EDR, vulnerability scanner) that should be excluded by process name.

Rule 4: RC4 Kerberos Downgrade (Overpass-the-Hash) (High Precision)
IF EventID = 4769 AND TicketEncryptionType = "0x17" AND AccountName NOT IN [known_legacy_accounts_using_rc4] AND ServiceName != "krbtgt" THEN alert

This catches the Overpass-the-Hash variant where Rubeus or Mimikatz uses an NTLM hash to request a Kerberos ticket with RC4 encryption. Alert volume is very low in environments that have enforced AES. Legitimate RC4 users (old systems, some service accounts) must be baselined and excluded first.

Tuning Guidance

• Legacy systems and applications requiring NTLM: Older printers, NAS devices, and pre-Windows 2008 systems frequently use NTLM for network authentication. Identify these through an initial inventory and exclude their specific IP addresses or hostnames in Rule 1 using a dynamic lookup table or reference list: NOT IpAddress IN [ntlm_legacy_allowlist]. Review and audit this list quarterly.
• Service accounts with NTLM dependencies: Some service accounts (backup agents, monitoring tools, SQL linked servers) authenticate via NTLM to remote systems. Identify these through baselining 4624 events over a 2–4 week period and exclude them specifically: NOT TargetUserName IN [ntlm_service_account_allowlist]. Never create a blanket exclusion for all service accounts — scope it narrowly.
• Security and vulnerability scanning tools: Tools like Nessus, Qualys, and CrowdStrike Falcon sensor may access LSASS or generate NTLM authentication events during scans. Exclude them by their known process names or source IPs: NOT SourceImage IN ["C:\Program Files\Tenable\Nessus Agent\nessusagent.exe"] or NOT IpAddress IN [scanner_ip_range].
• Domain controllers authenticating on behalf of clients: DCs generate large volumes of 4624 LogonType 3 events as they process network authentication for domain resources. Scope your rules to exclude DC-to-DC authentication or filter out TargetDomainName = NT AUTHORITY logons where appropriate. Focus alerting on member servers and workstations as both sources and targets.
• Workstations that are not domain-joined (BYOD, contractors): Non-domain-joined machines always authenticate via NTLM (they have no Kerberos realm relationship). If your environment has a known population of these, add their IP ranges to a reference list and exclude them from broad NTLM rules while still monitoring them for the more precise rules (Rules 3 and 4).

When the Alert Fires: Investigation Steps

1. Verify the alert is real — confirm the raw event exists. Pull the raw Event ID 4624 or Sysmon event directly from your SIEM using the exact event record ID, host, and timestamp from the alert. Confirm the AuthenticationPackageName, LogonType, and WorkstationName fields match expected PtH patterns before proceeding, to rule out a SIEM parsing error.
2. Identify the affected host and user — flag if privileged. Note the TargetUserName and TargetDomainName from the 4624 event and check if the account is a member of privileged groups (Domain Admins, Enterprise Admins, local Administrators) using Active Directory or your identity provider. If the account is privileged, treat this as high severity immediately and escalate in parallel with the rest of the investigation.
3. Pull the full command-line and parent process chain on the source host. On the host where the NTLM authentication originated (IpAddress field in the 4624 event on the target, or the host generating the 4648 event), query Sysmon Event ID 1 logs for the process that initiated the connection. Walk the parent process chain using ParentProcessGuid to determine if the authenticating process was spawned by a known attacker tool pattern (e.g., lsass.exe → cmd.exe or an unexpected parent).
4. Check for LSASS access on the source host preceding the logon event. Query Sysmon Event ID 10 on the source host for any LSASS access events in the 10–30 minutes before the suspicious logon. Look for GrantedAccess values associated with credential dumping (0x1010, 0x1410); if found, the hash was almost certainly dumped locally before being used, confirming the PtH chain.
5. Check for network connections and files written to disk from the source host. Query Sysmon Event ID 3 on the source host for outbound connections to port 445, 135, 5985, or 5986 from the suspicious process. Also check Sysmon Event ID 11 (File Create) for any tools, scripts, or payloads dropped to disk around the same timeframe, particularly in C:\Windows\Temp\, C:\ProgramData\, or user profile directories.
6. Look for lateral movement from the source and target hosts. Using the target host identified in the alert, query its Security logs for subsequent outbound 4624 (LogonType 3, NTLM) events originating from it — the attacker may be pivoting further. Also query your EDR or network logs for SMB, WMI, or WinRM connections emanating from the originally compromised host and the target host to identify the full blast radius.
7. Search for persistence mechanisms added on affected hosts. Query Sysmon Event ID 13 (Registry Value Set) for modifications to autorun keys (HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run), and Event ID 1 for new scheduled tasks (schtasks.exe) or service installations (sc.exe create) on both the source and target hosts. Cross-reference with Security Event ID 4698 (Scheduled Task Created) and 7045 (New Service Installed) to confirm any persistence the attacker may have established during their window of access.

Response Playbook

Containment

• Isolate affected hosts from the network immediately — do not power them off. Use your EDR platform (CrowdStrike Network Containment, Defender for Endpoint Isolate Device, or Carbon Black quarantine) to isolate both the source and target hosts while keeping them powered on so volatile memory (LSASS contents, running processes, network connections) remains available for forensic collection. If no EDR is available, block the host’s MAC address at the switch port level.
• Disable the compromised user account in Active Directory. In Active Directory Users and Computers or via PowerShell (Disable-ADAccount -Identity <username>), immediately disable the account whose hash was used. If the account is a service account, coordinate with the application team first but do not delay more than 15 minutes — attacker dwell time matters more than service disruption at this stage.
• Force-revoke all active sessions for the compromised account. Use Get-PSSession and Remove-PSSession for WinRM sessions, and query domain controllers for active logon sessions using qwinsta /server:<DC> or Invoke-UserHunter (BloodHound suite). Use net session \\<hostname> /delete or Defender for Identity to terminate active authenticated sessions on file servers and other resources.
• Block identified source IPs and any observed C2 infrastructure at the perimeter firewall and internal network segmentation points. If Impacket or CrackMapExec traffic was observed from a specific internal IP (attacker pivot point), create a block rule on your internal firewall or NAC to stop east-west movement. Block any external C2 IPs or domains identified during investigation at the perimeter firewall and in your DNS filtering solution (e.g., Umbrella, Zscaler).
• Kill any identified malicious processes on the affected hosts. If the host is still reachable via EDR console, terminate identified malicious processes (Mimikatz, Rubeus, cmd.exe spawned under the injected security context) using your EDR’s remote process kill capability. Document the PID, process name, and parent process before terminating for the forensic record.

Eradication

• Remove all identified persistence mechanisms. Based on investigation findings, delete any malicious scheduled tasks (schtasks /delete /tn "<taskname>" /f), remove rogue registry Run keys, and uninstall any new services created during the intrusion (sc delete <servicename>). Cross-reference Event IDs 4698 and 7045 found during investigation to ensure completeness.
• Search for and delete all dropped tools and payloads. Query your EDR for file creation events (Sysmon Event ID 11) from the intrusion timeframe and delete identified files. Run a hash-based scan across all potentially affected hosts using known Mimikatz, Impacket, CrackMapExec, and Rubeus file hashes from threat intelligence sources (VirusTotal, your TIP). Pay special attention to C:\Windows\Temp\, C:\ProgramData\, and user AppData directories.
• Reset credentials for all affected and potentially exposed accounts. Reset the password for the compromised account and for every account whose hash may have been resident in LSASS on the compromised host (this means all accounts with recent interactive or network logon sessions on that host). Use Get-WinEvent filtering on Event ID 4624 for that host over the past 90 days to build the full list. For domain admin accounts, this is mandatory and urgent.
• Check all lateral movement target hosts for backdoors. For every host the attacker reached (identified in investigation step 6), run a full EDR threat hunt for persistence mechanisms, unusual scheduled tasks, new local accounts (Event ID 4720), and unauthorized services. Do not assume a target host is clean simply because no payload was observed — PtH can enable attacker activity that leaves minimal disk artifacts.
• Rotate all secrets and credentials that may have been exposed. If the attacker had access to a system storing API keys, service account passwords, certificate private keys, or secrets management vaults (e.g., CyberArk, HashiCorp Vault), rotate all those secrets immediately. Check IIS application pool credentials, SQL linked server credentials, and any hardcoded credentials in scripts on the affected systems.

Recovery

• Re-image affected hosts if forensic confidence is not high. If you cannot confirm with certainty that all attacker tooling and persistence has been removed — particularly if the host had a domain admin account authenticated to it — re-image from a known-good baseline rather than attempting manual cleanup. Reconnect only after imaging is complete and the host has been domain-joined fresh with a new machine account.
• Re-enable the affected user account only after confirming no persistence remains. Before re-enabling the account in Active Directory, confirm that all sessions using that account’s hash have been invalidated, the password has been reset, and no persistence mechanism referencing that account exists on any host. Document the approval to re-enable with a timestamp for the incident record.
• Monitor the previously affected hosts and accounts intensively for 72 hours post-remediation. Create a temporary high-sensitivity detection rule in your SIEM scoped specifically to the affected hostnames and usernames, lowering thresholds for all NTLM logon, process creation, and network connection alerts for a 72-hour window. Assign a dedicated analyst to review these alerts during that period.
• Document the full attack timeline and conduct a lessons-learned review. Build a complete timeline from initial credential access through every lateral movement hop, including timestamps, hosts, accounts, and techniques. Use this to brief leadership and to identify gaps in detection coverage (e.g., hosts missing Sysmon, gaps in NTLM audit policy enforcement across the environment).
• Update detection rules with any new IOCs discovered during the investigation. Add newly discovered file hashes, renamed tool names, unique command-line arguments, and attacker infrastructure IPs to your detection rules and threat intelligence platform. If the attacker used a renamed Mimikatz binary or an unusual Impacket variation, update your behavioral detections to catch that specific variant in future incidents.