Microsoft Tools & Hacks

Unmasking Pass-the-Hash: Detecting Lateral Movement with Windows Event Logs

safe_research

Introduction: Unmasking the Ghost in the Machine – Detecting Pass-the-Hash with Windows Event Logs

In the intricate dance of cyber defense, understanding the adversary's playbook is paramount. Among the many techniques attackers wield, "Pass-the-Hash" (PtH) stands out as a particularly insidious method for lateral movement and privilege escalation within Windows environments. Unlike traditional brute-force or password spraying attacks that attempt to guess or crack passwords, PtH leverages already compromised NTLM (NT LAN Manager) or Kerberos hashes directly for authentication, bypassing the need for the plaintext password. This makes it incredibly difficult to detect without a robust understanding of Windows event logs and proactive threat detection strategies.

At SAFE Cyberdefense, our expertise in endpoint protection, threat analysis, and cyber defense strategies constantly brings us face-to-face with sophisticated attacks. Detecting PtH is a critical component of a comprehensive incident response plan, safeguarding your organization against the stealthy spread of an intruder. This article delves deep into the mechanisms of PtH, the crucial role of Windows Event Log analysis, and practical techniques for identifying these covert attacks, providing invaluable insights for cybersecurity professionals, SOC analysts, penetration testers, and IT security administrators.

Understanding Pass-the-Hash: A Digital Skeleton Key

To appreciate the subtlety of PtH, one must first grasp the fundamentals of Windows authentication. When a user logs into a Windows system, their password is not stored in plaintext. Instead, a one-way cryptographic hash of their password is created and stored in the Security Account Manager (SAM) database on local machines or in the Active Directory (AD) database for domain accounts. These hashes are primarily NTLM hashes (and increasingly, Kerberos ticket-granting tickets/TGTs are targeted, although "Pass-the-Ticket" is a distinct but related technique).

When a user attempts to access a network resource, their system presents this hash (or a derived credential) to the authentication server (typically a Domain Controller). The server then performs its own hash calculation using the stored password and compares it. If they match, authentication succeeds.

Pass-the-Hash exploits this mechanism. If an attacker gains access to a system and manages to extract these password hashes from memory (e.g., from the Local Security Authority Subsystem Service - LSASS process) or from the SAM/AD database, they don't need to crack the hash to gain the plaintext password. Instead, they can directly use the hash to authenticate to other systems on the network, effectively "passing" the hash instead of the password.

This technique is highly effective because: * Stealth: No failed login attempts with incorrect passwords are generated, as the hash is valid. * Evasion: It bypasses multi-factor authentication (MFA) mechanisms that rely on knowledge of the plaintext password at the point of initial login (though MFA on the target service itself can still block it). * Lateral Movement: Once an attacker has one valid hash, they can use it to hop to other systems where that user account has permissions, leading to rapid network compromise.

MITRE ATT&CK Reference: PtH is a prime example of a Credential Access technique (T1003 – OS Credential Dumping) leading to Lateral Movement (T1550 – Use Alternate Authentication Material, specifically T1550.002 – Pass the Hash and T1550.003 – Pass the Ticket).

The Critical Role of Windows Event Logs in PtH Detection

Windows Event Logs are the digital breadcrumbs left by every action within a Windows operating system. For robust cybersecurity and incident response, proper configuration and diligent analysis of these logs are indispensable. When it comes to detecting sophisticated techniques like PtH, event logs offer the deepest visibility into authentication attempts, process creations, and system changes that might otherwise go unnoticed.

However, raw event logs can be overwhelming. A typical Windows system can generate thousands of events per hour. Effective PtH detection requires knowing which events to look for, understanding their context, and correlating them across multiple systems. This is where a well-configured SIEM (Security Information and Event Management) system and proactive threat detection capabilities become critical, enabling the aggregation, normalization, and analysis of vast quantities of log data.

Key Event IDs for Pass-the-Hash Detection

Successful detection hinges on understanding the specific event IDs generated during normal and malicious authentication flows. We'll focus on critical events across various log categories: Security, System, and potentially Application logs.

1. Authentication Event IDs

