From a952cd09384f271f854ecd8a526390b9328d7b0d Mon Sep 17 00:00:00 2001 From: tradebot-elastic <178941316+tradebot-elastic@users.noreply.github.com> Date: Wed, 29 Apr 2026 06:11:52 +0000 Subject: [PATCH] Update latest docs --- ...-different-att-ck-tactics-by-host.asciidoc | 136 ++++++++++++++++++ ...rts-in-same-att-ck-tactic-by-host.asciidoc | 126 ++++++++++++++++ ...-multiple-alerts-involving-a-user.asciidoc | 121 ++++++++++++++++ ...tiple-external-edr-alerts-by-host.asciidoc | 131 +++++++++++++++++ ...ved-high-severity-detection-alert.asciidoc | 121 ++++++++++++++++ ...wing-unusual-proxy-authentication.asciidoc | 125 ++++++++++++++++ .../prebuilt-rules-8-19-22-appendix.asciidoc | 12 ++ .../prebuilt-rules-8-19-22-summary.asciidoc | 24 ++++ ...ebuilt-rules-downloadable-updates.asciidoc | 5 + .../prebuilt-rules-reference.asciidoc | 12 +- ...-different-att-ck-tactics-by-host.asciidoc | 4 +- ...rts-in-same-att-ck-tactic-by-host.asciidoc | 4 +- .../multiple-alerts-involving-a-user.asciidoc | 30 ++-- ...tiple-external-edr-alerts-by-host.asciidoc | 54 +++---- ...ved-high-severity-detection-alert.asciidoc | 17 ++- ...wing-unusual-proxy-authentication.asciidoc | 6 +- docs/index.asciidoc | 2 + 17 files changed, 866 insertions(+), 64 deletions(-) create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-22/prebuilt-rule-8-19-22-alerts-in-different-att-ck-tactics-by-host.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-22/prebuilt-rule-8-19-22-multiple-alerts-in-same-att-ck-tactic-by-host.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-22/prebuilt-rule-8-19-22-multiple-alerts-involving-a-user.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-22/prebuilt-rule-8-19-22-multiple-external-edr-alerts-by-host.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-22/prebuilt-rule-8-19-22-newly-observed-high-severity-detection-alert.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-22/prebuilt-rule-8-19-22-okta-alerts-following-unusual-proxy-authentication.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-22/prebuilt-rules-8-19-22-appendix.asciidoc create mode 100644 docs/detections/prebuilt-rules/downloadable-packages/8-19-22/prebuilt-rules-8-19-22-summary.asciidoc diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-22/prebuilt-rule-8-19-22-alerts-in-different-att-ck-tactics-by-host.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-22/prebuilt-rule-8-19-22-alerts-in-different-att-ck-tactics-by-host.asciidoc new file mode 100644 index 0000000000..01dd8ceae0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-22/prebuilt-rule-8-19-22-alerts-in-different-att-ck-tactics-by-host.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-19-22-alerts-in-different-att-ck-tactics-by-host]] +=== Alerts in Different ATT&CK Tactics by Host + +This rule uses alert data to determine when multiple alerts in different phases of an attack involving the same host are triggered and where the accumulated risk score is higher than a defined threshold. Analysts can use this to prioritize triage and response, as these hosts are more likely to be compromised. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 1h + +*Searches indices from*: now-8h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: Higher-Order Rule +* Resources: Investigation Guide + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*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 Alerts in Different ATT&CK Tactics by Host* + + +The detection rule identifies hosts with alerts across various attack phases, indicating potential compromise. Adversaries exploit system vulnerabilities, moving through different tactics like execution, persistence, and exfiltration. This rule prioritizes hosts with diverse tactic alerts, aiding analysts in focusing on high-risk threats by correlating alert data to detect complex attack patterns. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific host involved and the different ATT&CK tactics that triggered the alerts. +- 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* + + +- Alerts from routine administrative tasks may trigger multiple tactics. Review and exclude known benign activities such as scheduled software updates or system maintenance. +- Security tools running on the host might generate alerts across different tactics. Identify and exclude alerts from trusted security applications to reduce noise. +- Automated scripts or batch processes can mimic adversarial behavior. Analyze and whitelist these processes if they are verified as non-threatening. +- Frequent alerts from development or testing environments can be misleading. Consider excluding these environments from the rule or applying a different risk score. +- User behavior anomalies, such as accessing multiple systems or applications, might trigger alerts. Implement user behavior baselines to differentiate between normal and suspicious activities. + + +*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. + +==== Rule query + + +[source, js] +---------------------------------- +from .alerts-security.* metadata _id + +// filter for alerts with populated risk score, excluding threat_match rules, deprecated and some other noisy ones. +| where kibana.alert.risk_score > 0 and + kibana.alert.rule.name IS NOT NULL and + host.id is not null and event.dataset is not null and + kibana.alert.rule.type != "threat_match" and + // Top noisy influencing rules + not kibana.alert.rule.name in ("Agent Spoofing - Mismatched Agent ID", "Compression DLL Loaded by Unusual Process", "Process Termination followed by Deletion", "Suspicious PrintSpooler Service Executable File Creation", "Potential PrintNightmare File Modification") and + not kibana.alert.rule.name like "Deprecated - *" and + not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """) + +// extract unique counts and values by host.id +| stats Esql.alerts_count = COUNT(*), + Esql.kibana_alert_rule_name_distinct_count = COUNT_DISTINCT(kibana.alert.rule.name), + Esql.event_module_distinct_count = COUNT_DISTINCT(event.module), + Esql.event_module_values = VALUES(event.module), + Esql.kibana_alert_rule_name_values = VALUES(kibana.alert.rule.name), + Esql.threat_tactic_id_distinct_count = COUNT_DISTINCT(kibana.alert.rule.threat.tactic.id), + Esql.threat_tactic_name_values = VALUES(kibana.alert.rule.threat.tactic.name), + Esql.kibana_alert_risk_score_sum = sum(kibana.alert.risk_score), + Esql.process_executable_values = VALUES(process.executable), + Esql.process_parent_executable_values = VALUES(process.parent.executable), + Esql.process_command_line_values = VALUES(process.command_line), + Esql.process_entity_id_distinct_count = COUNT_DISTINCT(process.entity_id) by host.id + +// divide the sum of risk scores by the total number of alerts +| eval Esql.risk_alerts_count_ratio = Esql.kibana_alert_risk_score_sum/Esql.alerts_count + +// filter for risky hosts by risk score and unique count of rules and tactics +| where Esql.kibana_alert_rule_name_distinct_count >= 5 and Esql.threat_tactic_id_distinct_count >= 3 and Esql.threat_tactic_id_distinct_count >= 3 and Esql.alerts_count <= 500 and Esql.risk_alerts_count_ratio >= 50 + +// fiels populated in the resulting alert +| keep host.id, + Esql.alerts_count, + Esql.kibana_alert_risk_score_sum, + Esql.risk_alerts_count_ratio, + Esql.kibana_alert_rule_name_distinct_count, + Esql.event_module_values, + Esql.kibana_alert_rule_name_values, + Esql.threat_tactic_name_values, + Esql.process_executable_values, + Esql.process_parent_executable_values, + Esql.process_command_line_values + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-22/prebuilt-rule-8-19-22-multiple-alerts-in-same-att-ck-tactic-by-host.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-22/prebuilt-rule-8-19-22-multiple-alerts-in-same-att-ck-tactic-by-host.asciidoc new file mode 100644 index 0000000000..26c213d59c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-22/prebuilt-rule-8-19-22-multiple-alerts-in-same-att-ck-tactic-by-host.asciidoc @@ -0,0 +1,126 @@ +[[prebuilt-rule-8-19-22-multiple-alerts-in-same-att-ck-tactic-by-host]] +=== Multiple Alerts in Same ATT&CK Tactic by Host + +This rule correlates multiple security alerts associated with the same ATT&CK tactic on a single host within a defined time window. By requiring alerts from multiple distinct detection rules, this detection helps identify hosts exhibiting concentrated malicious behavior, which may indicate an active intrusion or post-compromise activity. The rule is intended to assist analysts in prioritizing triage toward hosts with higher likelihood of compromise rather than signaling a single discrete event. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 30m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: Higher-Order Rule +* Resources: Investigation Guide + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*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 Multiple Alerts in Same ATT&CK Tactic by Host* + + +The detection rule identifies hosts with alerts from the same ATT&CK tactic, indicating potential compromise. Adversaries exploit system vulnerabilities, moving through different tactics like execution, defense evasion, and credential access. This rule prioritizes hosts with high-risk. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific host involved and the different techniques that triggered the alerts. +- 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* + + +- Alerts from routine administrative tasks may trigger multiple rules. Review and exclude known benign activities such as scheduled software updates or system maintenance. +- Security tools running on the host might generate multiple alerts. Identify and exclude alerts from trusted security applications to reduce noise. +- Automated scripts or batch processes can mimic adversarial behavior. Analyze and whitelist these processes if they are verified as non-threatening. +- Frequent alerts from development or testing environments can be misleading. Consider excluding these environments from the rule or applying a different risk score. +- User behavior anomalies, such as accessing multiple systems or applications, might trigger alerts. Implement user behavior baselines to differentiate between normal and suspicious activities. + + +*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. + +==== Rule query + + +[source, js] +---------------------------------- +from .alerts-security.* metadata _id + +| where kibana.alert.risk_score > 21 and + kibana.alert.rule.name IS NOT NULL and + host.id is not null and event.dataset is not null and + + // excluding ML and Threat Match rules as they tend to be noisy + not kibana.alert.rule.type in ("threat_match", "machine_learning") and + + // excluding noisy tactics like Discovery, Persistence and Lateral Movement + kibana.alert.rule.threat.tactic.name in ("Credential Access", "Defense Evasion", "Execution", "Command and Control") and + + // excluding some noisy rules + not kibana.alert.rule.name in ("Agent Spoofing - Mismatched Agent ID", "Process Termination followed by Deletion") and + not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """) + +// extract unique counts and values by host.id and tactic name +| stats Esql.alerts_count = COUNT(*), + Esql.kibana_alert_rule_name_distinct_count = COUNT_DISTINCT(kibana.alert.rule.name), + Esql.event_module_distinct_count = COUNT_DISTINCT(event.module), + Esql.event_module_values = VALUES(event.module), + Esql.kibana_alert_rule_name_values = VALUES(kibana.alert.rule.name), + Esql.threat_technique_id_distinct_count = COUNT_DISTINCT(kibana.alert.rule.threat.technique.id), + Esql.threat_technique_name_values = VALUES(kibana.alert.rule.threat.technique.name), + Esql.process_executable_values = VALUES(process.executable), + Esql.process_parent_executable_values = VALUES(process.parent.executable), + Esql.process_command_line_values = VALUES(process.command_line), + Esql.process_entity_id_distinct_count = COUNT_DISTINCT(process.entity_id) by host.id, kibana.alert.rule.threat.tactic.name + +// filter for at least 3 unique rules and exclude noisy patterns like high count of alerts or processes often associated with noisy FPs +| where Esql.kibana_alert_rule_name_distinct_count >= 3 and Esql.process_entity_id_distinct_count <= 10 and Esql.alerts_count <= 20 + +// fields populated in the resulting alerts +| Keep host.id, kibana.alert.rule.threat.tactic.name, Esql.* + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-22/prebuilt-rule-8-19-22-multiple-alerts-involving-a-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-22/prebuilt-rule-8-19-22-multiple-alerts-involving-a-user.asciidoc new file mode 100644 index 0000000000..0e97f29d1e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-22/prebuilt-rule-8-19-22-multiple-alerts-involving-a-user.asciidoc @@ -0,0 +1,121 @@ +[[prebuilt-rule-8-19-22-multiple-alerts-involving-a-user]] +=== Multiple Alerts Involving a User + +This rule uses alert data to determine when multiple different alerts involving the same user are triggered. Analysts can use this to prioritize triage and response, as these users are more likely to be compromised. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 1h + +*Searches indices from*: now-4h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: Higher-Order Rule +* Resources: Investigation Guide + +*Version*: 9 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*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 Multiple Alerts Involving a User* + + +In security environments, monitoring user activity is crucial as adversaries often exploit user accounts to gain unauthorized access. Attackers may trigger multiple alerts by performing suspicious actions under a compromised user account. The detection rule identifies such patterns by correlating diverse alerts linked to the same user, excluding known system accounts, thus prioritizing potential threats for analysts. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific user account involved, focusing on the user.name field to gather initial context about the user. +- Examine the timeline and sequence of the triggered alerts to understand the pattern of activity associated with the user, noting any unusual or unexpected actions. +- Cross-reference the user activity with known legitimate activities or scheduled tasks to rule out false positives, ensuring that the actions are not part of normal operations. +- Investigate the source and destination IP addresses associated with the alerts to identify any suspicious or unauthorized access points. +- Check for any recent changes in user permissions or group memberships that could indicate privilege escalation attempts. +- Look into any recent login attempts or authentication failures for the user account to detect potential brute force or credential stuffing attacks. +- Collaborate with the user or their manager to verify if the activities were authorized or if the account might be compromised. + + +*False positive analysis* + + +- Alerts triggered by automated system processes or scripts that mimic user behavior can be false positives. To manage these, identify and exclude known benign scripts or processes from the rule. +- Frequent alerts from users in roles that inherently require access to multiple systems or sensitive data, such as IT administrators, may not indicate compromise. Implement role-based exceptions to reduce noise. +- Alerts generated by legitimate software updates or maintenance activities can be mistaken for suspicious behavior. Schedule these activities during known maintenance windows and exclude them from the rule during these times. +- Users involved in testing or development environments may trigger multiple alerts due to their work nature. Create exceptions for these environments to prevent unnecessary alerts. +- High-volume users, such as those in customer support or sales, may naturally generate more alerts. Monitor these users separately and adjust the rule to focus on unusual patterns rather than volume alone. + + +*Response and remediation* + + +- Isolate the affected user account immediately to prevent further unauthorized access. Disable the account or change the password to stop any ongoing malicious activity. +- Conduct a thorough review of the affected user's recent activities and access logs to identify any unauthorized actions or data access. This will help in understanding the scope of the compromise. +- Remove any malicious software or unauthorized tools that may have been installed on the user's system. Use endpoint detection and response (EDR) tools to scan and clean the system. +- Restore any altered or deleted data from backups, ensuring that the restored data is free from any malicious modifications. +- Notify relevant stakeholders, including IT security teams and management, about the incident and the steps being taken to address it. This ensures that everyone is aware and can provide support if needed. +- Implement additional monitoring on the affected user account and related systems to detect any further suspicious activities. This includes setting up alerts for unusual login attempts or data access patterns. +- Review and update access controls and permissions for the affected user and similar accounts to prevent future incidents. Ensure that least privilege principles are applied. + +==== Rule query + + +[source, js] +---------------------------------- +from .alerts-security.* +| where kibana.alert.rule.name is not null and user.id is not null and + // Exclude low severity alerts + kibana.alert.risk_score > 21 and + not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """) +| stats + Esql.kibana_alert_rule_name_distinct_count = COUNT_DISTINCT(kibana.alert.rule.name), + Esql.kibana_alert_rule_rule_id_distinct_count = COUNT_DISTINCT(kibana.alert.rule.rule_id), + Esql.host_id_distinct_count = COUNT_DISTINCT(host.id), + Esql.kibana_alert_risk_score_distinct_count = COUNT_DISTINCT(kibana.alert.risk_score), + Esql.event_dataset_distinct_count = COUNT_DISTINCT(event.dataset), + Esql.kibana_alert_rule_name_values = VALUES(kibana.alert.rule.name), + Esql.kibana_alert_risk_score_values = VALUES(kibana.alert.risk_score), + Esql.event_dataset_values = VALUES(event.dataset), + Esql.event_module_values = VALUES(event.module), + Esql.process_command_line_values = VALUES(process.command_line), + Esql.host_id_values = VALUES(host.id), + Esql.source_ip_values = VALUES(source.ip), + Esql.destination_ip_values = VALUES(destination.ip) by user.id + +| where Esql.kibana_alert_rule_name_distinct_count >= 4 AND Esql.kibana_alert_rule_rule_id_distinct_count >= 2 and + // Exclude known system accounts with matches in more than one host + not ( + (length(TO_STRING(user.id)) <= 4 or user.id IN ("S-1-5-18", "S-1-5-19", "S-1-5-20", "0")) and + (Esql.host_id_distinct_count >= 2 or Esql.host_id_distinct_count == 0) + ) + +| keep user.id, Esql.* + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-22/prebuilt-rule-8-19-22-multiple-external-edr-alerts-by-host.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-22/prebuilt-rule-8-19-22-multiple-external-edr-alerts-by-host.asciidoc new file mode 100644 index 0000000000..9068f20d9b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-22/prebuilt-rule-8-19-22-multiple-external-edr-alerts-by-host.asciidoc @@ -0,0 +1,131 @@ +[[prebuilt-rule-8-19-22-multiple-external-edr-alerts-by-host]] +=== Multiple External EDR Alerts by Host + +This rule uses alert data to determine when multiple external EDR alerts involving the same host are triggered. Analysts can use this to prioritize triage and response, as these hosts are more likely to be compromised. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 30m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/elastic/detection-rules/blob/main/rules/promotions/external_alerts.toml + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: Higher-Order Rule +* Resources: Investigation Guide +* Domain: Endpoint + +*Version*: 5 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*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 Multiple External EDR Alerts by Host* + + +Endpoint security technologies monitor and analyze activities on devices to detect malicious behavior. Adversaries exploit these systems by deploying malware that triggers specific signatures across multiple hosts, indicating a coordinated attack. The detection rule identifies such threats by analyzing alert data for specific malware signatures across several hosts, flagging potential widespread infections for prioritized investigation. + + +*Possible investigation steps* + + +- Review the alert details to identify the specific host involved and the different ATT&CK tactics that triggered the alerts. +- 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* + + +- Alerts from routine administrative tasks may trigger multiple tactics. Review and exclude known benign activities such as scheduled software updates or system maintenance. +- Security tools running on the host might generate alerts across different tactics. Identify and exclude alerts from trusted security applications to reduce noise. +- Automated scripts or batch processes can mimic adversarial behavior. Analyze and whitelist these processes if they are verified as non-threatening. +- Frequent alerts from development or testing environments can be misleading. Consider excluding these environments from the rule or applying a different risk score. +- User behavior anomalies, such as accessing multiple systems or applications, might trigger alerts. Implement user behavior baselines to differentiate between normal and suspicious activities. + + +*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. + +==== Rule query + + +[source, js] +---------------------------------- +from .alerts-security.* +| WHERE event.dataset in ("crowdstrike.alert", "crowdstrike.falcon", "sentinel_one.alert", "sentinel_one.threat", "m365_defender.alert") and + host.id is not null and kibana.alert.risk_score > 21 and + not (event.module == "crowdstrike" and (kibana.alert.rule.name like "* at *" or kibana.alert.rule.name like "* on *" or kibana.alert.rule.name == "EICARTestFileWrittenWin")) and + not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """) +| stats Esql.alerts_count = COUNT(*), + Esql.kibana_alert_risk_score_distinct_count = COUNT_DISTINCT(kibana.alert.risk_score), + Esql.kibana_alert_rule_name_distinct_count = COUNT_DISTINCT(kibana.alert.rule.name), + Esql.process_executable_distinct_count = COUNT_DISTINCT(process.executable), + Esql.file_path_distinct_count = COUNT_DISTINCT(file.path), + Esql.process_command_line_distinct_count = COUNT_DISTINCT(process.command_line), + Esql.kibana_alert_risk_score_values = VALUES(kibana.alert.risk_score), + Esql.process_executable_values = VALUES(process.executable), + Esql.file_path_values = VALUES(file.path), + Esql.user_name_values = VALUES(user.name), + Esql.process_command_line_values = VALUES(process.command_line), + Esql.process_parent_command_line_values = VALUES(process.parent.command_line), + Esql.kibana_alert_rule_name_values = VALUES(kibana.alert.rule.name) by host.id, host.name, event.module +| where ( + // 3+ unique rules or processes + ( + Esql.kibana_alert_rule_name_distinct_count >= 3 or + (Esql.process_executable_distinct_count >= 3 and Esql.kibana_alert_rule_name_values == "External Alerts") + ) and + // and 2+ rules of different severity, or 1 high/critical severity rule + ( + Esql.kibana_alert_risk_score_distinct_count >= 2 or + Esql.kibana_alert_risk_score_values == 73 or + Esql.kibana_alert_risk_score_values == 99 + ) +) or + // or 5+ unique rules from the same host for 1+ path/command_line/process + (Esql.kibana_alert_rule_name_distinct_count >= 5 and Esql.alerts_count <= 50 and + (Esql.file_path_distinct_count >= 1 or Esql.process_command_line_distinct_count >= 1 or Esql.process_executable_distinct_count >= 1) +) +| KEEP event.module, host.id, host.name, Esql.* + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-22/prebuilt-rule-8-19-22-newly-observed-high-severity-detection-alert.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-22/prebuilt-rule-8-19-22-newly-observed-high-severity-detection-alert.asciidoc new file mode 100644 index 0000000000..0dd1cd8058 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-22/prebuilt-rule-8-19-22-newly-observed-high-severity-detection-alert.asciidoc @@ -0,0 +1,121 @@ +[[prebuilt-rule-8-19-22-newly-observed-high-severity-detection-alert]] +=== Newly Observed High Severity Detection Alert + +This rule detects Elastic SIEM high severity detection alerts that are observed for the first time in the previous 5 days of alert history. It highlights low-volume, newly observed alerts tied to a specific detection rule, analysts can use this to prioritize triage and response. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-7205m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/docs/solutions/security/detect-and-alert/about-detection-rules + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: Higher-Order Rule +* Resources: Investigation Guide + +*Version*: 6 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Newly Observed High Severity Detection Alert* + + +This rule surfaces newly observed, low-frequency behavior high severity alerts affecting a single agent within the current day. + +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 affected host, user and review the associated rule name to understand the behavior that triggered the alert. +- Validate the user context under which the activity occurred and assess whether it aligns with normal behavior for that account. +- Refer to the specific rule investiguation guide for further actions. + + +*False Positive Considerations* + + +- Newly deployed or updated software may introduce behavior not previously observed on the host. +- 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. + +==== Rule query + + +[source, js] +---------------------------------- +FROM .alerts-security.* +| where kibana.alert.rule.name is not null and kibana.alert.risk_score >= 73 and + not kibana.alert.rule.type in ("threat_match", "machine_learning", "new_terms") and + not kibana.alert.rule.name like "Deprecated - *" and kibana.alert.rule.name != "My First Rule" and + // covered by 7306ce7d-5c90-4f42-aa6c-12b0dc2fe3b8 + event.dataset != "endpoint.alerts" and + not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """) +| STATS Esql.alerts_count = count(*), + Esql.first_time_seen = MIN(@timestamp), + Esql.last_time_seen = MAX(@timestamp), + Esql.process_executable = VALUES(process.executable), + Esql.process_command_line_values = VALUES(process.command_line), + Esql.process_parent_executable_values = VALUES(process.parent.executable), + Esql.file_path_values = VALUES(file.path), + Esql.dll_path_values = VALUES(dll.path), + Esql.user_id_values = VALUES(user.id), + Esql.user_name_values = VALUES(user.name), + Esql.agent_id_values = VALUES(agent.id), + Esql.host_id_values = VALUES(host.id), + Esql.event_module_values = VALUES(event.module), + Esql.source_ip_values = VALUES(source.ip), + Esql.kibana_alert_rule_name_values = VALUES(kibana.alert.rule.name), + Esql.agent_id_distinct_count = COUNT_DISTINCT(agent.id) by kibana.alert.rule.name +// fist time seen in the last 5 days - defined in the rule schedule Additional look-back time +| eval Esql.recent = DATE_DIFF("minute", Esql.first_time_seen, now()) +// first time seen is within 10m of the rule execution time +| where Esql.recent <= 10 and Esql.agent_id_distinct_count == 1 and Esql.alerts_count <= 10 and (Esql.last_time_seen == Esql.first_time_seen) + +// Move single values to their corresponding ECS fields for alerts exclusion +| eval host.id = mv_min(Esql.host_id_values) + +| keep host.id, kibana.alert.rule.name, Esql.* + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-22/prebuilt-rule-8-19-22-okta-alerts-following-unusual-proxy-authentication.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-22/prebuilt-rule-8-19-22-okta-alerts-following-unusual-proxy-authentication.asciidoc new file mode 100644 index 0000000000..b07041636f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-22/prebuilt-rule-8-19-22-okta-alerts-following-unusual-proxy-authentication.asciidoc @@ -0,0 +1,125 @@ +[[prebuilt-rule-8-19-22-okta-alerts-following-unusual-proxy-authentication]] +=== Okta Alerts Following Unusual Proxy Authentication + +Correlates the first occurrence of an Okta user session started via a proxy with subsequent Okta security alerts for the same user. Attackers frequently use proxy infrastructure (VPNs, Tor, residential proxies) to mask their origin when using stolen credentials, and their post-authentication activity often triggers additional detection rules. + +*Rule type*: eql + +*Rule indices*: + +* .alerts-security.* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 30m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://developer.okta.com/docs/reference/api/system-log/ +* https://developer.okta.com/docs/reference/api/event-types/ +* https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy +* https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security +* https://www.elastic.co/security-labs/starter-guide-to-understanding-okta +* https://cloud.google.com/blog/topics/threat-intelligence/expansion-shinyhunters-saas-data-theft + +*Tags*: + +* Domain: Identity +* Domain: Cloud +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Data Source: Okta +* Data Source: Okta System Logs +* Tactic: Initial Access +* Rule Type: Higher-Order Rule +* Resources: Investigation Guide + +*Version*: 3 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Okta Alerts Following Unusual Proxy Authentication* + + +This rule correlates the first occurrences of authentication behind a proxy followed by an alert with subsequent Okta security alerts for the same user. Attackers frequently use proxy infrastructure (VPNs, Tor, residential proxies) to mask their origin when using stolen credentials, and their post-authentication activity often triggers additional detection rules. + +By correlating the proxy alert with other Okta alerts using an EQL sequence, this rule identifies users whose proxy-based authentication was followed by suspicious activity within a 1-hour window. + + +*Possible investigation steps* + +- Identify the affected user and review the correlated security alerts to understand what suspicious activity was detected after the proxy authentication. +- Examine the proxy source IP addresses and cross-reference with threat intelligence feeds for known malicious infrastructure. +- Review the time gap between the proxy authentication and subsequent alert generation. +- Review the user's recent Okta activity for signs of account takeover (MFA changes, new devices, unusual app access). +- Verify with the user whether they intentionally used a proxy or VPN during this session. + + +*False positive analysis* + +- Users who legitimately use VPN services for privacy or remote work may trigger this rule if they also trigger unrelated alerts. +- Security testing or red team exercises using proxy infrastructure combined with testing that triggers alerts. +- Corporate VPN egress points that Okta classifies as proxy infrastructure. + + +*Response and remediation* + +- If account compromise is suspected, immediately revoke all active sessions for the user. +- Reset the user's password and MFA factors. +- Review and revoke any OAuth tokens or API keys associated with the account. +- Block the source proxy IP at the network perimeter if confirmed malicious. +- Review the user's access to sensitive applications and data during the suspicious session. + + +==== Rule query + + +[source, js] +---------------------------------- +sequence by user.name with maxspan=30m + [any where event.dataset == "okta.system" and + kibana.alert.rule.rule_id == "6f1bb4b2-7dc8-11ee-92b2-f661ea17fbcd"] + [any where event.dataset == "okta.system" and + kibana.alert.rule.rule_id != null and + kibana.alert.severity != "low" and + kibana.alert.rule.rule_id not in ( + "6f1bb4b2-7dc8-11ee-92b2-f661ea17fbcd", + "af2d8e4c-3b7c-4e91-8f5a-6c9d0e1f2a3b" + ) + ] + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-22/prebuilt-rules-8-19-22-appendix.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-22/prebuilt-rules-8-19-22-appendix.asciidoc new file mode 100644 index 0000000000..c5c35e0065 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-22/prebuilt-rules-8-19-22-appendix.asciidoc @@ -0,0 +1,12 @@ +["appendix",role="exclude",id="prebuilt-rule-8-19-22-prebuilt-rules-8-19-22-appendix"] += Downloadable rule update v8.19.22 + +This section lists all updates associated with version 8.19.22 of the Fleet integration *Prebuilt Security Detection Rules*. + + +include::prebuilt-rule-8-19-22-multiple-alerts-involving-a-user.asciidoc[] +include::prebuilt-rule-8-19-22-alerts-in-different-att-ck-tactics-by-host.asciidoc[] +include::prebuilt-rule-8-19-22-multiple-alerts-in-same-att-ck-tactic-by-host.asciidoc[] +include::prebuilt-rule-8-19-22-multiple-external-edr-alerts-by-host.asciidoc[] +include::prebuilt-rule-8-19-22-newly-observed-high-severity-detection-alert.asciidoc[] +include::prebuilt-rule-8-19-22-okta-alerts-following-unusual-proxy-authentication.asciidoc[] diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-19-22/prebuilt-rules-8-19-22-summary.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-19-22/prebuilt-rules-8-19-22-summary.asciidoc new file mode 100644 index 0000000000..2f03b9f851 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-19-22/prebuilt-rules-8-19-22-summary.asciidoc @@ -0,0 +1,24 @@ +[[prebuilt-rule-8-19-22-prebuilt-rules-8-19-22-summary]] +[role="xpack"] +== Update v8.19.22 + +This section lists all updates associated with version 8.19.22 of the Fleet integration *Prebuilt Security Detection Rules*. + + +[width="100%",options="header"] +|============================================== +|Rule |Description |Status |Version + +|<> | This rule uses alert data to determine when multiple different alerts involving the same user are triggered. Analysts can use this to prioritize triage and response, as these users are more likely to be compromised. | update | 9 + +|<> | This rule uses alert data to determine when multiple alerts in different phases of an attack involving the same host are triggered and where the accumulated risk score is higher than a defined threshold. Analysts can use this to prioritize triage and response, as these hosts are more likely to be compromised. | update | 5 + +|<> | This rule correlates multiple security alerts associated with the same ATT&CK tactic on a single host within a defined time window. By requiring alerts from multiple distinct detection rules, this detection helps identify hosts exhibiting concentrated malicious behavior, which may indicate an active intrusion or post-compromise activity. The rule is intended to assist analysts in prioritizing triage toward hosts with higher likelihood of compromise rather than signaling a single discrete event. | update | 5 + +|<> | This rule uses alert data to determine when multiple external EDR alerts involving the same host are triggered. Analysts can use this to prioritize triage and response, as these hosts are more likely to be compromised. | update | 5 + +|<> | This rule detects Elastic SIEM high severity detection alerts that are observed for the first time in the previous 5 days of alert history. It highlights low-volume, newly observed alerts tied to a specific detection rule, analysts can use this to prioritize triage and response. | update | 6 + +|<> | Correlates the first occurrence of an Okta user session started via a proxy with subsequent Okta security alerts for the same user. Attackers frequently use proxy infrastructure (VPNs, Tor, residential proxies) to mask their origin when using stolen credentials, and their post-authentication activity often triggers additional detection rules. | update | 3 + +|============================================== diff --git a/docs/detections/prebuilt-rules/prebuilt-rules-downloadable-updates.asciidoc b/docs/detections/prebuilt-rules/prebuilt-rules-downloadable-updates.asciidoc index 1bf8e0b2b8..cb18246813 100644 --- a/docs/detections/prebuilt-rules/prebuilt-rules-downloadable-updates.asciidoc +++ b/docs/detections/prebuilt-rules/prebuilt-rules-downloadable-updates.asciidoc @@ -13,6 +13,10 @@ For previous rule updates, please navigate to the https://www.elastic.co/guide/e |Update version |Date | New rules | Updated rules | Notes +|<> | 29 Apr 2026 | 0 | 6 | +This release fixes ESQL prebuilt rules that broke after the previous release due to unmapped data_stream.dataset on security alert indices. + + |<> | 23 Apr 2026 | 6 | 708 | This release includes new rules for Linux, AWS and Windows. New rules for Linux and Windows include detection for defense evasion. New rules for AWS include detection for initial access. Additionally, significant tuning across multiple data-source rules improves efficacy and performance. @@ -118,3 +122,4 @@ include::downloadable-packages/8-19-18/prebuilt-rules-8-19-18-summary.asciidoc[l include::downloadable-packages/8-19-19/prebuilt-rules-8-19-19-summary.asciidoc[leveloffset=+1] include::downloadable-packages/8-19-20/prebuilt-rules-8-19-20-summary.asciidoc[leveloffset=+1] include::downloadable-packages/8-19-21/prebuilt-rules-8-19-21-summary.asciidoc[leveloffset=+1] +include::downloadable-packages/8-19-22/prebuilt-rules-8-19-22-summary.asciidoc[leveloffset=+1] diff --git a/docs/detections/prebuilt-rules/prebuilt-rules-reference.asciidoc b/docs/detections/prebuilt-rules/prebuilt-rules-reference.asciidoc index a71e518d60..dfb8f684ac 100644 --- a/docs/detections/prebuilt-rules/prebuilt-rules-reference.asciidoc +++ b/docs/detections/prebuilt-rules/prebuilt-rules-reference.asciidoc @@ -324,7 +324,7 @@ and their rule type is `machine_learning`. |<> |This rule uses alert data to determine when multiple alerts from different integrations with unique event categories and involving the same user.name are triggered. Analysts can use this to prioritize triage and response, as these users are more likely to be compromised. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide] |None |3 -|<> |This rule uses alert data to determine when multiple alerts in different phases of an attack involving the same host are triggered and where the accumulated risk score is higher than a defined threshold. Analysts can use this to prioritize triage and response, as these hosts are more likely to be compromised. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide] |None |4 +|<> |This rule uses alert data to determine when multiple alerts in different phases of an attack involving the same host are triggered and where the accumulated risk score is higher than a defined threshold. Analysts can use this to prioritize triage and response, as these hosts are more likely to be compromised. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide] |None |5 |<> |Identifies the creation of an Alternate Data Stream (ADS) at a volume root directory, which can indicate the attempt to hide tools and malware, as ADSs created in this directory are not displayed by system utilities. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: Microsoft Defender XDR], [Data Source: SentinelOne], [Data Source: Elastic Endgame], [Resources: Investigation Guide] |None |205 @@ -1646,11 +1646,11 @@ and their rule type is `machine_learning`. |<> |This rule detects the execution of multiple base64 decoding commands to decode data. multi-decoded data is suspicious, and may be used by attackers to obfuscate malicious payloads or commands. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Execution], [Data Source: Elastic Defend], [Resources: Investigation Guide] |None |3 -|<> |This rule uses alert data to determine when multiple different alerts involving the same user are triggered. Analysts can use this to prioritize triage and response, as these users are more likely to be compromised. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide] |None |8 +|<> |This rule uses alert data to determine when multiple different alerts involving the same user are triggered. Analysts can use this to prioritize triage and response, as these users are more likely to be compromised. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide] |None |9 |<> |This rule uses alert data to determine when multiple alerts in different phases of an attack involving the same host are triggered. Analysts can use this to prioritize triage and response, as these hosts are more likely to be compromised. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide] |None |6 -|<> |This rule correlates multiple security alerts associated with the same ATT&CK tactic on a single host within a defined time window. By requiring alerts from multiple distinct detection rules, this detection helps identify hosts exhibiting concentrated malicious behavior, which may indicate an active intrusion or post-compromise activity. The rule is intended to assist analysts in prioritizing triage toward hosts with higher likelihood of compromise rather than signaling a single discrete event. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide] |None |4 +|<> |This rule correlates multiple security alerts associated with the same ATT&CK tactic on a single host within a defined time window. By requiring alerts from multiple distinct detection rules, this detection helps identify hosts exhibiting concentrated malicious behavior, which may indicate an active intrusion or post-compromise activity. The rule is intended to assist analysts in prioritizing triage toward hosts with higher likelihood of compromise rather than signaling a single discrete event. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide] |None |5 |<> |This rule correlates multiple security alerts from a host exhibiting unusually high CPU utilization within a short time window. This behavior may indicate malicious activity such as malware execution, cryptomining, exploit payload execution, or abuse of system resources following initial compromise. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide], [Domain: Endpoint], [Tactic: Impact] |None |3 @@ -1662,7 +1662,7 @@ and their rule type is `machine_learning`. |<> |Detects multiple Elastic Defend EDR alerts originating from the same process tree, indicating coordinated malicious activity. Analysts can use this to prioritize triage and response, as these hosts are more likely to be compromised. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide], [Data Source: Elastic Defend] |None |2 -|<> |This rule uses alert data to determine when multiple external EDR alerts involving the same host are triggered. Analysts can use this to prioritize triage and response, as these hosts are more likely to be compromised. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide], [Domain: Endpoint] |None |4 +|<> |This rule uses alert data to determine when multiple external EDR alerts involving the same host are triggered. Analysts can use this to prioritize triage and response, as these hosts are more likely to be compromised. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide], [Domain: Endpoint] |None |5 |<> |Identifies multiple logon failures followed by a successful one from the same source address. Adversaries will often brute force login attempts across multiple users with a common or known password, in an attempt to gain access to accounts. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Resources: Investigation Guide], [Data Source: Windows Security Event Logs] |None |116 @@ -1754,7 +1754,7 @@ and their rule type is `machine_learning`. |<> |This rule detects FortiGate alerts that are observed for the first time in the previous 5 days of alert history. Analysts can use this to prioritize triage and response. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide], [Domain: Network], [Data Source: Fortinet] |None |3 -|<> |This rule detects Elastic SIEM high severity detection alerts that are observed for the first time in the previous 5 days of alert history. It highlights low-volume, newly observed alerts tied to a specific detection rule, analysts can use this to prioritize triage and response. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide] |None |5 +|<> |This rule detects Elastic SIEM high severity detection alerts that are observed for the first time in the previous 5 days of alert history. It highlights low-volume, newly observed alerts tied to a specific detection rule, analysts can use this to prioritize triage and response. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide] |None |6 |<> |This rule detects Suricata high severity alerts that are observed for the first time in the previous 5 days of alert history. Analysts can use this to prioritize triage and response. |[Use Case: Threat Detection], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide], [Domain: Network], [Data Source: Suricata] |None |3 @@ -1776,7 +1776,7 @@ and their rule type is `machine_learning`. |<> |Detects potential Adversary-in-the-Middle (AiTM) session cookie replay attacks against Okta. This rule identifies when an Okta session is used from multiple IP addresses or with suspicious non-browser user agents after initial authentication. AiTM attacks capture session cookies via phishing proxies (e.g., Evilginx, Modlishka) and replay them from attacker infrastructure, bypassing MFA. The detection correlates session start events with subsequent policy evaluations or SSO attempts that occur from different IPs or programmatic user agents. |[Domain: Identity], [Use Case: Identity and Access Audit], [Data Source: Okta], [Data Source: Okta System Logs], [Tactic: Credential Access], [Tactic: Lateral Movement], [Resources: Investigation Guide] |None |3 -|<> |Correlates the first occurrence of an Okta user session started via a proxy with subsequent Okta security alerts for the same user. Attackers frequently use proxy infrastructure (VPNs, Tor, residential proxies) to mask their origin when using stolen credentials, and their post-authentication activity often triggers additional detection rules. |[Domain: Identity], [Domain: Cloud], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Data Source: Okta], [Data Source: Okta System Logs], [Tactic: Initial Access], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide] |None |2 +|<> |Correlates the first occurrence of an Okta user session started via a proxy with subsequent Okta security alerts for the same user. Attackers frequently use proxy infrastructure (VPNs, Tor, residential proxies) to mask their origin when using stolen credentials, and their post-authentication activity often triggers additional detection rules. |[Domain: Identity], [Domain: Cloud], [Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Data Source: Okta], [Data Source: Okta System Logs], [Tactic: Initial Access], [Rule Type: Higher-Order Rule], [Resources: Investigation Guide] |None |3 |<> |Detects when Okta FastPass prevents a user from authenticating to a phishing website. |[Tactic: Initial Access], [Use Case: Identity and Access Audit], [Data Source: Okta], [Resources: Investigation Guide] |None |312 diff --git a/docs/detections/prebuilt-rules/rule-details/alerts-in-different-att-ck-tactics-by-host.asciidoc b/docs/detections/prebuilt-rules/rule-details/alerts-in-different-att-ck-tactics-by-host.asciidoc index 6b7b7b4e5c..66fe2779bb 100644 --- a/docs/detections/prebuilt-rules/rule-details/alerts-in-different-att-ck-tactics-by-host.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/alerts-in-different-att-ck-tactics-by-host.asciidoc @@ -25,7 +25,7 @@ This rule uses alert data to determine when multiple alerts in different phases * Rule Type: Higher-Order Rule * Resources: Investigation Guide -*Version*: 4 +*Version*: 5 *Rule authors*: @@ -93,7 +93,7 @@ from .alerts-security.* metadata _id // filter for alerts with populated risk score, excluding threat_match rules, deprecated and some other noisy ones. | where kibana.alert.risk_score > 0 and kibana.alert.rule.name IS NOT NULL and - host.id is not null and data_stream.dataset is not null and + host.id is not null and event.dataset is not null and kibana.alert.rule.type != "threat_match" and // Top noisy influencing rules not kibana.alert.rule.name in ("Agent Spoofing - Mismatched Agent ID", "Compression DLL Loaded by Unusual Process", "Process Termination followed by Deletion", "Suspicious PrintSpooler Service Executable File Creation", "Potential PrintNightmare File Modification") and diff --git a/docs/detections/prebuilt-rules/rule-details/multiple-alerts-in-same-att-ck-tactic-by-host.asciidoc b/docs/detections/prebuilt-rules/rule-details/multiple-alerts-in-same-att-ck-tactic-by-host.asciidoc index a43a1b2b48..20dd778b41 100644 --- a/docs/detections/prebuilt-rules/rule-details/multiple-alerts-in-same-att-ck-tactic-by-host.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/multiple-alerts-in-same-att-ck-tactic-by-host.asciidoc @@ -25,7 +25,7 @@ This rule correlates multiple security alerts associated with the same ATT&CK ta * Rule Type: Higher-Order Rule * Resources: Investigation Guide -*Version*: 4 +*Version*: 5 *Rule authors*: @@ -92,7 +92,7 @@ from .alerts-security.* metadata _id | where kibana.alert.risk_score > 21 and kibana.alert.rule.name IS NOT NULL and - host.id is not null and data_stream.dataset is not null and + host.id is not null and event.dataset is not null and // excluding ML and Threat Match rules as they tend to be noisy not kibana.alert.rule.type in ("threat_match", "machine_learning") and diff --git a/docs/detections/prebuilt-rules/rule-details/multiple-alerts-involving-a-user.asciidoc b/docs/detections/prebuilt-rules/rule-details/multiple-alerts-involving-a-user.asciidoc index 8ad917e738..a644bd25b4 100644 --- a/docs/detections/prebuilt-rules/rule-details/multiple-alerts-involving-a-user.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/multiple-alerts-involving-a-user.asciidoc @@ -25,7 +25,7 @@ This rule uses alert data to determine when multiple different alerts involving * Rule Type: Higher-Order Rule * Resources: Investigation Guide -*Version*: 8 +*Version*: 9 *Rule authors*: @@ -95,26 +95,26 @@ from .alerts-security.* kibana.alert.risk_score > 21 and not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """) | stats - Esql.rule_name_distinct_count = COUNT_DISTINCT(kibana.alert.rule.name), - Esql.rule_id_distinct_count = COUNT_DISTINCT(kibana.alert.rule.rule_id), + Esql.kibana_alert_rule_name_distinct_count = COUNT_DISTINCT(kibana.alert.rule.name), + Esql.kibana_alert_rule_rule_id_distinct_count = COUNT_DISTINCT(kibana.alert.rule.rule_id), Esql.host_id_distinct_count = COUNT_DISTINCT(host.id), - Esql.risk_score_distinct_count = COUNT_DISTINCT(kibana.alert.risk_score), - Esql.data_stream_dataset_distinct_count = COUNT_DISTINCT(data_stream.dataset), - Esql.rule_name_values = VALUES(kibana.alert.rule.name), - Esql.risk_score_values = VALUES(kibana.alert.risk_score), - Esql.data_stream_dataset_values = VALUES(data_stream.dataset), + Esql.kibana_alert_risk_score_distinct_count = COUNT_DISTINCT(kibana.alert.risk_score), + Esql.event_dataset_distinct_count = COUNT_DISTINCT(event.dataset), + Esql.kibana_alert_rule_name_values = VALUES(kibana.alert.rule.name), + Esql.kibana_alert_risk_score_values = VALUES(kibana.alert.risk_score), + Esql.event_dataset_values = VALUES(event.dataset), Esql.event_module_values = VALUES(event.module), - Esql.process_command_line = VALUES(process.command_line), + Esql.process_command_line_values = VALUES(process.command_line), Esql.host_id_values = VALUES(host.id), Esql.source_ip_values = VALUES(source.ip), Esql.destination_ip_values = VALUES(destination.ip) by user.id -| where Esql.rule_name_distinct_count >= 4 AND Esql.rule_id_distinct_count >= 2 and - // Exclude known system accounts with matches in more than one host - not ( - (length(TO_STRING(user.id)) <= 4 or user.id IN ("S-1-5-18", "S-1-5-19", "S-1-5-20", "0")) and - (Esql.host_id_distinct_count >= 2 or Esql.host_id_distinct_count == 0) - ) +| where Esql.kibana_alert_rule_name_distinct_count >= 4 AND Esql.kibana_alert_rule_rule_id_distinct_count >= 2 and + // Exclude known system accounts with matches in more than one host + not ( + (length(TO_STRING(user.id)) <= 4 or user.id IN ("S-1-5-18", "S-1-5-19", "S-1-5-20", "0")) and + (Esql.host_id_distinct_count >= 2 or Esql.host_id_distinct_count == 0) + ) | keep user.id, Esql.* diff --git a/docs/detections/prebuilt-rules/rule-details/multiple-external-edr-alerts-by-host.asciidoc b/docs/detections/prebuilt-rules/rule-details/multiple-external-edr-alerts-by-host.asciidoc index 951fbef56f..4a4671c668 100644 --- a/docs/detections/prebuilt-rules/rule-details/multiple-external-edr-alerts-by-host.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/multiple-external-edr-alerts-by-host.asciidoc @@ -28,7 +28,7 @@ This rule uses alert data to determine when multiple external EDR alerts involvi * Resources: Investigation Guide * Domain: Endpoint -*Version*: 4 +*Version*: 5 *Rule authors*: @@ -92,39 +92,39 @@ Endpoint security technologies monitor and analyze activities on devices to dete [source, js] ---------------------------------- from .alerts-security.* -| WHERE data_stream.dataset in ("crowdstrike.alert", "crowdstrike.falcon", "sentinel_one.alert", "sentinel_one.threat", "m365_defender.alert") and +| WHERE event.dataset in ("crowdstrike.alert", "crowdstrike.falcon", "sentinel_one.alert", "sentinel_one.threat", "m365_defender.alert") and host.id is not null and kibana.alert.risk_score > 21 and not (event.module == "crowdstrike" and (kibana.alert.rule.name like "* at *" or kibana.alert.rule.name like "* on *" or kibana.alert.rule.name == "EICARTestFileWrittenWin")) and not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """) | stats Esql.alerts_count = COUNT(*), - Esql.rule_risk_score_distinct_count = COUNT_DISTINCT(kibana.alert.risk_score), - Esql.unique_rules_count = COUNT_DISTINCT(kibana.alert.rule.name), - Esql.processes_count = COUNT_DISTINCT(process.executable), - Esql.files_count = COUNT_DISTINCT(file.path), - Esql.process_cmdline_count = COUNT_DISTINCT(process.command_line), - Esql.rule_risk_score_values = VALUES(kibana.alert.risk_score), - Esql.process_path_values = VALUES(process.executable), - Esql.file_path_values = VALUES(file.path), - Esql.user_name_values = VALUES(user.name), - Esql.process_command_line_values = VALUES(process.command_line), - Esql.process_parent_command_line_values = VALUES(process.parent.command_line), - Esql.rule_name_values = VALUES(kibana.alert.rule.name) by host.id, host.name, event.module + Esql.kibana_alert_risk_score_distinct_count = COUNT_DISTINCT(kibana.alert.risk_score), + Esql.kibana_alert_rule_name_distinct_count = COUNT_DISTINCT(kibana.alert.rule.name), + Esql.process_executable_distinct_count = COUNT_DISTINCT(process.executable), + Esql.file_path_distinct_count = COUNT_DISTINCT(file.path), + Esql.process_command_line_distinct_count = COUNT_DISTINCT(process.command_line), + Esql.kibana_alert_risk_score_values = VALUES(kibana.alert.risk_score), + Esql.process_executable_values = VALUES(process.executable), + Esql.file_path_values = VALUES(file.path), + Esql.user_name_values = VALUES(user.name), + Esql.process_command_line_values = VALUES(process.command_line), + Esql.process_parent_command_line_values = VALUES(process.parent.command_line), + Esql.kibana_alert_rule_name_values = VALUES(kibana.alert.rule.name) by host.id, host.name, event.module | where ( // 3+ unique rules or processes - ( - Esql.unique_rules_count >= 3 or - (Esql.processes_count >= 3 and Esql.rule_name_values == "External Alerts") - ) and - // and 2+ rules of different severity, or 1 high/critical severity rule - ( - Esql.rule_risk_score_distinct_count >= 2 or - Esql.rule_risk_score_values == 73 or - Esql.rule_risk_score_values == 99 - ) + ( + Esql.kibana_alert_rule_name_distinct_count >= 3 or + (Esql.process_executable_distinct_count >= 3 and Esql.kibana_alert_rule_name_values == "External Alerts") + ) and + // and 2+ rules of different severity, or 1 high/critical severity rule + ( + Esql.kibana_alert_risk_score_distinct_count >= 2 or + Esql.kibana_alert_risk_score_values == 73 or + Esql.kibana_alert_risk_score_values == 99 + ) ) or - // or 5+ unique rules from the same host for 1+ path/command_line/process - (Esql.unique_rules_count >= 5 and Esql.alerts_count <= 50 and - (Esql.files_count >= 1 or Esql.process_cmdline_count >= 1 or Esql.processes_count >= 1) + // or 5+ unique rules from the same host for 1+ path/command_line/process + (Esql.kibana_alert_rule_name_distinct_count >= 5 and Esql.alerts_count <= 50 and + (Esql.file_path_distinct_count >= 1 or Esql.process_command_line_distinct_count >= 1 or Esql.process_executable_distinct_count >= 1) ) | KEEP event.module, host.id, host.name, Esql.* diff --git a/docs/detections/prebuilt-rules/rule-details/newly-observed-high-severity-detection-alert.asciidoc b/docs/detections/prebuilt-rules/rule-details/newly-observed-high-severity-detection-alert.asciidoc index 287ed48cf9..4b2632a2da 100644 --- a/docs/detections/prebuilt-rules/rule-details/newly-observed-high-severity-detection-alert.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/newly-observed-high-severity-detection-alert.asciidoc @@ -27,7 +27,7 @@ This rule detects Elastic SIEM high severity detection alerts that are observed * Rule Type: Higher-Order Rule * Resources: Investigation Guide -*Version*: 5 +*Version*: 6 *Rule authors*: @@ -90,16 +90,15 @@ FROM .alerts-security.* not kibana.alert.rule.type in ("threat_match", "machine_learning", "new_terms") and not kibana.alert.rule.name like "Deprecated - *" and kibana.alert.rule.name != "My First Rule" and // covered by 7306ce7d-5c90-4f42-aa6c-12b0dc2fe3b8 - data_stream.dataset != "endpoint.alerts" and + event.dataset != "endpoint.alerts" and not KQL("""kibana.alert.rule.tags : "Rule Type: Higher-Order Rule" """) | STATS Esql.alerts_count = count(*), Esql.first_time_seen = MIN(@timestamp), Esql.last_time_seen = MAX(@timestamp), Esql.process_executable = VALUES(process.executable), - Esql.cmd_line = VALUES(process.command_line), - Esql.parent_executable = VALUES(process.parent.executable), - Esql.file_path_values = VALUES(file.path), - Esql.file_path_values = VALUES(file.path), + Esql.process_command_line_values = VALUES(process.command_line), + Esql.process_parent_executable_values = VALUES(process.parent.executable), + Esql.file_path_values = VALUES(file.path), Esql.dll_path_values = VALUES(dll.path), Esql.user_id_values = VALUES(user.id), Esql.user_name_values = VALUES(user.name), @@ -107,12 +106,12 @@ FROM .alerts-security.* Esql.host_id_values = VALUES(host.id), Esql.event_module_values = VALUES(event.module), Esql.source_ip_values = VALUES(source.ip), - Esql.rule_name_values = VALUES(kibana.alert.rule.name), - Esql.agents_distinct_count = COUNT_DISTINCT(agent.id) by kibana.alert.rule.name + Esql.kibana_alert_rule_name_values = VALUES(kibana.alert.rule.name), + Esql.agent_id_distinct_count = COUNT_DISTINCT(agent.id) by kibana.alert.rule.name // fist time seen in the last 5 days - defined in the rule schedule Additional look-back time | eval Esql.recent = DATE_DIFF("minute", Esql.first_time_seen, now()) // first time seen is within 10m of the rule execution time -| where Esql.recent <= 10 and Esql.agents_distinct_count == 1 and Esql.alerts_count <= 10 and (Esql.last_time_seen == Esql.first_time_seen) +| where Esql.recent <= 10 and Esql.agent_id_distinct_count == 1 and Esql.alerts_count <= 10 and (Esql.last_time_seen == Esql.first_time_seen) // Move single values to their corresponding ECS fields for alerts exclusion | eval host.id = mv_min(Esql.host_id_values) diff --git a/docs/detections/prebuilt-rules/rule-details/okta-alerts-following-unusual-proxy-authentication.asciidoc b/docs/detections/prebuilt-rules/rule-details/okta-alerts-following-unusual-proxy-authentication.asciidoc index f4ff4d59b3..bee8daf6d7 100644 --- a/docs/detections/prebuilt-rules/rule-details/okta-alerts-following-unusual-proxy-authentication.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/okta-alerts-following-unusual-proxy-authentication.asciidoc @@ -40,7 +40,7 @@ Correlates the first occurrence of an Okta user session started via a proxy with * Rule Type: Higher-Order Rule * Resources: Investigation Guide -*Version*: 2 +*Version*: 3 *Rule authors*: @@ -96,9 +96,9 @@ By correlating the proxy alert with other Okta alerts using an EQL sequence, thi [source, js] ---------------------------------- sequence by user.name with maxspan=30m - [any where data_stream.dataset == "okta.system" and + [any where event.dataset == "okta.system" and kibana.alert.rule.rule_id == "6f1bb4b2-7dc8-11ee-92b2-f661ea17fbcd"] - [any where data_stream.dataset == "okta.system" and + [any where event.dataset == "okta.system" and kibana.alert.rule.rule_id != null and kibana.alert.severity != "low" and kibana.alert.rule.rule_id not in ( diff --git a/docs/index.asciidoc b/docs/index.asciidoc index 7b5e96d751..73a1bb9b89 100644 --- a/docs/index.asciidoc +++ b/docs/index.asciidoc @@ -125,3 +125,5 @@ include::detections/prebuilt-rules/downloadable-packages/8-19-19/prebuilt-rules- include::detections/prebuilt-rules/downloadable-packages/8-19-20/prebuilt-rules-8-19-20-appendix.asciidoc[] include::detections/prebuilt-rules/downloadable-packages/8-19-21/prebuilt-rules-8-19-21-appendix.asciidoc[] + +include::detections/prebuilt-rules/downloadable-packages/8-19-22/prebuilt-rules-8-19-22-appendix.asciidoc[]