Correlated Alerts on Similar User Identities

Description

This rule correlates alerts from multiple integrations and event categories that involve different user.name values which may represent the same real-world identity. It uses an LLM-based similarity analysis to evaluate whether multiple user identifiers (e.g. naming variations, formats, aliases, or domain differences) likely belong to the same person.

Query · esql

from .alerts-security.*

// truncate timestamp to 5-minute window
| eval Esql.time_window_date_trunc = date_trunc(5 minutes, @timestamp)

// high severity alerts excluding system standard user.ids
| where kibana.alert.rule.name is not null and user.name is not null and kibana.alert.risk_score >= 73 and kibana.alert.workflow_status == "open" and 
        not kibana.alert.rule.type in ("threat_match", "machine_learning") and
        not user.id in ("S-1-5-18", "S-1-5-19", "S-1-5-20", "0")

// group alerts by short time window and extract values of interest for alert triage
| stats Esql.event_module_distinct_count = COUNT_DISTINCT(event.module),
        Esql.user_name_distinct_count = COUNT_DISTINCT(user.name),
        Esql.rule_name_distinct_count = COUNT_DISTINCT(kibana.alert.rule.name),
        Esql.event_category_distinct_count = COUNT_DISTINCT(event.category),
        Esql.rule_risk_score_distinct_count = COUNT_DISTINCT(kibana.alert.risk_score),
        Esql.event_module_values = VALUES(event.module),
        Esql.rule_name_values = VALUES(kibana.alert.rule.name),
        Esql.message_values = VALUES(message),
        Esql.event_category_values = VALUES(event.category),
        Esql.event_action_values = VALUES(event.action),
        Esql.source_ip_values = VALUES(source.ip),
        Esql.destination_ip_values = VALUES(destination.ip),
        Esql.host_id_values = VALUES(host.id),
        Esql.agent_id_values = VALUES(agent.id),
        Esql.rule_severity_values = VALUES(kibana.alert.risk_score),
        Esql.user_name_values = VALUES(user.name) by Esql.time_window_date_trunc

// filter for alerts from different integrations with unique categories
| where Esql.event_module_distinct_count >= 2 and Esql.user_name_distinct_count >= 2 and Esql.event_category_distinct_count >= 2

// build context for LLM analysis
| eval users_list = MV_CONCAT(Esql.user_name_values, ",")

// LLM analysis
| eval instructions = "Analyze the provided user names and return a boolean value true if at least 2 of them are similar and they may belong to the same human identity or false if not, do not compare user names that may look like service accounts. If the list of users has more than 2 users and only 2 of them are similar consider this as true. Structure the output as follows: verdict=<verdict> confidence=<score between 0.0 and 1.0> summary=<short reason max 500 words> without any other response statements on a single line."
| eval prompt = CONCAT("User identities extracted from different alerts: ", users_list, instructions)
| COMPLETION triage_result = prompt WITH { "inference_id": ".anthropic-claude-4.6-sonnet-completion"}

// parse LLM response
| DISSECT triage_result """verdict=%{Esql.verdict} confidence=%{Esql.confidence} summary=%{Esql.summary}"""

// filter for similar user values
| where TO_LOWER(Esql.verdict) == "true"
| keep Esql.*

Rule dependencies

Depends on

  • correlates · Elastic alerts index
    Correlates over any alert. No specific upstream rule.

Implementation guide

LLM Configuration

This rule uses the ES|QL COMPLETION command with Elastic Inference Service Claude Sonnet 4.6 (.anthropic-claude-4.6-sonnet-completion), which is available out-of-the-box in Elastic Cloud deployments with an appropriate subscription. See EIS supported models.

To use a different LLM provider (Azure OpenAI, Amazon Bedrock, OpenAI, or Google Vertex), configure a connector following the LLM connector documentation and update the inference_id parameter in the query to reference your configured connector.

Analyst notes

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, analysts should validate findings against their environment and identity architecture.

Investigating Correlated Alerts on Similar User Identities

This rule identifies alerts from multiple integrations and event categories involving different user.name values that may represent the same real-world identity. An LLM is used to assess string similarity and naming patterns to determine whether multiple user identifiers likely belong to the same person, which may indicate account compromise, credential abuse, or identity misuse across systems.

