Suspected Lateral Movement from Compromised Host
Detects potential lateral movement or post-compromise activity by correlating alerts where the host.ip of one alert matches the source.ip of a subsequent alert. This behavior may indicate a compromised host being used to authenticate to another system or resource, including cloud services.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2025/12/31"
3maturity = "production"
4updated_date = "2026/02/16"
5
6
7[rule]
8author = ["Elastic"]
9description = """
10Detects potential lateral movement or post-compromise activity by correlating alerts where the host.ip of one alert matches
11the source.ip of a subsequent alert. This behavior may indicate a compromised host being used to authenticate to another system
12or resource, including cloud services.
13"""
14from = "now-30m"
15interval = "29m"
16language = "esql"
17license = "Elastic License v2"
18name = "Suspected Lateral Movement from Compromised Host"
19risk_score = 73
20rule_id = "171a4981-9c1a-4a03-9028-21cff4b27b38"
21setup = """## Setup
22
23This rule requires the `host.ip` field to be populated.
24For **Elastic Defend** events on versions **8.18 and above**, this field is **disabled by default**.
25
26If you are using **Elastic Defend**, ensure host IP collection is enabled by following the configuration steps in the
27[helper guide](https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-data-volume-for-elastic-endpoint#host-fields).
28"""
29severity = "high"
30tags = ["Use Case: Threat Detection", "Rule Type: Higher-Order Rule", "Resources: Investigation Guide"]
31timestamp_override = "event.ingested"
32type = "esql"
33
34query = '''
35from .alerts-security.*
36
37// any alerts excluding deprecated, low severity and threat_match rules
38| where kibana.alert.rule.name is not null and kibana.alert.risk_score > 21 and
39 kibana.alert.rule.type != "threat_match" and
40 not kibana.alert.rule.name like "Deprecated - *" and
41 not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """) and
42 not kibana.alert.rule.name in ("Abnormally Large DNS Response", "Web Application Suspicious Activity: No User Agent")
43
44// alerts with existing source.ip or host.ip
45| eval alert_source_ip = CASE(source.ip is not null, source.ip, null),
46 alert_host_ip = CASE(host.ip is not null and source.ip is null, host.ip, null)
47
48| eval Esql.source_ip = COALESCE(alert_source_ip, alert_host_ip)
49| where Esql.source_ip is not null and Esql.source_ip != "127.0.0.1" and Esql.source_ip != "::1"
50
51| stats Esql.alerts_count = COUNT(*),
52 Esql.event_module_distinct_count = COUNT_DISTINCT(event.module),
53 Esql.host_id_distinct_count = COUNT_DISTINCT(host.id),
54 Esql.rule_name_distinct_count = COUNT_DISTINCT(kibana.alert.rule.name),
55 Esql.event_module_values = VALUES(event.module),
56 Esql.message_values = VALUES(message),
57 Esql.rule_name = VALUES(kibana.alert.rule.name),
58 Esql.event_action_values = VALUES(event.action),
59 Esql.event_category_values = VALUES(event.category),
60 Esql.process_executable_values = VALUES(process.executable),
61 Esql.process_cmdline_values = VALUES(process.command_line),
62 Esql.file_path_values = VALUES(file.path),
63 Esql.host_id_values = VALUES(host.id),
64 Esql.host_ip_values = VALUES(host.ip),
65 Esql.destination_ip_values = VALUES(destination.ip),
66 Esql.user_name_values = VALUES(user.name),
67 SRC_IP = VALUES(source.ip)
68 by Esql.source_ip
69
70// filter for different alerts from multiple hosts and where the host.ip of one alert matches the source.ip of the other alert
71| eval concat_ip_values = MV_CONCAT(TO_STRING(Esql.host_ip_values), ",")
72| eval host_ip_equal_to_source_ip =LOCATE(concat_ip_values, TO_STRING(Esql.source_ip))
73| where Esql.rule_name_distinct_count >= 2 and Esql.host_id_distinct_count >= 2 and host_ip_equal_to_source_ip > 0 and SRC_IP is not null and Esql.alerts_count <= 100
74
75// Move single values to their corresponding ECS fields for alerts exclusion
76| eval source.ip = mv_min(Esql.source_ip),
77 host.id = mv_min(Esql.host_id_values)
78| KEEP Esql.*, source.ip, host.id
79'''
80note = """## Triage and analysis
81
82> **Disclaimer**:
83> 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.
84
85### Investigating Suspected Lateral Movement from Compromised Host
86
87The detection rule uses alert data to determine when multiple alerts from different integrations involving the same user.name are triggered.
88
89### Possible investigation steps
90
91- Review the alert details to identify the specific host involved and the different modules and rules that triggered the alert.
92- Examine the timeline of the alerts to understand the sequence of events and determine if there is a pattern or progression in the tactics used.
93- Correlate the alert data with other logs and telemetry from the host, such as process creation, network connections, and file modifications, to gather additional context.
94- Investigate any known vulnerabilities or misconfigurations on the host that could have been exploited by the adversary.
95- Check for any indicators of compromise (IOCs) associated with the alerts, such as suspicious IP addresses, domains, or file hashes, and search for these across the network.
96- Assess the impact and scope of the potential compromise by determining if other hosts or systems have similar alerts or related activity.
97
98### False positive analysis
99
100- Vulnerability scanners.
101- Jump hosts, NAT gateways and proxies.
102
103### Response and remediation
104
105- Isolate the affected host from the network immediately to prevent further lateral movement by the adversary.
106- Conduct a thorough forensic analysis of the host to identify the specific vulnerabilities exploited and gather evidence of the attack phases involved.
107- Remove any identified malicious software or unauthorized access tools from the host, ensuring all persistence mechanisms are eradicated.
108- Apply security patches and updates to the host to address any exploited vulnerabilities and prevent similar attacks.
109- Restore the host from a known good backup if necessary, ensuring that the backup is free from compromise.
110- Monitor the host and network for any signs of re-infection or further suspicious activity, using enhanced logging and alerting based on the identified attack patterns.
111- Escalate the incident to the appropriate internal or external cybersecurity teams for further investigation and potential legal action if the attack is part of a larger campaign."""
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 Suspected Lateral Movement from Compromised Host
The detection rule uses alert data to determine when multiple alerts from different integrations involving the same user.name are triggered.
Possible investigation steps
- Review the alert details to identify the specific host involved and the different modules and rules that triggered the alert.
- Examine the timeline of the alerts to understand the sequence of events and determine if there is a pattern or progression in the tactics used.
- Correlate the alert data with other logs and telemetry from the host, such as process creation, network connections, and file modifications, to gather additional context.
- Investigate any known vulnerabilities or misconfigurations on the host that could have been exploited by the adversary.
- Check for any indicators of compromise (IOCs) associated with the alerts, such as suspicious IP addresses, domains, or file hashes, and search for these across the network.
- Assess the impact and scope of the potential compromise by determining if other hosts or systems have similar alerts or related activity.
False positive analysis
- Vulnerability scanners.
- Jump hosts, NAT gateways and proxies.
Response and remediation
- Isolate the affected host from the network immediately to prevent further lateral movement by the adversary.
- Conduct a thorough forensic analysis of the host to identify the specific vulnerabilities exploited and gather evidence of the attack phases involved.
- Remove any identified malicious software or unauthorized access tools from the host, ensuring all persistence mechanisms are eradicated.
- Apply security patches and updates to the host to address any exploited vulnerabilities and prevent similar attacks.
- Restore the host from a known good backup if necessary, ensuring that the backup is free from compromise.
- Monitor the host and network for any signs of re-infection or further suspicious activity, using enhanced logging and alerting based on the identified attack patterns.
- Escalate the incident to the appropriate internal or external cybersecurity teams for further investigation and potential legal action if the attack is part of a larger campaign.
Related rules
- Alerts From Multiple Integrations by Destination Address
- Alerts From Multiple Integrations by Source Address
- Alerts From Multiple Integrations by User Name
- Alerts in Different ATT&CK Tactics by Host
- Detection Alert on a Process Exhibiting CPU Spike