These are the most direct indicators of authentication activity, showing who logged in, from where, and how.

  • Event ID 4624: An account was successfully logged on.

    • Description: This event signifies a successful logon. While ubiquitous, its details are crucial.
    • Key Fields for PtH Detection:
      • Logon Type: This is paramount. PtH typically involves interactive (Type 2), network (Type 3), or service (Type 5) logons.
        • Type 3 (Network) is highly suspicious for interactive logins or unexpected administrative access.
        • Type 2 (Interactive) from a remote system via RDP can be an indicator if associated with a compromised account.
        • Type 5 (Service) could indicate a service being created or started using stolen credentials.
      • Authentication Package: Should be NTLM for PtH.
      • Source Network Address: The IP address of the machine from which the logon originated. Look for unexpected internal IPs or activity from compromised hosts.
      • Process Information (often Logon Process Name and Source Process Name): Can reveal the process responsible for the logon. For Type 3 logons, this might be lsass.exe on the authenticating machine, but the Source Process Name on the target might be WmiPrvSE.exe, psexec.exe, or other administrative tools.
    • PtH Indicator: A Logon Type 3 event using the NTLM authentication package for an account that doesn't typically perform network logons from that source IP, especially if it's an administrative account, is a strong indicator. Also, look for Logon Type 2 RDP sessions initiated from unexpected sources for high-privilege accounts.

  • Event ID 4672: Special privileges assigned to new logon.

    • Description: This event indicates that a new logon was assigned special privileges (e.g., SeBackupPrivilege, SeDebugPrivilege). This often accompanies successful administrative logons.
    • PtH Indicator: Correlate this with Event ID 4624. If a suspicious Logon Type 3 or Type 2 for a high-privilege account is followed by Event ID 4672, it strengthens the suspicion of a successful administrative compromise via PtH.

  • Event ID 4634: An account was logged off.

    • Description: Indicates an account logged off. While not a direct PtH indicator, monitoring logoff events can help establish session durations and identify abrupt or unusual disconnections that might follow a quick compromise and lateral hop.

While PtH primarily targets NTLM hashes, attackers often obtain Kerberos TGTs (Ticket-Granting Tickets) in a similar fashion (Pass-the-Ticket). Monitoring Kerberos activity can provide additional context, especially when an attacker is moving between different authentication types.

  • Event ID 4768: A Kerberos authentication ticket (TGT) was requested.

    • Description: Logs every request for a TGT.
    • Key Fields: Client Address, Service Name (usually krbtgt for TGTs), Account Name.
    • PtH Context: Look for TGT requests from unexpected Client Addresses for high-privilege accounts, especially if they are followed by suspicious Logon Type 3 events.

  • Event ID 4769: A Kerberos service ticket was requested.

    • Description: Logs every request for a service ticket after a TGT has been obtained.
    • Key Fields: Client Address, Service Name (e.g., cifs/server.domain.com), Ticket Options, Account Name.
    • PtH Context: Suspicious Service Ticket requests for administrative services (e.g., RDP, CIFS/SMB, WMI) from unusual sources can indicate lateral movement using Kerberos tickets (Pass-the-Ticket), which often goes hand-in-hand with NTLM hash compromise.

3. Process Creation Event IDs

Attackers using PtH often rely on specific tools or built-in utilities to achieve lateral movement. Monitoring process creation is crucial.

  • Event ID 4688: A new process has been created.
    • Description: This event is generated every time a new process starts. It requires enabling Audit Process Creation and Include command line in process creation events in Group Policy for maximum effectiveness.
    • Key Fields: New Process Name, Creator Process Name, Process Command Line, Target Account Name.
    • PtH Indicator: Look for the creation of processes associated with lateral movement tools or built-in Windows utilities used maliciously, especially when initiated by a compromised account or from an unexpected source.
      • PsExec.exe / psexec.py: A common tool for remote execution. Its presence on a target system, especially with certain command-line arguments, is highly suspicious.
      • WmiPrvSE.exe: WMI (Windows Management Instrumentation) is frequently used for remote execution (T1021.006 - Windows Remote Management). Look for WMI activity originating from compromised hosts targeting other systems. The Creator Process Name can sometimes reveal the calling process.
      • cmd.exe / powershell.exe: Look for interactive or script execution of these shells from remote sources, particularly if they involve base64 encoded commands or suspicious parameters (T1059.001 - PowerShell).
      • svchost.exe: While benign, look for svchost.exe instances associated with newly created services, especially if they are running under stolen credentials.
      • Rundll32.exe: Can be used to execute malicious DLLs.
    • MITRE ATT&CK Reference: T1059.001 (PowerShell), T1021.006 (WMI), T1021.002 (SMB/Windows Admin Shares), T1550.002 (Pass the Hash for lateral movement).