Possible investigation steps

  • Review the correlated user.name values and validate whether they represent naming variations, aliases, or identity mappings.
  • Examine the LLM output fields (verdict, confidence, summary) as decision support, not ground truth.
  • Analyze the diversity of alert sources, event categories, and detection rules involved.
  • Reconstruct the alert timeline to identify potential stages such as initial access, lateral movement, privilege escalation, or persistence.
  • Correlate with authentication logs, IAM/SSO telemetry, EDR data, and network logs to identify shared sessions, IPs, devices, or hosts.
  • Validate identities against directory services, identity providers, and federation mappings.

False positive analysis

  • Identity format variations across systems (e.g., first.last, flast, user@domain).
  • Federated identity mappings between on-prem, cloud, and SaaS platforms.
  • Service, automation, and CI/CD accounts with similar naming conventions.
  • Separate admin and standard user accounts for the same individual.
  • Shared credentials or naming templates in development and test environments.

Response and remediation

  • Temporarily disable or suspend correlated accounts if compromise is suspected.
  • Revoke active sessions, tokens, and credentials.
  • Investigate access scope, privileges, and lateral movement paths.
  • Perform endpoint and identity forensics to identify persistence mechanisms.
  • Remediate IAM misconfigurations and federation issues.
  • Enhance monitoring for identity correlation, credential misuse, and cross-platform abuse.
Raw source Correlated Alerts on Similar User Identities · Elastic TOML
Esc
Published by elastic/detection-rules ↗, licensed under Elastic License 2.0 ↗. Reproduced here unmodified. 
[metadata]
creation_date = "2026/02/12"
maturity = "production"
min_stack_comments = "ES|QL COMPLETION and INLINE STATS require Elastic Stack 9.3.0 or later."
min_stack_version = "9.3.0"
updated_date = "2026/08/06"

[rule]
author = ["Elastic"]
description = """
This rule correlates alerts from multiple integrations and event categories that involve different user.name values which
may represent the same real-world identity. It uses an LLM-based similarity analysis to evaluate whether multiple user identifiers
(e.g. naming variations, formats, aliases, or domain differences) likely belong to the same person.
"""
from = "now-60m"
interval = "30m"
language = "esql"
license = "Elastic License v2"
name = "Correlated Alerts on Similar User Identities"
references = [
    "https://www.elastic.co/docs/reference/query-languages/esql/esql-commands#esql-completion",
    "https://www.elastic.co/docs/explore-analyze/elastic-inference/eis-supported-models",
    "https://www.elastic.co/security-labs/elastic-advances-llm-security",
]
risk_score = 73
rule_id = "1bb329a5-2168-4da5-b7b9-d42a51deb6dd"
setup = """## Setup

### LLM Configuration

This rule uses the ES|QL COMPLETION command with Elastic Inference Service Claude Sonnet 4.6
(`.anthropic-claude-4.6-sonnet-completion`), which is available out-of-the-box in Elastic Cloud deployments
with an appropriate subscription. See [EIS supported models](https://www.elastic.co/docs/explore-analyze/elastic-inference/eis-supported-models).

To use a different LLM provider (Azure OpenAI, Amazon Bedrock, OpenAI, or Google Vertex), configure a connector
following the [LLM connector documentation](https://www.elastic.co/docs/explore-analyze/ai-features/llm-guides/llm-connectors)
and update the `inference_id` parameter in the query to reference your configured connector.
"""
severity = "high"
tags = [
    "Domain: Identity",
    "Domain: LLM",
    "Use Case: Threat Detection",
    "Use Case: Identity and Access Audit",
    "Resources: Investigation Guide",
    "Resources: LLM",
    "Rule Type: Higher-Order Rule",
]
timestamp_override = "event.ingested"
type = "esql"

