Potential Pass-the-Hash (PtH) Attempt

ELASTIC detection rule by Elastic · Elastic License v2

Adversaries may pass the hash using stolen password hashes to move laterally within an environment, bypassing normal system access controls. Pass the hash (PtH) is a method of authenticating as a user without having access to the user's cleartext password.

[metadata]
creation_date = "2023/03/29"
integration = ["windows", "system"]
maturity = "production"
updated_date = "2026/05/04"

[rule]
author = ["Elastic"]
description = """
Adversaries may pass the hash using stolen password hashes to move laterally within an environment, bypassing normal
system access controls. Pass the hash (PtH) is a method of authenticating as a user without having access to the user's
cleartext password.
"""
from = "now-9m"
index = ["winlogbeat-*", "logs-windows.forwarded*", "logs-system.security*"]
language = "kuery"
license = "Elastic License v2"
name = "Potential Pass-the-Hash (PtH) Attempt"
note = """## Triage and analysis

> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

### Investigating Potential Pass-the-Hash (PtH) Attempt

Pass-the-Hash (PtH) is a technique where attackers use stolen password hashes to authenticate and move laterally across systems without needing plaintext passwords. This method exploits the authentication process in Windows environments. The detection rule identifies suspicious logins using specific logon types and processes, indicating potential PtH activity, by monitoring successful authentications with certain user IDs and logon processes.

### Possible investigation steps

- Review the event logs for the specific user IDs (S-1-5-21-* or S-1-12-1-*) to identify any unusual or unauthorized access patterns, focusing on the time and source of the logon events.
- Examine the winlog.event_data.LogonProcessName field for "seclogo" to determine if this process is commonly used in your environment or if it appears suspicious or unexpected.
- Correlate the successful authentication events with other security logs to identify any lateral movement or access to sensitive systems that occurred after the initial logon.
- Investigate the source IP addresses and hostnames associated with the logon events to determine if they are known and trusted within the network or if they originate from unusual or external locations.
- Check for any recent changes or anomalies in the accounts associated with the suspicious user IDs, such as password resets, privilege escalations, or unusual account activity.
- Consult threat intelligence sources to see if there are any known campaigns or threat actors using similar techniques or targeting similar environments.

### False positive analysis

- Legitimate administrative tools or scripts that use the "NewCredentials" logon type for automation or scheduled tasks can trigger false positives. Review and whitelist known benign processes or scripts that are part of regular operations.
- Security software or monitoring tools that perform regular checks using the "seclogo" logon process may be misidentified. Identify and exclude these tools from the detection rule to prevent unnecessary alerts.
- Service accounts with user IDs matching the specified patterns (S-1-5-21-* or S-1-12-1-*) might be flagged during routine operations. Ensure these accounts are documented and create exceptions for their expected activities.
- Regularly scheduled tasks or maintenance activities that involve authentication processes similar to PtH can cause false positives. Document these activities and adjust the detection rule to account for their occurrence.
- User behavior analytics might incorrectly flag normal user activities as suspicious. Implement user behavior baselining to differentiate between typical and atypical logon patterns, refining the detection criteria accordingly.

### Response and remediation

- Immediately isolate the affected system from the network to prevent further lateral movement by the attacker.
- Revoke any active sessions associated with the compromised user IDs (S-1-5-21-* or S-1-12-1-*) to disrupt the attacker's access.
- Conduct a password reset for the affected accounts and any other accounts that may have been accessed using the compromised hashes.
- Review and update access controls and permissions for the affected accounts to ensure they adhere to the principle of least privilege.
- Deploy endpoint detection and response (EDR) tools to monitor for any further suspicious activity or attempts to use stolen hashes.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach.
- Implement additional logging and monitoring for the "seclogo" logon process to enhance detection of future pass-the-hash attempts."""
references = ["https://attack.mitre.org/techniques/T1550/002/"]
risk_score = 47
rule_id = "daafdf96-e7b1-4f14-b494-27e0d24b11f6"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Lateral Movement",
    "Data Source: Windows Security Event Logs",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
host.os.type:"windows" and
event.category : "authentication" and event.action : "logged-in" and
winlog.logon.type : "NewCredentials" and event.outcome : "success" and
user.id : (S-1-5-21-* or S-1-12-1-*) and winlog.event_data.LogonProcessName : "seclogo"
'''

setup = """## Setup

Audit Logon must be enabled to generate the events used by this rule.
Setup instructions: https://ela.st/audit-logon
"""


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1550"
name = "Use Alternate Authentication Material"
reference = "https://attack.mitre.org/techniques/T1550/"
[[rule.threat.technique.subtechnique]]
id = "T1550.002"
name = "Pass the Hash"
reference = "https://attack.mitre.org/techniques/T1550/002/"



[rule.threat.tactic]
id = "TA0008"
name = "Lateral Movement"
reference = "https://attack.mitre.org/tactics/TA0008/"

[rule.new_terms]
field = "new_terms_fields"
value = ["user.id"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-10d"

[[ currentRule.title && currentRule.title.length > 60 ? currentRule.title.slice(0, 60) + '…' : currentRule.title ]]

59ded3ea-ad76-4339-bb2b-4a33d82db714

Propose edits, view related rules, and engage with the community through comments.

Executable code, not a declarative rule

This submission is arbitrary [[ currentRule.format ? currentRule.format.toUpperCase() : '' ]] code, not a declarative detection rule — review it as you would any script before running it, and note that it cannot be safely aggregated or auto-executed alongside YARA/Sigma/Suricata/CRS rules.

Rejected pattern present

[[ reason ]]

What does this mean?

Format & documentation suggestions

Not a security issue — this rule is valid and was accepted as-is. These are optional fields/conventions its own format recommends, mainly affecting its quality score and how well it documents itself for other reviewers.

[[ reason ]]

What do these messages mean?

[[ currentRule.title && currentRule.title.length > 60 ? currentRule.title.slice(0, 60) + '…' : currentRule.title ]]

[[ currentRule.title ]]

Community Discussion