Lateral Movement Alerts from a Newly Observed Source Address

This rule detects source IPs that triggered their first lateral movement alert within the last 10 minutes (i.e., newly observed), while also triggering at least 2 distinct lateral movement detection rules. This surfaces new potentially malicious IPs exhibiting immediate lateral movement behavior.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/01/14"
  3maturity = "production"
  4updated_date = "2026/02/16"
  5
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10This rule detects source IPs that triggered their first lateral movement alert within the last 10 minutes (i.e., newly observed), while also triggering at least 2 distinct lateral movement detection rules. This surfaces new potentially malicious IPs exhibiting immediate lateral movement behavior.
 11"""
 12from = "now-7200m"
 13interval = "10m"
 14language = "esql"
 15license = "Elastic License v2"
 16name = "Lateral Movement Alerts from a Newly Observed Source Address"
 17risk_score = 73
 18rule_id = "0e67f4f1-f683-43c0-8d45-c3293cf31e5d"
 19setup = """## Setup
 20
 21This rule requires the `host.ip` field to be populated.
 22For **Elastic Defend** events on versions **8.18 and above**, this field is **disabled by default**.
 23
 24If you are using **Elastic Defend**, ensure host IP collection is enabled by following the configuration steps in the
 25[helper guide](https://www.elastic.co/docs/solutions/security/configure-elastic-defend/configure-data-volume-for-elastic-endpoint#host-fields).
 26"""
 27severity = "high"
 28tags = ["Use Case: Threat Detection", "Rule Type: Higher-Order Rule", "Tactic: Lateral Movement", "Resources: Investigation Guide"]
 29timestamp_override = "event.ingested"
 30type = "esql"
 31
 32query = '''
 33FROM .alerts-security.* METADATA _index
 34
 35// Lateral Movement related rules with fields of interest
 36| where kibana.alert.rule.threat.tactic.name is not null and
 37        source.ip IS NOT NULL and destination.ip is not null and
 38        host.id is not null and KQL("""kibana.alert.rule.threat.tactic.name : "Lateral Movement" and not kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """)
 39
 40// aggregate stats by source.ip
 41| stats  Esql.first_time_seen = MIN(@timestamp),
 42         Esql.alerts_count = count(*),
 43         Esql.unique_rules_count = COUNT_DISTINCT(kibana.alert.rule.name),
 44         Esql.unique_count_host_id = COUNT_DISTINCT(host.id),
 45         Esql.rule_name_values = VALUES(kibana.alert.rule.name),
 46         Esql.user_name_values = VALUES(user.name),
 47         Esql.host_id_values = VALUES(host.id),
 48         Esql.host_ip_values = VALUES(host.ip),
 49         Esql.tactic_name_values = VALUES(kibana.alert.rule.threat.tactic.name) by source.ip
 50
 51// values we will need for next filter
 52| eval isLocal = locate(MV_CONCAT(to_string(Esql.host_ip_values), ","), to_string(source.ip)),
 53       Esql.date_diff = DATE_DIFF("minute", Esql.first_time_seen, now())
 54
 55// at least 2 unique rules from same source.ip and that was first seen in last 5 days
 56| where Esql.unique_rules_count >= 2 and
 57        // matches are within 10m of the rule execution time to avoid alert duplicates
 58        Esql.date_diff <= 10 and
 59        // make sure source.ip is not equal to host.ip
 60        not isLocal > 0 and
 61        // reduce noise from SCCM, Nessus and alike
 62        Esql.unique_count_host_id <= 3 and Esql.alerts_count <= 20
 63| eval host.id = MV_FIRST(Esql.host_id_values), user.name = MV_FIRST(Esql.user_name_values)
 64| KEEP Esql.*, source.ip, host.id, user.name
 65'''
 66note = """## Triage and analysis
 67
 68### Investigating Lateral Movement Alerts from a Newly Observed Source Address
 69
 70This rule surfaces newly observed, low-frequency source address triggering multiple lateral movement alerts.
 71
 72Because the alert has not been seen previously for this rule and host, it should be prioritized for validation to determine
 73whether it represents a true compromise or rare benign activity.
 74
 75### Investigation Steps
 76
 77- Identify the source address, affected host, user and review the associated rule name to understand the behavior that triggered the alert.
 78- Validate the source address and user context under which the activity occurred and assess whether it aligns with normal behavior for that address.
 79- Refer to the specific rule investigation guide for further actions.
 80
 81### False Positive Considerations
 82
 83- Administrative scripts or automation tools can trigger behavior-based detections when first introduced.
 84- Security tooling, IT management agents, or EDR integrations may generate new behavior alerts during updates or configuration changes.
 85- Development or testing environments may produce one-off behaviors that resemble malicious techniques.
 86
 87### Response and Remediation
 88
 89- If the activity is confirmed malicious, isolate the affected host to prevent further execution or lateral movement.
 90- Terminate malicious processes and remove any dropped files or persistence mechanisms.
 91- Collect forensic artifacts to understand initial access and execution flow.
 92- Patch or remediate any vulnerabilities or misconfigurations that enabled the behavior.
 93- If benign, document the finding and consider tuning or exception handling to reduce future noise.
 94- Continue monitoring the host and environment for recurrence of the behavior or related alerts."""
 95references = ["https://www.elastic.co/docs/solutions/security/detect-and-alert/about-detection-rules"]
 96
 97[[rule.threat]]
 98framework = "MITRE ATT&CK"
 99[rule.threat.tactic]
100id = "TA0008"
101name = "Lateral Movement"
102reference = "https://attack.mitre.org/tactics/TA0008/"

Triage and analysis

Investigating Lateral Movement Alerts from a Newly Observed Source Address

This rule surfaces newly observed, low-frequency source address triggering multiple lateral movement alerts.

Because the alert has not been seen previously for this rule and host, it should be prioritized for validation to determine whether it represents a true compromise or rare benign activity.

Investigation Steps

  • Identify the source address, affected host, user and review the associated rule name to understand the behavior that triggered the alert.
  • Validate the source address and user context under which the activity occurred and assess whether it aligns with normal behavior for that address.
  • Refer to the specific rule investigation guide for further actions.

False Positive Considerations

  • Administrative scripts or automation tools can trigger behavior-based detections when first introduced.
  • Security tooling, IT management agents, or EDR integrations may generate new behavior alerts during updates or configuration changes.
  • Development or testing environments may produce one-off behaviors that resemble malicious techniques.

Response and Remediation

  • If the activity is confirmed malicious, isolate the affected host to prevent further execution or lateral movement.
  • Terminate malicious processes and remove any dropped files or persistence mechanisms.
  • Collect forensic artifacts to understand initial access and execution flow.
  • Patch or remediate any vulnerabilities or misconfigurations that enabled the behavior.
  • If benign, document the finding and consider tuning or exception handling to reduce future noise.
  • Continue monitoring the host and environment for recurrence of the behavior or related alerts.

References

Related rules

to-top