query = '''
from .alerts-security.*

// truncate timestamp to 5-minute window
| eval Esql.time_window_date_trunc = date_trunc(5 minutes, @timestamp)

// high severity alerts excluding system standard user.ids
| where kibana.alert.rule.name is not null and user.name is not null and kibana.alert.risk_score >= 73 and kibana.alert.workflow_status == "open" and 
        not kibana.alert.rule.type in ("threat_match", "machine_learning") and
        not user.id in ("S-1-5-18", "S-1-5-19", "S-1-5-20", "0")

// group alerts by short time window and extract values of interest for alert triage
| stats Esql.event_module_distinct_count = COUNT_DISTINCT(event.module),
        Esql.user_name_distinct_count = COUNT_DISTINCT(user.name),
        Esql.rule_name_distinct_count = COUNT_DISTINCT(kibana.alert.rule.name),
        Esql.event_category_distinct_count = COUNT_DISTINCT(event.category),
        Esql.rule_risk_score_distinct_count = COUNT_DISTINCT(kibana.alert.risk_score),
        Esql.event_module_values = VALUES(event.module),
        Esql.rule_name_values = VALUES(kibana.alert.rule.name),
        Esql.message_values = VALUES(message),
        Esql.event_category_values = VALUES(event.category),
        Esql.event_action_values = VALUES(event.action),
        Esql.source_ip_values = VALUES(source.ip),
        Esql.destination_ip_values = VALUES(destination.ip),
        Esql.host_id_values = VALUES(host.id),
        Esql.agent_id_values = VALUES(agent.id),
        Esql.rule_severity_values = VALUES(kibana.alert.risk_score),
        Esql.user_name_values = VALUES(user.name) by Esql.time_window_date_trunc

// filter for alerts from different integrations with unique categories
| where Esql.event_module_distinct_count >= 2 and Esql.user_name_distinct_count >= 2 and Esql.event_category_distinct_count >= 2

// build context for LLM analysis
| eval users_list = MV_CONCAT(Esql.user_name_values, ",")

// LLM analysis
| eval instructions = "Analyze the provided user names and return a boolean value true if at least 2 of them are similar and they may belong to the same human identity or false if not, do not compare user names that may look like service accounts. If the list of users has more than 2 users and only 2 of them are similar consider this as true. Structure the output as follows: verdict=<verdict> confidence=<score between 0.0 and 1.0> summary=<short reason max 500 words> without any other response statements on a single line."
| eval prompt = CONCAT("User identities extracted from different alerts: ", users_list, instructions)
| COMPLETION triage_result = prompt WITH { "inference_id": ".anthropic-claude-4.6-sonnet-completion"}

// parse LLM response
| DISSECT triage_result """verdict=%{Esql.verdict} confidence=%{Esql.confidence} summary=%{Esql.summary}"""

// filter for similar user values
| where TO_LOWER(Esql.verdict) == "true"
| keep Esql.*
'''
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, analysts should validate findings against their environment and identity architecture.

### Investigating Correlated Alerts on Similar User Identities

This rule identifies alerts from multiple integrations and event categories involving different `user.name` values that may represent the same real-world identity.
An LLM is used to assess string similarity and naming patterns to determine whether multiple user identifiers likely belong to the same person, which may indicate account compromise, credential abuse, or identity misuse across systems.

### Possible investigation steps

- Review the correlated `user.name` values and validate whether they represent naming variations, aliases, or identity mappings.
- Examine the LLM output fields (`verdict`, `confidence`, `summary`) as decision support, not ground truth.
- Analyze the diversity of alert sources, event categories, and detection rules involved.
- Reconstruct the alert timeline to identify potential stages such as initial access, lateral movement, privilege escalation, or persistence.
- Correlate with authentication logs, IAM/SSO telemetry, EDR data, and network logs to identify shared sessions, IPs, devices, or hosts.
- Validate identities against directory services, identity providers, and federation mappings.

### False positive analysis

- Identity format variations across systems (e.g., `first.last`, `flast`, `user@domain`).
- Federated identity mappings between on-prem, cloud, and SaaS platforms.
- Service, automation, and CI/CD accounts with similar naming conventions.
- Separate admin and standard user accounts for the same individual.
- Shared credentials or naming templates in development and test environments.

### Response and remediation

- Temporarily disable or suspend correlated accounts if compromise is suspected.
- Revoke active sessions, tokens, and credentials.
- Investigate access scope, privileges, and lateral movement paths.
- Perform endpoint and identity forensics to identify persistence mechanisms.
- Remediate IAM misconfigurations and federation issues.
- Enhance monitoring for identity correlation, credential misuse, and cross-platform abuse."""

Detection rules belong to the projects that publish them and remain under their own licenses. This site indexes and links to them; it claims no rights in them.