* [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] 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 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)?
AWS SNS is a pub/sub style service where users can subscribe to a topic and receive messages published to that topic. Below is a screenshot of the different protocols a user could subscribe with and the various endpoints that could be associated with those protocols.
AWS SNS Email Subscription by Rare User --> AWS SNS Rare Protocol Subscription by User (not a new rule)
- changed the scope of the rule to capture the first time a user/role subscribes to a topic via a particular protocol (ie. email, http, lambda, mobile). Subscribing to an SNS topic via email is a rather normal behavior and it would be normal for each user to subscribe this way "for the first time" making this rule not as valuable as it was intended to be.
- reduced execution window
- added real-world threat references
- added additional MITRE technique and Impact tag
- small edits to IG and Description
- edited highlighted fields
AWS SNS Topic Message Publish by Rare User
- added AWS to name for consistency
-changed new terms fields to use a combination of cloud.account.id and user.name against the topic itself `aws.cloudtrail.resources.arn`. So that instead of simply evaluating the first time a user/role publishes a message to ANY topic, this rule now looks for the first time a user/role publishes a message to a particular topic. We want to make this distinction to capture the case where an identity responsible for publishing to a particular topic A suddenly starts publishing to another topic B, which indicates behavior that should be verified.
- reduced new terms window
- added setup notes as Data events are necessary for capturing the `Publish` API call
- reduced execution window
- added real-world threat references
- added additional MITRE technique and Impact tag
- small edits to IG and Description
- edited highlighted fields
AWS SNS Topic Created by Rare User
- removed the `AssumedRole` and `*-i*` parameters from the query as this narrowed the query to only alert on behavior from EC2 instance roles. We ideally want to evaluate this behavior for all users and roles.
- reduced execution window
- added real-world threat references
- added additional MITRE technique and Impact tag
- small edits to IG and Description
- edited highlighted fields
* [Rule Tunings] Reduce Usage of Flattened Fields in AWS Rules
This PR is in part a response to the following issues regarding the future of flattened fields in AWS, which we use as an essential part of our ruleset. However, this is also in response to the ongoing ruleset audit. Some of the flattened fields used are not truly necessary for the alert to trigger or can be replaced by a different field. Those changes have been made here and our non_ecs file has been edited to remove the unnecessary fields. Additionally, flattened fields have been removed from highlighted fields, and from investigation guides.
* Update discovery_ec2_userdata_request_for_ec2_instance.toml
updated_date
* Update execution_ssm_sendcommand_by_rare_user.toml
updated_date
* Update non-ecs-schema.json
add necessary field for ModifyInstanceAttribute action
* Update persistence_ec2_security_group_configuration_change_detection.toml
added missing event.action AuthorizeSecurityGroupIngress, narrowed scope for ModifyInstanceAttribute action by adding a necessary flattened_field
* Update privilege_escalation_iam_customer_managed_policy_attached_to_role.toml
updated min_stack_version for new field target.entity.id
* Update privilege_escalation_iam_customer_managed_policy_attached_to_role.toml
* Update privilege_escalation_iam_update_assume_role_policy.toml
updating min_stack to account of target.entity.id field
* Update impact_s3_excessive_object_encryption_with_sse_c.toml
adding highlighted fields
* Update rules/integrations/aws/exfiltration_dynamodb_table_exported_to_s3.toml
* Apply suggestions from code review
---------
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
* new rule Microsoft Entra ID Suspicious Cloud Device Registration
* adjusted backticks in non-ecs and rule
* linted
* adjusted uuid; bumped patch version
* [Rule Tunings] AWS SSM Command Document Created by Rare User
## AWS SSM Command Document Created by Rare User
Rule executes as expected and has very few alerts in telemetry. However, it is one of the rules timing out occasionally.
- reduced execution window
- reduced new terms history window
- replaced wildcards with the flattened field in the query, which should improve performance
- replaced `aws.cloudtrail.user_identity.arn` with combination of `cloud.account.id` and `user.name` to account for Assumed Roles. This will only evaluate the role instead of each individual role session, which will improve performance.
- added investigation fields
- corrected tags
- added mitre technique
## AWS SSM `SendCommand` Execution by Rare User"
- added investigation fields
- added tag
* update pyproject.toml
update pyproject.toml version
* tuning rule Suspicious Microsoft 365 Mail Access by Unusual ClientAppId
* adjusted tactic tag
* updating patch version
* updating patch version
* bumping patch version
* [Rule Tuning] AWS EC2 User Data Retrieval for EC2 Instance
- changed execution window
- explicitly added flattened fields to query, to reduce wildcard usage
- added investigation fields
- changed new terms field to evaluate `user.name` over `aws.cloudtrail.user_identity.arn` so that only the role name for Assumed Role identitites is being evaluated instead of each individual session. This should greatly impact performance as most instances of this rule in telemetry is triggered by Assumed Roles.
* Apply suggestions from code review
* remove instanceId parameter
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
---------
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* [New Rule] AWS CloudTrail Log Evasion
Identifies the evasion of cloudtrail logging for IAM actions involving policy creation, modification or attachment. When making certain policy-related API calls, an adversary may pad the associated policy document with whitespaces to trigger CloudTrail’s logging size constraints, resulting in incomplete logging where critical details about the policy are omitted. By exploiting this gap, threat actors can bypass monitoring performed through CloudTrail and can effectively obscure unauthorized changes. This rule looks for IAM API calls with the requestParameters property containing reason:”requestParameters too large” and omitted:true.
This is a known gap in AWS with no immediate remediation steps. While the size constraint issue affects additional services, IAM policy-related API calls are the only that pose a security risk which is why this rule is scoped specifically to `event.provider: iam.amazonaws.com`. For additional background on the evasion technique refer to Permisso's [research](https://permiso.io/blog/cloudtrail-logging-evasion-where-policy-size-matters).
* aligning IG and rule name
* added investigation fields
added investigation fields
* change severity
* updating pyproject version
* [Rule Tuning] AWS EC2 Deprecated AMI Discovery
Rule triggers as expected
Telemetry shows only known FP risks from tools that are intentionally including deprecated AMIs in their searches (these should be excluded by customers)
- changed the query to reduce use of multiple wildcards
- changed the execution window
- removed unnecessary parts of IG
- added to the highlighted fields
* update non-ecs-schema.json
update non-ecs-schema.json with field "aws.cloudtrail.flattened.request_parameters.ownersSet.items.owner"
* update version in pyproject.toml
update version in pyproject.toml
* Update pyproject.toml
* new rule 'Suspicious Email Access by First-Party Application via Microsoft Graph'
* updated patch version
---------
Co-authored-by: Colson Wilhoit <48036388+DefSecSentinel@users.noreply.github.com>
* tuning 'Azure Service Principal Credentials Added'
* updated patch version
* added investigation guide
* updating patch version
* updating patch version
* tuning 'Microsoft Entra ID Rare Authentication Requirement for Principal User'
* updated MITRE ATT&CK mappings
* updated index target
* updated patch version
* updating patch version
* bumping patch version
* updating patch version
* new rules for AWS DynamoDB data exfiltration
* bumping patch version
* adjusting investigation guide
* updating patch version
* updating patch version
* updating patch version
---------
Co-authored-by: Colson Wilhoit <48036388+DefSecSentinel@users.noreply.github.com>
* rule tuning 'First Occurrence of Entra ID Auth via DeviceCode Protocol'
* bumping patch version
* fixed investigation guide unit test failure
* bump patch
* [Rule Tuning] AWS Monthly Rule Tunings
* Adding several more AWS tunings
* updating patch version
* updating non-ecs type to boolean
* fixed cloudtrail index
* new rule 'AWS EC2 Deprecated AMI Discovery'
* updated type
* updated non-ecs; bumped package version
* updated query
* added missing index
* updated patch version
* adding new rule 'AWS IAM Customer-Managed Policy Attached to Role by Rare User'
* adding investigation guide tag
* adds new hunting query
* updated notes
* changed name
* adjusting pyproject.toml version
* [New Rule] [Rule Tuning] AWS STS AssumeRole with New MFA Device, AWS IAM Deactivation of MFA Device
New terms rule for new MFA device with AssumeRole action. Rule tuning to add MITRE technique to "AWS IAM Deactivation of MFA Device"
* add serialNumber to non-ecs schema file
* fixed misspelled toml file name
* Update rules/integrations/aws/persistence_sts_assume_role_with_new_mfa.toml
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
---------
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
* adding new rule for Okta public client app OAuth token request with client credentials
* Update detection_rules/etc/non-ecs-schema.json
* changing new terms to okta.actor.display_name
* linted; added references
* [Rule BugFix] Google Workspace Oauth2 new app
In our extended testing the changed rule with latest Google Workspace
integration generates the following errors which make the rule fail everytime:
```
unsupported_operation_exception: [wildcard] queries are not currently supported on keyed [flattened] fields.
```
After careful investigation this happens since the field google_workspace.token.scope.data is a flattened
JSON filed that contains one or more key/value pairs and ES does not support wildcard matches withing flattened
fields as the error suggests.
We instead query the whole field (that contains the flattened fields) with the wildcard characters and achieve
the same outcome without the error.
* [Rule BugFix] Google Workspace Oauth2 new app update (#3436)
In our extended testing the changed rule with latest Google Workspace
integration generates the following errors which make the rule fail everytime:
```
unsupported_operation_exception: [wildcard] queries are not currently supported on keyed [flattened] fields.
```
After careful investigation this happens since the field google_workspace.token.scope.data is a flattened
JSON filed that contains one or more key/value pairs and ES does not support wildcard matches withing flattened
fields as the error suggests.
We instead query the whole field (that contains the flattened fields) with the wildcard characters and achieve
the same outcome without the error.
---------
Co-authored-by: Mika Ayenson <Mikaayenson@users.noreply.github.com>
Co-authored-by: Terrance DeJesus <99630311+terrancedejesus@users.noreply.github.com>
* [New Rules] UEBA GItHub BBRs and Rules
A new set of BBRs and rules that will be used to trigger new UEBA GitHub threshold Rules.
* Update rules/integrations/github/impact_github_member_removed_from_organization.toml
* Apply suggestions from code review
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
* edited BBR rules
-removed newly added member rule
* updated integration manifests and schemas
* Updated min_stack for some rules based on newest GitHub integration schema manifest
* testing min_stack bump to 8.8 for new fields
* removing offending rule to troubleshoot seperately
* added UEBA tags and created UEBA threshold rule
* updated non-ecs-schema to add signal.rule.tags
* updated non-ecs-schema with kibana.alert.workflow_status
* updated rule.threat.tactic
* added user.name to non-ecs-schema
* added quotes to kibana.alert.workflow_status value
* removed trailing space from rule name
* update tags and optimize query for UEBA threshold rule
* removed integration field from Higher-Order rule
* Apply suggestions from code review
Co-authored-by: Terrance DeJesus <99630311+terrancedejesus@users.noreply.github.com>
* adjusted new_terms order and rule types based on review feedback
* Apply suggestions from code review
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
* remove user.name from detection_rules/etc/non-ecs-schema.json
* fix json formatting
---------
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
Co-authored-by: Colson Wilhoit <48036388+DefSecSentinel@users.noreply.github.com>
Co-authored-by: Terrance DeJesus <99630311+terrancedejesus@users.noreply.github.com>
Co-authored-by: Justin Ibarra <16747370+brokensound77@users.noreply.github.com>
Co-authored-by: Mika Ayenson <Mikaayenson@users.noreply.github.com>
Samirbous