How to Detect Pass-the-Hash Attacks in Windows Event Logs

Event ID 4624: Successful logon (the primary detection target):

This event fires on the destination machine (the system being authenticated to). For pass-the-hash detection, the fields that matter are:

• LogonType: Must be 3 (Network logon). PtH uses network authentication, not interactive or service logon.
• AuthenticationPackageName: Will be NTLM for PtH. Kerberos authentication uses the Kerberos package. Seeing NTLM on a machine that should only accept Kerberos is a flag.
• WorkstationName: The hostname of the source machine. In a PtH attack, this often does not match where the account is expected to authenticate from.
• SubjectUserName: The account being used. If this is a Domain Admin account authenticating via NTLM Type 3 to a workstation, that is highly suspicious: DA accounts should use Kerberos for domain operations.
• IpAddress: The source IP. Compare against the account's expected source IPs.

Event ID 4625: Failed logon:

Failed PtH attempts appear as Type 3 NTLM failures. High volumes of Type 3 NTLM failures from a single source IP against multiple targets in a short time window indicate an attacker testing harvested hashes.

Event ID 4648: Explicit credential use:

Event 4648 fires when an account provides credentials explicitly (runas, network drive mapping with credentials). Legitimate lateral movement by IT staff using alternate credentials generates 4648. Pass-the-hash does NOT generate 4648: the attacker is not providing credentials, they are injecting a hash. Seeing 4624 Type 3 NTLM without a corresponding 4648 from the source workstation is a stronger PtH indicator.

Before writing detection rules, understand your environment's legitimate NTLM Type 3 traffic:

Legitimate NTLM Type 3 sources:

• Windows Firewall with Advanced Security communicating between workstations
• File server access using older SMBv1 clients (legacy Windows 7/Server 2008)
• Printers and MFPs that use NTLM for authentication to file shares
• Network-attached storage (NAS) devices running older Samba versions
• Applications configured to use NTLM explicitly (older web applications with Windows authentication)
• Local account authentication on non-domain-joined machines

Suspicious NTLM Type 3 patterns (PtH indicators):

• Domain Admin account authenticating via NTLM Type 3 to a workstation (DA accounts should use Kerberos)
• Any high-privilege account appearing in NTLM Type 3 events on machines it does not normally access
• NTLM Type 3 authentications from a single source in rapid succession to multiple different destinations (hash spray pattern)
• NTLM Type 3 from a workstation IP to a server at unusual hours (2 AM lateral movement is different from 9 AM helpdesk access)
• NTLM Type 3 where WorkstationName is blank or contains a generic hostname inconsistent with your naming convention

Splunk SPL: High-privilege NTLM lateral movement:

index=windows EventCode=4624 Logon_Type=3 Authentication_Package=NTLM
| eval account_lower=lower(Account_Name)
| lookup privileged_accounts.csv account_name as account_lower OUTPUTNEW is_privileged
| where is_privileged="true"
| where NOT match(Workstation_Name, "^(DC01|DC02|MGMT)")
| stats count by Account_Name, Workstation_Name, IpAddress, _time
| where count > 0
| sort -_time

This rule alerts when a privileged account (DA, Schema Admin, etc.) uses NTLM Type 3 authentication from a non-domain-controller, non-management-server source. Build privileged_accounts.csv from the Domain Admin audit you ran previously.

Splunk SPL: NTLM hash spray (rapid multi-target authentication):

index=windows EventCode=4624 Logon_Type=3 Authentication_Package=NTLM
| bucket _time span=5m
| stats dc(ComputerName) as unique_targets, values(ComputerName) as targets by Account_Name, IpAddress, _time
| where unique_targets > 5
| table _time, Account_Name, IpAddress, unique_targets, targets

Five or more distinct destination machines from the same account and source IP within a 5-minute window indicates a hash being tested across multiple targets.

Microsoft Sentinel KQL: NTLM Type 3 from privileged accounts:

let privilegedAccounts = dynamic(["Administrator", "svc-sql", "backup-admin"]); // populate from your DA audit
SecurityEvent
| where EventID == 4624
| where LogonType == 3
| where AuthenticationPackageName == "NTLM"
| where Account has_any (privilegedAccounts)
| where WorkstationName !in ("DC01", "DC02", "MGMT-SERVER") // known legitimate sources
| project TimeGenerated, Account, WorkstationName, IpAddress, Computer
| sort by TimeGenerated desc

Run both rules in Report-only or monitor mode for 14 days before enabling alerts. The most common false positive sources:

Service accounts with NTLM-dependent applications: Some backup agents, monitoring tools, and legacy LOB applications authenticate via NTLM Type 3 from a fixed source IP. Identify these by their consistency: same source, same destination, same time pattern, every day. Exclude by source IP AND destination combination.

Printer and MFP scan-to-folder: These devices authenticate via NTLM to file shares. The source IP is the device IP; the destination is the file server. Exclude by device IP range if these are managed assets.

IT staff using runas or alternate credentials legitimately: These generate 4648 before 4624. Create a correlation exclusion: if 4648 appears from the same source within 30 seconds of the 4624, it is likely legitimate alternate credential use rather than PtH.

After tuning: The remaining NTLM Type 3 alerts for privileged accounts should be near-zero in normal operations. Any alert that fires after tuning represents either a genuine PtH attempt or a new legitimate application that needs documentation and exclusion.