4. Service Creation Event IDs

Attackers sometimes establish persistence by creating new services that run under compromised credentials.

  • Event ID 7045: A service was installed in the system.
    • Description: Logs the creation of a new Windows service.
    • Key Fields: Service Name, Service File Name, Service Type, Service Account.
    • PtH Indicator: Monitor for the creation of new services, particularly those configured to run under a domain account (especially a privileged one) that might have been compromised. Correlation with Event ID 4688 (for the process that created the service) and Event ID 4624 (for the logon of the service account) is crucial.

5. Sysmon Events (Advanced Monitoring)

For organizations with advanced endpoint security, Microsoft Sysmon (System Monitor) provides an unparalleled level of detail, augmenting native Windows Event Logs.

  • Sysmon Event ID 1: Process Creation
    • Description: Similar to 4688 but with more detail, including hashes of executables and parent process information.
    • PtH Indicator: Enhanced 4688 data for tools like PsExec, WMI, or Mimikatz. Look for ParentProcessName that indicates remote execution.
  • Sysmon Event ID 3: Network Connection
    • Description: Logs every network connection, including source/destination IPs, ports, and the process that initiated the connection.
    • PtH Indicator: Identify unexpected outbound connections from systems, especially interactive connections (e.g., SMB/445, RDP/3389, WinRM/5985) originating from processes like wmiprvse.exe, svchost.exe, or powershell.exe to other internal systems, which might indicate lateral movement.
  • Sysmon Event ID 8: CreateRemoteThread
    • Description: Detects when a process creates a remote thread in another process.
    • PtH Indicator: Mimikatz and other credential dumping tools often inject code into lsass.exe to extract hashes. This event can detect such suspicious injections.
  • Sysmon Event ID 10: ProcessAccess
    • Description: Logs when a process attempts to open another process with specific access rights.
    • PtH Indicator: Detects attempts to open lsass.exe with PROCESS_VM_READ or PROCESS_DUP_HANDLE permissions, often a precursor to credential dumping.

Setting Up for Success: Audit Policy Configuration

The effectiveness of Event Log analysis for PtH detection is directly tied to your audit policy configuration. Many critical events are not logged by default.

Key Audit Policies to Enable (via Group Policy):

  1. Audit Credential Validation: Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Account Logon > Audit Credential Validation (Success and Failure). This helps in detecting authentication attempts.
  2. Audit Logon/Logoff: Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Logon/Logoff > Audit Logon (Success and Failure) and Audit Logoff (Success). This will log Event ID 4624, 4634, etc.
  3. Audit Process Creation: Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Detailed Tracking > Audit Process Creation (Success). This logs Event ID 4688.
  4. Include command line in process creation events: Computer Configuration > Administrative Templates > System > Audit Process Creation > Include command line in process creation events (Enabled). This is vital for Event ID 4688 to contain the full command line, which is crucial for distinguishing malicious activity.
  5. Audit Security System Extension: Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > System > Audit Security System Extension (Success).
  6. Audit Other Account Logon Events: Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Account Logon > Audit Kerberos Authentication Service and Audit Kerberos Service Ticket Operations (Success and Failure). Essential for Kerberos-related events.

These settings should be applied via Group Policy Objects (GPOs) to all relevant domain-joined workstations and servers. Remember that enabling extensive auditing generates more logs, necessitating adequate storage and a robust log management solution.

Practical Detection Scenarios and Rules

Let's explore some common PtH scenarios and how to translate event log analysis into actionable detection rules.

Scenario 1: Lateral Movement via PsExec/WMI

An attacker uses a compromised NTLM hash to execute a command remotely on another machine via PsExec or WMI.

