* Updated kubernetes.audit.requestObject.spec.containers.image type of text to Keyword
* [New Rules] Misc. K8s RBAC Abuse Rules
* --
* Update non-ecs-schema
* Update to make unit tests happy
* Mitre mapping updates
* Fix query logic for service account role bindings
* Fix formatting in persistence_service_account_bound_to_clusterrole rule
* [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] 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>
* [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>
* [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
* [New] Alerts in Different ATT&CK Tactics by Host
Using ES|QL and alerts risk score to identify top risky hosts based on presence of multiple alert touching at least 4 unique tactics in a 24h time Window.
* Update multiple_alerts_risky_host_esql.toml
* Update multiple_alerts_risky_host_esql.toml
* Update multiple_alerts_risky_host_esql.toml
* Update multiple_alerts_risky_host_esql.toml
* Update multiple_alerts_risky_host_esql.toml
* Update non-ecs-schema.json
* ++
* Update multiple_alerts_edr_elastic_defend_by_host.toml
---------
Co-authored-by: shashank-elastic <91139415+shashank-elastic@users.noreply.github.com>
* [New] SOCKS Traffic from an Unusual Process
This detection correlates FortiGate's application control SOCKS events with Elastic Defend network event to identify the
source process performing SOCKS traffic. Adversaries may use a connection proxy to direct network traffic between systems
or act as an intermediary for network communications to a command and control server to avoid direct connections to their
infrastructure.
* Update command_and_control_socks_fortigate_endpoint.toml
* Update command_and_control_socks_fortigate_endpoint.toml
* Update rules/cross-platform/command_and_control_socks_fortigate_endpoint.toml
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
* Update command_and_control_socks_fortigate_endpoint.toml
* add fortinet schema and manif
* Update rules/cross-platform/command_and_control_socks_fortigate_endpoint.toml
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* Update rules/cross-platform/command_and_control_socks_fortigate_endpoint.toml
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* Update pyproject.toml
---------
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* Add alignment checking for sub-queries
* Allow field to be over written with original field
* Update rule prompt to allow for int 0 values
* Support custom schema index overwrite
---------
Co-authored-by: shashank-elastic <91139415+shashank-elastic@users.noreply.github.com>
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* [New Rule] Azure Storage Blob Retrieval via AzCopy with SAS Token
# Pull Request
*Issue link(s)*:
* https://github.com/elastic/detection-rules/issues/5178
<!--
Add Related Issues / PRs for context. Eg:
Related to elastic/repo#999
Resolves#123
If there is no issue link, take extra care to write a clear summary and label the PR just as you would label an issue to give additional context to reviewers.
-->
## Summary - What I changed
Adds detection capabilities for Azure Storage Blob retrieval via AzCopy with SAS tokens. Related to behavior observed by Storm-0501. Please see related issue for more details.
<!--
Summarize your PR. Animated gifs are 💯. Code snippets are ⚡️. Examples & screenshots are 🔥
-->
## How To Test
Query can be used in TRADE stack.
<!--
Some examples of what you could include here are:
* Links to GitHub action results for CI test improvements
* Sample data before/after screenshots (or short videos showing how something works)
* Copy/pasted commands and output from the testing you did in your local terminal window
* If tests run in GitHub, you can 🪁or 🔱, respectively, to indicate tests will run in CI
* Query used in your stack to verify the change
-->
## Checklist
<!-- Delete any items that are not applicable to this PR. -->
- [ ] Added a label for the type of pr: `bug`, `enhancement`, `schema`, `maintenance`, `Rule: New`, `Rule: Deprecation`, `Rule: Tuning`, `Hunt: New`, or `Hunt: Tuning` so guidelines can be generated
- [ ] Added the `meta:rapid-merge` label if planning to merge within 24 hours
- [ ] Secret and sensitive material has been managed correctly
- [ ] Automated testing was updated or added to match the most common scenarios
- [ ] Documentation and comments were added for features that require explanation
## Contributor checklist
- Have you signed the [contributor license agreement](https://www.elastic.co/contributor-agreement)?
- Have you followed the [contributor guidelines](https://github.com/elastic/detection-rules/blob/main/CONTRIBUTING.md)?
* updating non-ecs
* Update rules/integrations/azure/exfiltration_azure_storage_blob_download_azcopy_sas_token.toml
* Update rules/integrations/azure/exfiltration_azure_storage_blob_download_azcopy_sas_token.toml
* [New Rule] Azure RBAC Built-In Administrator Roles Assigned
<!--
Thank you for your interest in and contributing to Detection Rules!
There are a few simple things to check before submitting your pull request
that can help with the review process. You should delete these items
from your submission, but they are here to help bring them to your attention.
-->
# Pull Request
*Issue link(s)*:
* https://github.com/elastic/detection-rules/issues/5108
<!--
Add Related Issues / PRs for context. Eg:
Related to elastic/repo#999
Resolves#123
If there is no issue link, take extra care to write a clear summary and label the PR just as you would label an issue to give additional context to reviewers.
-->
## Summary - What I changed
Adds a new rule for detecting `Azure RBAC Built-In Administrator Roles Assigned` from Azure Activity Logs. Please se issue for more details.
<!--
Summarize your PR. Animated gifs are 💯. Code snippets are ⚡️. Examples & screenshots are 🔥
-->
## How To Test
Query can be used in TRADE serverless stack.
<!--
Some examples of what you could include here are:
* Links to GitHub action results for CI test improvements
* Sample data before/after screenshots (or short videos showing how something works)
* Copy/pasted commands and output from the testing you did in your local terminal window
* If tests run in GitHub, you can 🪁or 🔱, respectively, to indicate tests will run in CI
* Query used in your stack to verify the change
-->
## Checklist
<!-- Delete any items that are not applicable to this PR. -->
- [ ] Added a label for the type of pr: `bug`, `enhancement`, `schema`, `maintenance`, `Rule: New`, `Rule: Deprecation`, `Rule: Tuning`, `Hunt: New`, or `Hunt: Tuning` so guidelines can be generated
- [ ] Added the `meta:rapid-merge` label if planning to merge within 24 hours
- [ ] Secret and sensitive material has been managed correctly
- [ ] Automated testing was updated or added to match the most common scenarios
- [ ] Documentation and comments were added for features that require explanation
## Contributor checklist
- Have you signed the [contributor license agreement](https://www.elastic.co/contributor-agreement)?
- Have you followed the [contributor guidelines](https://github.com/elastic/detection-rules/blob/main/CONTRIBUTING.md)?
* fixed query logic
* fixed query logc
* fixed query logic
* adding field to non-ecs
* updated UUID
<!--
Thank you for your interest in and contributing to Detection Rules!
There are a few simple things to check before submitting your pull request
that can help with the review process. You should delete these items
from your submission, but they are here to help bring them to your attention.
-->
# Pull Request
*Issue link(s)*:
* https://github.com/elastic/detection-rules/issues/5138
<!--
Add Related Issues / PRs for context. Eg:
Related to elastic/repo#999
Resolves#123
If there is no issue link, take extra care to write a clear summary and label the PR just as you would label an issue to give additional context to reviewers.
-->
## Summary - What I changed
Adds a missing detection for Azure storage account updates that enabled Blob Storage public access. **Please see the related issue for more details.**
<!--
Summarize your PR. Animated gifs are 💯. Code snippets are ⚡️. Examples & screenshots are 🔥
-->
## How To Test
Query can be used in TRADE stack for example data.
<!--
Some examples of what you could include here are:
* Links to GitHub action results for CI test improvements
* Sample data before/after screenshots (or short videos showing how something works)
* Copy/pasted commands and output from the testing you did in your local terminal window
* If tests run in GitHub, you can 🪁or 🔱, respectively, to indicate tests will run in CI
* Query used in your stack to verify the change
-->
## Checklist
<!-- Delete any items that are not applicable to this PR. -->
- [ ] Added a label for the type of pr: `bug`, `enhancement`, `schema`, `maintenance`, `Rule: New`, `Rule: Deprecation`, `Rule: Tuning`, `Hunt: New`, or `Hunt: Tuning` so guidelines can be generated
- [ ] Added the `meta:rapid-merge` label if planning to merge within 24 hours
- [ ] Secret and sensitive material has been managed correctly
- [ ] Automated testing was updated or added to match the most common scenarios
- [ ] Documentation and comments were added for features that require explanation
## Contributor checklist
- Have you signed the [contributor license agreement](https://www.elastic.co/contributor-agreement)?
- Have you followed the [contributor guidelines](https://github.com/elastic/detection-rules/blob/main/CONTRIBUTING.md)?
Terrance DeJesus