* [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] Potential Ransomware Behavior - Note Files by System
added host.id and removed noisy patterns (writes to non C drive)
* Update impact_high_freq_file_renames_by_kernel.toml
* Apply suggestion from @Mikaayenson
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* Update impact_high_freq_file_renames_by_kernel.toml
---------
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* Added logic to main.py to use the created_at and updated_at values from the ndjson file if they exist.
* Add comment for parsing created_at and updated_at fields to metadata
* updated the date metadata code based on PR feedback
* Add --dates-import option to rule import command
Introduce a new option `--dates-import` to parse `created_at` and `updated_at` fields from rule content. This allows users to import date metadata while preventing conflicts with existing date options.
* Update version to 1.5.23 for release preparation
This update increments the version number in the project metadata
to reflect the upcoming release. No other changes were made.
* Update date metadata logic to include timezone information
Modified the handling of creation and updated dates to ensure
that the datetime objects are timezone-aware by replacing the
timezone info with UTC. This change improves the accuracy of
date metadata in the rules.
* Updated format of main.py using ruff
* Update project version to 1.5.29
* updating pyproject version
---------
Co-authored-by: Sergey Polzunov <traut@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
* [Rule Tunings] AWS removal of target.entity.id and actor.entity.id fields
Related Issue : - https://github.com/elastic/security-team/issues/14019
`target.entity.id` and `related.entity.id` fields will soon be fully removed from the AWS Integration. This rule tuning replaces rule queries that relied on `target.entity.id` with the equivalent field `entity.target.id` which was introduced with AWS version 4.7.0 along with several new entity classification fields. This tuning also removes references to these fields in highlighted fields and investigation guides for several rules.
* update data for defense_evasion_route53_dns_query_resolver_config_deletion.toml
update data for defense_evasion_route53_dns_query_resolver_config_deletion.toml
* updated_dates
* [Rule Tunings] AWS remove target.entity.id and actor.entity.id fields
adding min_stack to rules using the field `entity.target.id`, we determined AWS version 4.7.0 is compatible with Kibana versions '^8.19.4 || ^9.1.4'. We reverted the initial PR and this one adds the min_stack_version.
Original PR: - https://github.com/elastic/detection-rules/pull/5563
______
### Issue Link
- https://github.com/elastic/ia-trade-team/issues/781
## Summary - What I changed
`target.entity.id` and `actor.entity.id` fields will soon be fully removed from the AWS Integration. This rule tuning replaces rule queries that relied on `target.entity.id` with the equivalent field `entity.target.id` which was introduced with AWS version 4.7.0 along with several new entity classification fields. This tuning also removes references to these fields in highlighted fields and investigation guides for several rules.
<img width="1622" height="1488" alt="image" src="https://github.com/user-attachments/assets/024fbdb2-c0e4-4785-9735-5285218e4fa9" />
## Rules with Query Changes
**AWS IAM Customer-Managed Policy Attached to Role by Rare User
AWS IAM Assume Role Policy Update**
Both of these rules relied on `target.entity.id` as a new terms field, this field has been replaced with `entity.target.id` field which is populating the same value for the event.actions these rules trigger on, as shown in the screenshot below.
<img width="1600" height="445" alt="Screenshot 2026-01-15 at 12 13 17 PM" src="https://github.com/user-attachments/assets/27e482fe-2a09-4dfb-8337-2e5070422183" />
## How To Test
- recent test data is in our stack for the 2 rules that have changes to their new terms values.
- test scripts for each:
- [trigger_privilege_escalation_iam_customer_managed_policy_attached_to_role.py](https://github.com/elastic/elastic-aws-ruleset-testing/blob/main/IAM/trigger_privilege_escalation_iam_customer_managed_policy_attached_to_role.py)
- [trigger_privilege_escalation_update_assume_role_policy.py](https://github.com/elastic/elastic-aws-ruleset-testing/blob/main/IAM/trigger_privilege_escalation_update_assume_role_policy.py)
* [Rule Tunings] AWS removal of target.entity.id and actor.entity.id fields
Related Issue : - https://github.com/elastic/security-team/issues/14019
`target.entity.id` and `related.entity.id` fields will soon be fully removed from the AWS Integration. This rule tuning replaces rule queries that relied on `target.entity.id` with the equivalent field `entity.target.id` which was introduced with AWS version 4.7.0 along with several new entity classification fields. This tuning also removes references to these fields in highlighted fields and investigation guides for several rules.
* update data for defense_evasion_route53_dns_query_resolver_config_deletion.toml
update data for defense_evasion_route53_dns_query_resolver_config_deletion.toml
* updated_dates
Completing the Deprecation process for these rules as they have been shipped at least 2 release cycles with "Deprecated - " prefix.
All have the following metadata changes
maturity = "deprecated"
updated_date = "2026/01/16"
deprecation_date = "2026/01/16"
- Removing the genAI disclaimer for the AWS ruleset Investigation guides which were all manually modified during the most recent audit.
- Removing any numbering in the investigation guides to maintain better consistency across guides
- Fixed any spacing inconsistencies
* Docs: improve WinRAR/7-Zip encrypted archive rule guidance
Clarifies the rule description and expands investigation and false positive guidance
to help analysts distinguish data staging for exfiltration from common benign
administrative and backup workflows. No detection logic or query changes.
* Update rules/windows/collection_winrar_encryption.toml
* Change updated_date to 2026/01/12
Bump update_date
---------
Co-authored-by: Jonhnathan <26856693+w0rk3r@users.noreply.github.com>
* [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>
Eric Forte