Detection Logic: Look for Event ID 4624 (Logon Type 3 - Network) followed shortly by Event ID 4688 indicating suspicious process creation, where the Target Account Name matches the account used in 4624.

Example Sigma Rule (PsExec-like activity):

title: Potential PsExec Lateral Movement with Pass-the-Hash
id: a1b2c3d4-e5f6-7890-1234-567890abcdef
status: experimental
description: Detects lateral movement activity often associated with PsExec or similar tools, especially in a Pass-the-Hash context, by monitoring suspicious service and process creation after a network logon.
author: SAFE Cyberdefense
date: 2023/10/27
modified: 2023/10/27
logsource:
  product: windows
  service: security
detection:
  # Condition 1: Detect a suspicious network logon for an administrative account
  logon_event:
    EventID: 4624
    LogonType: 3
    AuthenticationPackage: "NTLM"
    TargetLogonId: "0x3e7" # Often indicates SYSTEM logon (PsExec creates SYSTEM service)
    # Exclude known benign network logons if they match these criteria
    # e.g., Workstation$: (LogonType: 3 for machine accounts is common)
    # Consider excluding specific source IPs/accounts known to be legitimate admin tools

  # Condition 2: Detect process creation often associated with remote execution tools
  # This can be EventID 4688 for process creation OR EventID 7045 for service creation
  # We look for a service creation as PsExec often drops a service.
  service_creation:
    EventID: 7045
    ServiceName|contains: # Typical PsExec service names
      - 'PSEXESVC'
      - 'RemComSvc'
      - 'wmiesetup' # WMI-based PsExec variants
    ServiceFileName|contains: 
      - '\system32\PSEXEC.exe' # Older PsExec versions
      - '\system32\RemCom.exe' # RemCom variant
      - '\system32\cmd.exe /c' # Generic remote command execution
      - '\system32\powershell.exe -NoP -Exec Bypass' # Generic remote PowerShell

  # Condition 3: Correlation - The process creation or service creation occurs shortly after the logon
  # This requires a SIEM to correlate events by time and potentially by target machine.
  # The time correlation window should be small (e.g., 5-60 seconds).

  # Condition 4: (Optional, for higher fidelity) Look for specific command-line arguments
  # This would be an additional condition for EventID 4688
  process_command_line:
    EventID: 4688
    NewProcessName|endswith: 
      - '\cmd.exe'
      - '\powershell.exe'
    CommandLine|contains: # Common PsExec command line patterns
      - '-c' # Copy file
      - '-s' # Run as System
      - '-d' # Don't wait for process to terminate
      - '-h' # Run with high privileges (often after -s)
      - '-accepteula'
      - 'whoami'
      - 'net localgroup administrators'
      - 'tasklist /svc'

  condition: (logon_event and (service_creation or process_command_line))
falsepositives:
  - Legitimate administrative tools using similar techniques, but should be rare for generic 'PSEXESVC' names.
level: high
tags:
  - attack.lateral_movement
  - attack.t1021.002 # SMB/Windows Admin Shares
  - attack.t1550.002 # Pass the Hash
  - attack.t1059 # Command and Scripting Interpreter

Note: A SIEM solution is essential for correlating Event ID 4624 on the target system with the subsequent Event ID 7045 or 4688 within a short timeframe, specifically checking if the initiating TargetLogonId (or Account Name for 4688/7045) matches the account used in the PtH.

Scenario 2: Remote Desktop (RDP) Login with Stolen Hash

An attacker obtains an NTLM hash and uses a tool like xfreerdp (with /pth option) or Mimikatz's sekurlsa::pth to establish an RDP session.

Detection Logic: Look for Event ID 4624 with Logon Type 10 (RemoteInteractive) where the Authentication Package is NTLM and the Source Network Address is suspicious or originates from an already compromised host. While NTLM for RDP isn't inherently malicious, an RDP session for an administrative account using NTLM and originating from an unusual source is suspect.

Example Sigma Rule (RDP PtH):

