* [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>
(cherry picked from commit cee9f51b6d)
* [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>
(cherry picked from commit 42e7f3b4ce)
* [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>
(cherry picked from commit 094f907144)
* [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>
(cherry picked from commit 7221db6b36)
* 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>
(cherry picked from commit 5fff45ec93)
* [Tuning] Suricata and Elastic Defend Network Correlation
Nessus is main source of noise.
* Update command_and_control_suricata_elastic_defend_c2.toml
(cherry picked from commit e2c8c7745d)
* [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)
(cherry picked from commit 4e4559204d)
* [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
(cherry picked from commit 07579f2bd7)
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"
(cherry picked from commit 5f4f9d206f)
- 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
(cherry picked from commit 9e6bf04e82)
Terrance DeJesus