* [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
* Fix rule and mitigate py toml
* Bump patch version
* Add reference to issue
* Add unit test for path issues
* Update comment
* Certain strings were not properly escaped
* Updated to use json instead of repr
* replace _old_dump_str with json.dumps
* Bump Version
* [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>
shashank-elastic