Pass the Hash

Executive Summary

Pass the Hash (PtH) is the reuse of an NTLM password hash to authenticate without recovering the account's plaintext password. An adversary who obtains a reusable hash may authenticate to services that accept NTLM and operate with the victim account's privileges. The activity is most useful for lateral movement but can also blend with legitimate remote administration.

Why Attackers Use It

• A captured hash can be immediately reusable even when the plaintext password is unknown.
• Shared local-administrator credentials can turn one compromised host into access across many systems.
• NTLM remains available in many Windows environments for compatibility.
• Successful authentication often resembles ordinary administration unless identity, endpoint, and network evidence are correlated.

MITRE Description

MITRE classifies Pass the Hash as T1550.002. The technique uses stolen password hashes in place of plaintext credentials. The hash is generally obtained through credential-access activity before being presented during local or remote authentication. Overpass-the-hash is related but uses key material to obtain Kerberos tickets rather than directly relying on an NTLM-authenticated service.

Attack Flow

1. The adversary compromises an account or a host where reusable credential material is present.
2. Credential-access activity retrieves an NTLM hash from memory, the SAM database, or another protected store.
3. The adversary selects a reachable service that accepts NTLM, commonly SMB, WMI, WinRM, or another administrative interface.
4. The hash is supplied to an authentication-capable tool and a remote session or process is created.
5. The adversary repeats the process across hosts, then performs discovery, persistence, collection, or further credential access.

Prerequisites

• A valid NTLM hash for an enabled account.
• Network reachability to an NTLM-capable service.
• Sufficient privileges for the requested remote operation.
• NTLM authentication must not be disabled or fully constrained for the path being used.

Common Tools

• Mimikatz and compatible credential tooling
• Impacket remote-administration utilities
• NetExec or CrackMapExec
• WMI, SMB service-control, and WinRM clients
• Native administrative tools used after authentication

Commands

The following patterns are included for recognition and authorized laboratory validation. Values are intentionally represented as placeholders.

mimikatz "sekurlsa::pth /user:<user> /domain:<domain> /ntlm:<hash> /run:<process>"
impacket-wmiexec -hashes :<ntlm-hash> <domain>/<user>@<host>
netexec smb <host> -u <user> -H <ntlm-hash>

Defenders should alert on the resulting authentication and remote-execution behavior rather than relying only on these command strings.

Network Traffic

• SMB commonly uses TCP 445 and may carry NTLM authentication followed by service or share access.
• WMI and service-control activity may use RPC endpoint mapping on TCP 135 followed by dynamic RPC ports.
• WinRM commonly uses TCP 5985 or 5986.
• Indicators include workstation-to-workstation administration, first-seen source and destination pairs, NTLM where Kerberos is expected, and one account rapidly authenticating to multiple hosts.

Windows Events

Sysmon Events

Detection Opportunities

• Correlate Security 4624 Logon Type 3 using NTLM with 4672 on systems where the account rarely administers hosts.
• Detect one source authenticating to many destinations, or one account moving across many hosts in a short interval.
• Identify NTLM use by privileged accounts where Kerberos is normally expected.
• Join authentication with remote service creation, WMI process creation, administrative-share access, or WinRM activity.
• Treat source-host credential access followed by remote NTLM logons as a high-confidence sequence.

Sigma Rules

This rule is a review-ready starting point and requires environment-specific exclusions for scanners, management servers, and approved administrators.

title: Suspicious Privileged NTLM Network Logon
id: 7e653fa5-6e8a-4d9d-bf3e-ecdb6651b28c
status: experimental
description: Detects a successful NTLM network logon followed by assignment of special privileges when correlated by Logon ID.
logsource:
  product: windows
  service: security
detection:
  selection_logon:
    EventID: 4624
    LogonType: 3
    AuthenticationPackageName: NTLM
  selection_privileged:
    EventID: 4672
  condition: 1 of selection_*
falsepositives:
  - Approved administration using NTLM
  - Vulnerability scanners and legacy management systems
level: medium
tags:
  - attack.lateral-movement
  - attack.t1550.002

Splunk Queries

Correlate by Logon_ID using the field names produced by your Windows add-on:

index=windows sourcetype="WinEventLog:Security" (EventCode=4624 Logon_Type=3 Authentication_Package=NTLM) OR EventCode=4672
| stats values(EventCode) as events values(src_ip) as src_ip values(user) as users min(_time) as firstTime max(_time) as lastTime by host Logon_ID
| where mvfind(events,"4624")>=0 AND mvfind(events,"4672")>=0
| convert ctime(firstTime) ctime(lastTime)

Investigation Workflow

1. Confirm the target account, source address, workstation, destination, logon type, and authentication package from 4624.
2. Correlate the Logon ID with 4672 and process, share, service, WMI, or WinRM activity on the destination.
3. Establish whether the source is an approved management system and whether the account normally administers the destination.
4. Review the source for LSASS access, SAM access, credential-tool execution, suspicious drivers, or dump files before the first remote logon.
5. Enumerate every destination contacted by the same account and source during the suspected window.
6. Inspect destination processes, services, scheduled tasks, shares, and follow-on credential access.
7. Determine whether the hash belongs to a reused local account, service account, or domain account and scope equivalent exposure.

Containment

1. Isolate confirmed source and destination hosts when operationally safe.
2. Disable or restrict the compromised account and terminate active sessions.
3. Rotate the exposed credential; rotate shared local credentials across every affected host.
4. Remove unauthorized services, tasks, processes, and persistence only after evidence collection.
5. Block unnecessary east-west administrative protocols and restrict privileged logon paths.

Mitigation

• Use Windows LAPS or another mechanism that gives local administrator accounts unique, rotated passwords.
• Enable Credential Guard where supported and configure additional LSA protection.
• Remove unnecessary local-administrator rights and prevent privileged accounts from logging on to lower-trust systems.
• Restrict or disable NTLM where compatibility testing permits.
• Segment administrative services and require controlled management hosts.
• Monitor privileged NTLM authentication and reduce shared service-account credentials.

Related Techniques

• T1003.001 — LSASS Memory
• T1003.002 — Security Account Manager
• T1021.002 — SMB/Windows Admin Shares
• T1047 — Windows Management Instrumentation
• T1550.003 — Pass the Ticket