title: Potential Pass-the-Hash over RDP
id: f7e8d9c0-b1a2-3456-7890-abcdef123456
status: experimental
description: Detects RDP sessions initiated via Pass-the-Hash by looking for RemoteInteractive (Type 10) logons using NTLM, especially for privileged accounts or from suspicious sources.
author: SAFE Cyberdefense
date: 2023/10/27
modified: 2023/10/27
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4624
    LogonType: 10 # RemoteInteractive
    AuthenticationPackage: 'NTLM'
    # Filter for high-privilege accounts or specific suspicious accounts
    TargetAccountName|endswith: 
      - 'Administrator' 
      - 'svc_admin' # Example service admin account
    # Filter for suspicious source network addresses (e.g., from external IPs without VPN, or known compromised internal IPs)
    # SourceNetworkAddress|startswith: '192.168.10.' # Example: monitor specific subnet
    # SourceNetworkAddress: '10.0.0.100' # Example: known compromised host
  condition: selection
falsepositives:
  - Legitimate RDP access for some service accounts or older systems where NTLM is still used. Requires tuning to your environment.
  - Some legitimate administrative tools that leverage NTLM for RDP.
level: medium
tags:
  - attack.lateral_movement
  - attack.t1021.001 # Remote Desktop Protocol
  - attack.t1550.002 # Pass the Hash

Scenario 3: Service Account Compromise and Persistence

An attacker compromises a service account's hash and uses it to create a new, malicious service for persistence or to access other resources.

Detection Logic: Look for Event ID 7045 (Service Creation) where the Service Account is a domain account (especially a privileged one) and the Service File Name points to a suspicious executable or script location. Correlate this with Event ID 4624 on the source system where the hash might have been dumped, or Event ID 4688 indicating a remote command being used to install the service.

Example Sigma Rule (Suspicious Service Creation by Compromised Account):

title: Suspicious Service Creation by Compromised Account
id: g3h4i5j6-k7l8-9012-3456-7890abcdef12
status: experimental
description: Detects the creation of new services, particularly those running under domain user accounts, which could indicate persistence or lateral movement using stolen credentials.
author: SAFE Cyberdefense
date: 2023/10/27
modified: 2023/10/27
logsource:
  product: windows
  service: system
detection:
  selection:
    EventID: 7045
    ServiceType: '0x10' # User-mode service
    # Look for services running under a domain user account (not LocalSystem, NetworkService, etc.)
    ServiceAccount|contains: '\' # Domain accounts usually contain a backslash
    ServiceAccount|endswith: # Exclude known legitimate service accounts
      - 'NT AUTHORITY\SYSTEM'
      - 'NT AUTHORITY\LOCAL SERVICE'
      - 'NT AUTHORITY\NETWORK SERVICE'
    # Look for suspicious service file names or paths
    ServiceFileName|contains: 
      - 'C:\Windows\Temp\'
      - 'C:\ProgramData\'
      - 'C:\Users\Public\'
      - '.exe'
      - '.dll'
      - '.ps1'
      - 'powershell.exe'
      - 'cmd.exe'
    ServiceFileName|endswith: # Exclude known legitimate system services if they fit patterns
      - 'svchost.exe'
      - 'services.exe'
  condition: selection
falsepositives:
  - Legitimate application installations that create new services under domain accounts. Requires whitelisting or further investigation.
level: high
tags:
  - attack.persistence
  - attack.privilege_escalation
  - attack.t1543.003 # Windows Service
  - attack.t1078 # Valid Accounts

Advanced Detection with SIEM and EDR

