endgame_adversary_behavior_detected.toml

[metadata]
creation_date = "2020/02/18"
maturity = "production"
promotion = true
updated_date = "2025/01/15"

[rule]
author = ["Elastic"]
description = """
Elastic Endgame detected an Adversary Behavior. Click the Elastic Endgame icon in the event.module column or the link in
the rule.reference column for additional information.
"""
from = "now-15m"
index = ["endgame-*"]
interval = "10m"
language = "kuery"
license = "Elastic License v2"
max_signals = 10000
name = "Adversary Behavior - Detected - Elastic Endgame"
risk_score = 47
rule_id = "77a3c3df-8ec4-4da4-b758-878f551dee69"
setup = """## Setup

This rule is configured to generate more **Max alerts per run** than the default 1000 alerts per run set for all rules. This is to ensure that it captures as many alerts as possible.

**IMPORTANT:** The rule's **Max alerts per run** setting can be superseded by the `xpack.alerting.rules.run.alerts.max` Kibana config setting, which determines the maximum alerts generated by _any_ rule in the Kibana alerting framework. For example, if `xpack.alerting.rules.run.alerts.max` is set to 1000, this rule will still generate no more than 1000 alerts even if its own **Max alerts per run** is set higher.

To make sure this rule can generate as many alerts as it's configured in its own **Max alerts per run** setting, increase the `xpack.alerting.rules.run.alerts.max` system setting accordingly.

**NOTE:** Changing `xpack.alerting.rules.run.alerts.max` is not possible in Serverless projects."""
severity = "medium"
tags = ["Data Source: Elastic Endgame", "Resources: Investigation Guide"]
timestamp_override = "event.ingested"
type = "query"

query = '''
event.kind:alert and event.module:endgame and (event.action:behavior_protection_event or endgame.event_subtype_full:behavior_protection_event)
'''
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 Adversary Behavior - Detected - Elastic Endgame

Elastic Endgame is a security solution designed to detect and prevent adversarial actions by monitoring system behaviors. Adversaries may exploit system vulnerabilities or execute unauthorized actions to compromise environments. This detection rule identifies suspicious behavior by analyzing alerts and specific event actions, flagging potential threats for further investigation. The rule's medium severity and risk score highlight its importance in maintaining security posture.

### Possible investigation steps

- Review the alert details in the Elastic Endgame console by clicking the Elastic Endgame icon in the event.module column or the link in the rule.reference column to gather more context about the detected behavior.
- Analyze the event.action and endgame.event_subtype_full fields to understand the specific behavior protection event that triggered the alert.
- Correlate the alert with other recent alerts or logs from the same host or user to identify any patterns or additional suspicious activities.
- Investigate the affected system for any signs of compromise or unauthorized changes, focusing on the timeframe around the alert.
- Check for any known vulnerabilities or misconfigurations in the affected system that could have been exploited by the adversary.
- Consult with the IT or security team to determine if any recent changes or updates could have triggered the alert as a false positive.

### False positive analysis

- Routine software updates or installations may trigger alerts due to behavior resembling adversarial actions. Users can create exceptions for known update processes to reduce false positives.
- Legitimate administrative tasks, such as system configuration changes, might be flagged. Identifying and excluding these tasks from monitoring can help minimize unnecessary alerts.
- Security tools or scripts that perform regular scans or maintenance can mimic adversary behavior. Whitelisting these tools in the detection rule settings can prevent them from being flagged.
- Automated backup processes that access multiple files or systems simultaneously may be misinterpreted as suspicious. Users should ensure these processes are recognized and excluded from triggering alerts.
- Custom applications with unique behaviors might be incorrectly identified as threats. Users should document and exclude these behaviors if they are verified as non-threatening.

### Response and remediation

- Isolate the affected system immediately to prevent further unauthorized actions or potential lateral movement by the adversary.
- Review the specific event.action and endgame.event_subtype_full fields to understand the nature of the detected behavior and identify any compromised accounts or processes.
- Terminate any unauthorized processes or sessions identified during the investigation to halt adversary activities.
- Apply security patches or updates to address any exploited vulnerabilities that may have been used by the adversary.
- Conduct a thorough scan of the affected system and network to identify and remove any malicious artifacts or backdoors left by the adversary.
- Restore affected systems from a known good backup if necessary, ensuring that the backup is free from compromise.
- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected."""