* [New] FortiGate SSL VPN Login Followed by SIEM Alert by User
Detects when a FortiGate SSL VPN login event is followed by any SIEM detection alert for the same user name within a short time window. This correlation can indicate abuse of VPN access for malicious activity, credential compromise used from a VPN session, or initial access via VPN followed by post-compromise behavior.
* Update initial_access_fortigate_ssl_vpn_login_followed_by_siem_alert.toml
* Update initial_access_fortigate_ssl_vpn_login_followed_by_siem_alert.toml
* Update initial_access_fortigate_ssl_vpn_login_followed_by_siem_alert.toml
* [New] Correlated Alerts on Similar User Identities
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.
* Update multiple_alerts_llm_by_user_entity.toml
* Update multiple_alerts_llm_by_user_entity.toml
* Update multiple_alerts_llm_by_user_entity.toml
* Update multiple_alerts_llm_by_user_entity.toml
* Update rules/cross-platform/multiple_alerts_llm_by_user_entity.toml
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* Update multiple_alerts_llm_by_user_entity.toml
* Apply suggestion from @terrancedejesus
Co-authored-by: Terrance DeJesus <99630311+terrancedejesus@users.noreply.github.com>
* Update multiple_alerts_llm_by_user_entity.toml
---------
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
Co-authored-by: Terrance DeJesus <99630311+terrancedejesus@users.noreply.github.com>
* [New] Multiple Rare Elastic Defend Behavior Rules by Host
Identifies hosts that triggered multiple distinct Elastic Defend behavior rules, while reducing false positives by
considering only behavior rules that appear on a single host globally (via INLINE STATS). Hosts with two or more
such rare behavior rules are more likely to be compromised and warrant prioritized triage.
* Update multiple_elastic_defend_behavior_rules_same_host_prevalence.toml
* Update multiple_elastic_defend_behavior_rules_same_host_prevalence.toml
* Update multiple_elastic_defend_behavior_rules_same_host_prevalence.toml
* Update multiple_elastic_defend_behavior_rules_same_host_prevalence.toml
* Update multiple_elastic_defend_behavior_rules_same_host_prevalence.toml
---------
Co-authored-by: Colson Wilhoit <48036388+DefSecSentinel@users.noreply.github.com>
* [Tuning] High Order Rules fine tuning
- Exclude High Order Rules as input by other HORs to avoid recursive alerting.
- Adjusted the rule name for one rule.
- FTS Detection rule using ES|QL - moved the `Esql.rule_name_values = VALUES(kibana.alert.rule.name)` to preserve the original alert name (it get confused with the HOR alert name).
* Update impact_alert_from_a_process_with_cpu_spike.toml
* Update command_and_control_socks_fortigate_endpoint.toml
* Update lateral_movement_multi_alerts_new_srcip.toml
* ++
* Update impact_alerts_on_host_with_cpu_spike.toml
* Update multiple_alerts_by_host_ip_and_source_ip.toml
* Update multiple_alerts_from_different_modules_by_user.toml
* [Tuning] Adds host metadata to the setup requirements
Rules requiring host.ip and that are compatible with Elastic Defend integration can be impacting by windows].advanced.set_extended_host_information if set to the default value (false), host.ip won't be populated from 8.18+ (only host.name and host.os and host.id).
Related SDH https://github.com/elastic/sdh-endpoint/issues/722
* ++
* Update rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_process_args.toml
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* Update rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_session_duration.toml
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* Update rules/integrations/lmd/lateral_movement_ml_high_remote_file_size.toml
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* Update rules/integrations/lmd/lateral_movement_ml_high_variance_rdp_session_duration.toml
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* Update rules/integrations/lmd/lateral_movement_ml_rare_remote_file_directory.toml
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* Update rules/integrations/lmd/lateral_movement_ml_unusual_time_for_an_rdp_session.toml
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* Update rules/integrations/lmd/lateral_movement_ml_spike_in_connections_from_a_source_ip.toml
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* Update rules/integrations/lmd/lateral_movement_ml_rare_remote_file_extension.toml
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* Update rules/integrations/lmd/lateral_movement_ml_spike_in_connections_to_a_destination_ip.toml
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* Update lateral_movement_ml_spike_in_rdp_processes.toml
* Apply suggestion from @Mikaayenson
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
---------
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* [New] Elastic Defend Alert Followed by Telemetry Loss
Detects when an Elastic Defend endpoint alert is generated on a host and is not followed by any subsequent endpoint
telemetry (process, network, registry, library, or DNS events) within a short time window. This behavior may indicate
endpoint security evasion, agent tampering, sensor disablement, service termination, system crash, or malicious interference with telemetry collection following detection.
* Update defense_evasion_missing_events_after_alert.toml
* Apply suggestion from @Mikaayenson
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
---------
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* Updated kubernetes.audit.requestObject.spec.containers.image type of text to Keyword
* [Rule Tuning] Dormant & Deprecated Rule Clean-Up
* [Rule Tuning] Dormant & Deprecated Rule Clean-Up
* Few more deprecations
* ++
* Update unit test syntax fix
* Update bad bytes
* ++
* [New] Multiple Machine Learning Alerts by Influencer Field
This rule uses alerts data to determine when multiple different machine learning alerts involving the same influencer field are triggered. Analysts can use this to prioritize triage and response, as these entities are more likely to be more suspicious.
* Update multiple_machine_learning_jobs_by_entity.toml
* Update multiple_machine_learning_jobs_by_entity.toml
* Update non-ecs-schema.json
* Update multiple_machine_learning_jobs_by_entity.toml
* Update non-ecs-schema.json
* [New] Newly Observed Process Exhibiting CPU Spike
This rule alerts on processes exhibiting CPU spike and that are observed for the first time in the previous 5 days. This behavior may indicate performance issues as well as potential suspicious software like cryptomining or exploit abusing system resources following compromise.
* Update impact_newly_observed_process_with_high_cpu.toml
* Update impact_newly_observed_process_with_high_cpu.toml
* Update impact_newly_observed_process_with_high_cpu.toml
* Update impact_newly_observed_process_with_high_cpu.toml
* Update rules/cross-platform/impact_newly_observed_process_with_high_cpu.toml
Co-authored-by: Jonhnathan <26856693+w0rk3r@users.noreply.github.com>
* Update impact_newly_observed_process_with_high_cpu.toml
* Update impact_newly_observed_process_with_high_cpu.toml
* Update impact_newly_observed_process_with_high_cpu.toml
---------
Co-authored-by: Jonhnathan <26856693+w0rk3r@users.noreply.github.com>
* [New] Multiple Alerts on a Host Exhibiting CPU Spike
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.
* Update multiple_alerts_on_host_with_cpu_spike.toml
* Rename multiple_alerts_on_host_with_cpu_spike.toml to impact_alerts_on_host_with_cpu_spike.toml
* Update impact_alerts_on_host_with_cpu_spike.toml
* Update rules/cross-platform/impact_alerts_on_host_with_cpu_spike.toml
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* Update non-ecs-schema.json
---------
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* [New] Detection Alert on a Process Exhibiting CPU Spike
This rule correlates security alerts with processes exhibiting unusually high CPU utilization on the same host and process ID 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.
* Update securityt_alert_from_a_process_with_cpu_spike.toml
* Update securityt_alert_from_a_process_with_cpu_spike.toml
* Update rules/cross-platform/securityt_alert_from_a_process_with_cpu_spike.toml
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* Rename securityt_alert_from_a_process_with_cpu_spike.toml to security_alert_from_a_process_with_cpu_spike.toml
* Update security_alert_from_a_process_with_cpu_spike.toml
* Rename security_alert_from_a_process_with_cpu_spike.toml to impact_alert_from_a_process_with_cpu_spike.toml
* Update impact_alert_from_a_process_with_cpu_spike.toml
* Update non-ecs-schema.json
* Update rules/cross-platform/impact_alert_from_a_process_with_cpu_spike.toml
Co-authored-by: Eric Forte <119343520+eric-forte-elastic@users.noreply.github.com>
---------
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
Co-authored-by: Eric Forte <119343520+eric-forte-elastic@users.noreply.github.com>
* [Tuning] Suricata and Elastic Defend Network Correlation
Nessus is main source of noise.
* Update command_and_control_suricata_elastic_defend_c2.toml
* [New] Multiple Alerts in Same ATT&CK Tactic by Host
This rule uses alert data to determine when multiple alerts in the same phase 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.
* Update multiple_alerts_same_tactic_by_host.toml
* Update rules/cross-platform/multiple_alerts_same_tactic_by_host.toml
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
* Update non-ecs-schema.json
* Update multiple_alerts_same_tactic_by_host.toml
---------
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
* [New] 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.
* Update multiple_external_edr_alerts_by_host.toml
* Update multiple_external_edr_alerts_by_host.toml
* Update multiple_external_edr_alerts_by_host.toml
* Update multiple_external_edr_alerts_by_host.toml
* Update multiple_external_edr_alerts_by_host.toml
* Update multiple_external_edr_alerts_by_host.toml
* Update multiple_external_edr_alerts_by_host.toml
* Update multiple_external_edr_alerts_by_host.toml
* Update multiple_external_edr_alerts_by_host.toml
* Update multiple_external_edr_alerts_by_host.toml
* Update multiple_external_edr_alerts_by_host.toml
* Update multiple_external_edr_alerts_by_host.toml
* Update multiple_external_edr_alerts_by_host.toml
* [New] Suspected Lateral Movement from Compromised Host
Detects potential lateral movement or post-compromise activity by correlating alerts where the host.ip of one alert matches the source.ip of a subsequent alert. This behavior may indicate a compromised host being used to authenticate to another system or resource, including cloud services.
* Update multiple_alerts_by_host_ip_and_source_ip.toml
* Update multiple_alerts_by_host_ip_and_source_ip.toml
* Update multiple_alerts_by_host_ip_and_source_ip.toml
* Update multiple_alerts_by_host_ip_and_source_ip.toml
---------
Co-authored-by: Colson Wilhoit <48036388+DefSecSentinel@users.noreply.github.com>
* [New] Multiple Elastic Defend Alerts from Single Process Tree
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.
* Update multiple_alerts_edr_elastic_same_process_tree.toml
* Update rules/cross-platform/multiple_alerts_edr_elastic_same_process_tree.toml
Co-authored-by: Jonhnathan <26856693+w0rk3r@users.noreply.github.com>
* Update rules/cross-platform/multiple_alerts_edr_elastic_same_process_tree.toml
Co-authored-by: Jonhnathan <26856693+w0rk3r@users.noreply.github.com>
* Update rules/cross-platform/multiple_alerts_edr_elastic_same_process_tree.toml
Co-authored-by: Jonhnathan <26856693+w0rk3r@users.noreply.github.com>
* Update multiple_alerts_edr_elastic_same_process_tree.toml
* Update multiple_alerts_edr_elastic_same_process_tree.toml
* Update multiple_alerts_edr_elastic_same_process_tree.toml
---------
Co-authored-by: Jonhnathan <26856693+w0rk3r@users.noreply.github.com>
* [Tuning] Elastic Defend and Email Alerts Correlation
this rule uses the logs-* generic index, which causes failures on clusters without an email related integration with `destination.user.name` populated. for now limiting the rule to checkpoint email security and we can add more or users can customize it by adding more indexes.
* add checkpoint_email manifest and schema
* Update pyproject.toml
* Update multiple_alerts_email_elastic_defend_correlation.toml
Samirbous