Detect Pass-the-Hash — NTLM Lateral Movement & Suspicious Network Logons

MITRE ATT&CK

Security Relevance

Pass-the-Hash is the most common form of lateral movement in enterprise intrusions. Once an attacker dumps a single privileged account hash from one host, they can silently authenticate to every host where that account has access — all without triggering a single failed logon. On networks without LAPS, a single local administrator hash often grants access to every Windows workstation. PtH logons are indistinguishable from legitimate NTLM logons without behavioral context, making baseline deviation the primary detection strategy.

Indicators of Malicious Use

• ⚑Event 4624 Type 3 (network logon) with Authentication Package: NTLM — on domain-joined systems, Kerberos is preferred; NTLM suggests IP-based connection or PtH
• ⚑Event 4624 Type 3 NTLM from a workstation (not a server) to another workstation or DC — lateral movement pattern
• ⚑Event 4624 with Workstation Name blank and a raw IP address as the source — common Impacket signature
• ⚑Event 4776 on a domain controller showing NTLM validation for a domain admin account from a non-DC source
• ⚑Event 4648 (explicit credentials) where the credentials used differ from the session account — pass-the-hash often uses 4648
• ⚑Event 4672 immediately following a 4624 Type 3 NTLM logon — elevated privileges granted on network logon suggests admin hash was passed
• ⚑Multiple 4624 Type 3 NTLM events for the same account from different source IPs within a short window — hash sprayed across hosts

Example Log Entry

Log Name: Security
Event ID:  4624
Level:     Information

An account was successfully logged on.

Subject:
  Account Name:     WORKSTATION01$
  Account Domain:   CORP

New Logon:
  Account Name:     Administrator
  Account Domain:   CORP
  Logon Type:       3
  Logon Process:    NtLmSsp
  Authentication Package: NTLM
  Workstation Name: -
  Source Network Address: 10.0.1.45

--- Impacket signature: blank workstation, raw IP source, NTLM on domain ---

Investigation Steps

1. 1.Filter Event 4624 for Logon Type 3 + Authentication Package = NTLM. On a healthy domain, most network logons use Kerberos. A burst of NTLM Type 3 logons from a single source IP is the primary PtH indicator.
2. 2.Check Event 4776 on domain controllers — this fires when the DC validates NTLM credentials. If a privileged account is being NTLM-validated from a workstation rather than a DC, investigate the source host immediately.
3. 3.Look for the Impacket source signature: Event 4624 with Workstation Name blank and Source Network Address as a raw IP (not hostname). Impacket tools connect by IP and do not send a workstation name, creating a distinctive log pattern.
4. 4.Check for hash reuse — search for the same account authenticating via NTLM from multiple source IPs within a short window. A stolen hash is typically sprayed across many hosts using tools like CrackMapExec.
5. 5.Investigate the source host — if the source is a workstation, check what process on that workstation initiated the connection. Event 4688 on the source host around the same timestamp may reveal mimikatz.exe, wmiexec.py, or lateral movement tooling.
6. 6.Check Event 4648 on the source host — PtH via Mimikatz sekurlsa::pth spawns a new process with alternate credentials, which generates a 4648 (explicit credential logon). The credentials in 4648 will differ from the session account.
7. 7.Determine the scope — check every host the suspected hash was used against. CrackMapExec sprays are fast and wide. Pull 4624 Type 3 NTLM events across all DCs and servers for the account to map the full lateral movement path.
8. 8.Contain and rotate — identify how the hash was obtained (LSASS dump, DCSync, network capture), rotate the compromised account's password, and audit for persistence mechanisms created during the lateral movement window.

Common False Positives

• ◎Legacy applications — older software, ERP systems, and some scanners use NTLM by design and cannot be configured to use Kerberos. Baseline known-NTLM applications and their source IPs.
• ◎IP-based connections — Windows always uses NTLM when connecting by IP address rather than hostname (e.g. \\10.0.1.5\share vs \\SERVER\share). NTLM on its own is not an IOC; the account, source, and timing matter.
• ◎Non-domain systems — standalone workstations, Linux hosts using Samba, and DMZ systems often use NTLM for Windows authentication.
• ◎Scheduled tasks and service accounts — some tasks run under domain accounts and authenticate via NTLM if Kerberos tickets are not available at execution time.
• ◎Is NTLM logon always pass-the-hash? No — NTLM is used legitimately in many scenarios. PtH is indicated by NTLM in contexts where Kerberos should be used: domain-to-domain, privileged accounts from unexpected hosts, or a burst of NTLM logons from a single source.

Remediation

• ✓Deploy LAPS (Local Administrator Password Solution) — gives every Windows host a unique, rotating local admin password. Eliminates the most common PtH vector: identical local admin hashes across all workstations.
• ✓Enable Protected Users security group for all privileged accounts — forces Kerberos authentication and prevents NTLM. Accounts in Protected Users cannot be used for PtH.
• ✓Restrict NTLM where possible — Group Policy: Network Security → Restrict NTLM → Deny All Accounts (or restrict to specific servers). Use audit mode first to baseline legitimate NTLM usage.
• ✓Implement network segmentation — prevent workstation-to-workstation lateral movement with host-based firewall rules blocking SMB (445) and WMI (135/dynamic) between workstations.
• ✓Rotate the compromised account password immediately — a new password generates a new NTLM hash, invalidating the stolen one.
• ✓Enable Credential Guard — prevents Mimikatz from extracting hashes from LSASS memory on the source host, cutting off the hash acquisition step.

Related Event IDs

Related Detection Guides

Frequently Asked Questions

Is every NTLM logon a pass-the-hash attack?

No. NTLM is used legitimately in many environments: local account logons, workgroup machines, systems that can't reach a domain controller, and some legacy applications. Pass-the-Hash is specifically indicated by NTLM in contexts where Kerberos should be used — privileged domain accounts authenticating via NTLM to remote systems, especially from unexpected hosts or at unusual hours. Treat NTLM as a signal, not a verdict.

Can pass-the-hash be detected in Windows Security logs without Sysmon?

Yes. Event ID 4624 with Logon Type 3 and Authentication Package NTLM, Event ID 4648 (explicit credential use), and Event ID 4776 (NTLM credential validation on a DC) are all in the standard Windows Security log. Sysmon adds process-level context (which process initiated the connection) but is not required for baseline PtH detection.

What does a blank Workstation Name in Event ID 4624 mean?

A blank Workstation Name field in a Type 3 NTLM logon is a known indicator of Impacket-based tools (wmiexec, psexec, smbexec, secretsdump). Legitimate Windows clients always populate the Workstation Name field. Combined with a raw IP address (not a hostname) in Source Network Address, this is a strong indicator of pass-the-hash via Impacket. It is one of the most reliable Impacket signatures available in native Windows logs.

Does changing a user's password stop a pass-the-hash attack?

Yes — changing the password invalidates the NTLM hash. However, if the attacker has also stolen a Kerberos TGT (pass-the-ticket) or has persistence via another account, changing one password is insufficient. After a PtH compromise, assume all accounts that had active sessions on the compromised host are at risk and rotate them. For local admin accounts, deploy LAPS to ensure unique passwords per machine.