While native Windows Event Logs provide the raw data, manually sifting through them across hundreds or thousands of endpoints is impossible. This is where a robust cybersecurity stack becomes indispensable.

  • SIEM (Security Information and Event Management): A SIEM system like Splunk, Elastic SIEM, or Microsoft Sentinel is crucial for aggregating, normalizing, and correlating events from all your endpoints and domain controllers. It enables:

    • Centralized Logging: Collects all relevant logs in one place.
    • Correlation: Automatically links related events across different machines and log sources (e.g., a suspicious logon on Server A followed by process creation on Server B).
    • Alerting: Triggers immediate alerts when detection rules are met.
    • Historical Analysis: Allows forensic investigation over long periods.
    • Behavioral Baselines: Helps identify deviations from normal user and system behavior, which is key for detecting PtH that might mimic legitimate actions.

  • EDR (Endpoint Detection and Response): EDR solutions provide deeper visibility into endpoint activities, including process execution, file system changes, registry modifications, and network connections. Many EDRs have built-in capabilities to detect credential dumping (e.g., Mimikatz) and lateral movement techniques. They can also often collect and enrich Sysmon events.

  • Cyber Defense Strategies & Threat Intelligence: Integrating your log analysis with up-to-date threat intelligence feeds helps in identifying known malicious IP addresses, command-and-control (C2) domains, and attack patterns associated with PtH and other sophisticated threats. SAFE Cyberdefense specializes in developing comprehensive cyber defense strategies that incorporate these advanced tools for proactive threat detection and rapid incident response. For mapping out potential initial access points and understanding your external threat surface, tools like Zondex can provide invaluable insights by discovering exposed services that attackers might target to gain an initial foothold, a common precursor to PtH. Furthermore, robust security posture management including regular vulnerability scanning and security audits with platforms like Secably can help identify and remediate weaknesses that attackers exploit to extract credentials in the first place.

Mitigation Strategies

Beyond detection, robust prevention and mitigation are essential to minimize the risk of PtH attacks:

  1. Enforce Least Privilege: Limit user and service account privileges to the absolute minimum required for their function. This restricts an attacker's lateral movement options even if a hash is compromised.
  2. Regular Patching: Keep operating systems, applications, and firmware fully patched. Many credential dumping vulnerabilities (e.g., in LSASS) are addressed through security updates.
  3. Endpoint Protection: Deploy and maintain a robust EDR and antivirus solution to detect and prevent credential dumping tools like Mimikatz.
  4. Multi-Factor Authentication (MFA): Implement MFA for all privileged accounts and remote access services. While PtH can bypass MFA if it's only enforced at initial login, MFA on target services (e.g., RDP gateway with MFA) can still block it.
  5. Secure Administrative Workstations: Use dedicated, hardened jump boxes or PAWs (Privileged Access Workstations) for administrative tasks. These should have stringent security controls, no internet access, and restrict outbound connections.
  6. Restrict Local Administrator Rights: Avoid granting users local administrator rights on their workstations. This significantly limits an attacker's ability to dump hashes from user machines.
  7. Network Segmentation: Segment your network to restrict lateral movement between different security zones.
  8. Credential Guard: On Windows 10/Server 2016 and later, enable Credential Guard (a Virtualization-based Security feature) to protect LSASS from credential dumping.
  9. Attack Surface Reduction: Regularly audit and reduce your attack surface. Close unnecessary ports, disable unused services, and ensure strong configurations.

Key Takeaways

Detecting Pass-the-Hash techniques requires a layered approach, combining meticulous audit policy configuration with advanced log analysis and correlation capabilities.

  • Enable Comprehensive Auditing: Crucial events like 4624 (Logon), 4688 (Process Creation), and 7045 (Service Creation) must be fully enabled and configured to include command-line details.
  • Focus on Logon Type and Authentication Package: Suspicious Logon Type 3 (Network) or Type 10 (RemoteInteractive) events using NTLM for privileged accounts from unusual sources are prime indicators.
  • Correlate Events: Individual events are often insufficient. A SIEM solution is vital for correlating events across different machines and log categories within a specific timeframe to identify a PtH attack chain.
  • Monitor Process Creation: Look for remote execution tools (PsExec, WMI) and suspicious command-line arguments, especially those initiated by compromised accounts.
  • Leverage Advanced Tools: EDR and Sysmon provide deeper endpoint visibility, detecting credential dumping attempts and granular network activity.
  • Proactive Prevention: Strong mitigation strategies, including least privilege, patching, MFA, and network segmentation, are the first line of defense against PtH.
  • Continuous Improvement: Regularly review and refine your detection rules based on new threat intelligence and adversary techniques.

By diligently analyzing Windows Event Logs and implementing robust cyber defense strategies, organizations can significantly enhance their ability to detect and respond to sophisticated Pass-the-Hash attacks, securing their endpoints and protecting their critical assets from advanced threats.

Defense Microsoft Tools
Related

Related Research