* [Rule Tuning][New Rule] AWS S3 Bucket Policy Added to Share with External Account/ to Allow Public Access
AWS S3 Bucket Policy Added to Share with External Account
Low telemetry volume overall, however false positives were seen for cloudfront identity and service accounts being given access to a bucket
- Reduced the scope of this rule to only analyze policy that include account ids or account ARNs (which include an account ID). This eliminates the false positives triggered by sharing buckets with a service account (i.e. cloudtrail.amazonaws.com)
- Excluded cloudfront identity, which should be treated the same way service accounts are being treated and be excluded as they do not include account IDs in their ARN
- This rule wasn't explicitly capturing the use of `Principal: *` which is a public sharing method, often accompanied by a Condition statement (i.e. aws.SourceAccount = OR aws.PrincipalAccount= OR ip.address = ....). The new query will capture Condition statements that include an account id. However there is still a gap for Policies that have explicit `Principal:*` with or without a condition, so another rule was created that will account for these scenarios.
- added highlighted fields
- updated investigation guide and description
- updated Mitre tactics and tags
- `event.type` used in place of `event.category` field
### AWS S3 Bucket Policy Added to Allow Public Access
Rule added to cover gap in public bucket policy added which includes an `Effect=Allow` and `Principal: *`. While an additional condition might be added to this policy which would exclude public access, cases where the condition is not included mean the bucket is publicly accessible. Both cases need to be verified, because even the condition could be giving access to an attacker owned account. There is also the chance that an `Effect=Deny` for `Principal:*` will trigger a false positive for this rule if the same policy also includes an `Effect=Allow` statement. We call this out in the description, false positive and investigation guide sections of the rule.
* [Rule Tunings] AWS Group Creation, User Added to Group, Group Deletion
All 3 rules are showing extremely low telemetry volume as expected. No major changes needed to these queries.
- updated the descriptions, investigation guides and false positive sections
- reduced execution window
- added highlighted fields
* Revert "[Rule Tunings] AWS Group Creation, User Added to Group, Group Deletion"
This reverts commit c66a4f11e1c690a856b1c2f4cbb03077739629d7.
<!--
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/5189
<!--
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
Tunes `Suspicious Entra ID OAuth User Impersonation Scope Detected (9563dace-5822-11f0-b1d3-f661ea17fbcd)` rule to reduce FPs. Please see related issue for more information.
<!--
Summarize your PR. Animated gifs are 💯. Code snippets are ⚡️. Examples & screenshots are 🔥
-->
## How To Test
Query can be used in TRADE stack. TeamFiltration testing and matches occurred in July 2025.
<!--
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)?
*Issue link(s)*:
* https://github.com/elastic/detection-rules/issues/5185
<!--
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 specific detection rule for admin confirmed compromise by Entra ID protection. Relates to BBR rule `Microsoft Entra ID Protection - Risk Detections`. 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 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)?
* [Rule Tuning] AWS User Created Access Key For Another User
Telemetry looks good for this rule, no way to change this from ESQL as we need to be able to compare fields.
- added event.dataset to query
- added source.ip, cloud.account.id, event.dataset, aws.cloudtrail.user_identity.access_key_id, and source.geo.* fields to `keep`
- added to highlighted fields
- updated IG
* toml-lint
* [Rule Tuning][New BBR Rule] AWS Sign-In Token Creation and Console Login
### Tuning - "AWS Signin Single Factor Console Login with Federated User"
Rule scope change and name change to match
- This original rule description suggests that it was designed to capture console login sessions by a Federated User without the use of MFA. However, AWS does not capture MFA usage for Federated Users (only for Root and IAM users). Federated identities will often use 3rd party IDP apps like Okta to enforce MFA, that data is not captured in Cloudtrail. So, the fields `MFAUsed` of `mfaAuthenticated` will always show as False/No in Cloudtrail.
- I changed the scope of this rule to simply capture Console Login by a Federated User. For security reasons this behavior should be correlated with 3rd party IDP data to ensure MFA was established by the identity requesting the Federated Console login. This is very low noise behavior both in telemetry and prod data.
- added highlighted fields
- edited investigation guide to align with scope change
### New BBR
- `GetSigninToken` exchanges existing temporary AWS credentials (e.g., from STS GetFederationToken or AssumeRole) for a short-lived sign-in token that is embedded in a one-click URL to the AWS Management Console.
- ConsoleLogin API often follows a `GetSignInToken` request in normal operations. However, suspicious circumstances like both requests coming from different IPs or geo locations might indicate some form of compromise and should be investigated.
- This BBR rule is created to capture all successful `GetSigninToken` requests for any identity type. It can be used for further correlation with other rules or as an investigative/hunting rule during alert triage.
* adding FederatedUser to query
adding FederatedUser to query
* changed ig title to match rule name
changed ig title to match rule name
* toml-lint
* [Rule Tunings] AWS IAM Administrator Access Policy Attached to Group/Role/User
All 3 rules triggering as expected, low telemetry volume. However, the same rule logic can be applied via EQL so I've changed the rule types for all 3 from ESQL to EQL. To provide better telemetry and alert context for users.
- changed rule type to EQL
- updated all IGs
- added highlighted fields
- added index
* removed double note key
removed double note key
* adding iam event.category
* removed file beat compatibility missing category for AttachRolePolicy
filebeat does not have category mapping for AttachRolePolicy event
* toml-lint
* [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
* [Rule Tuning][Deprecation] AWS Root Console Login Rules
Deprecate - AWS Root Login Without MFA
- Starting deprecation process for this rule. While root login without MFA should certainly be investigated, this rule overlaps with the broader AWS Successful Root Console login rule. Between the 2, the broader rule should remain since all succesful Root console login events should be investigated. Part of the investigation can include determining if MFA was or was not enabled.
Tuning - AWS Management Console Root Login
No major rule changes needed, telemetry is low as expected for this rule
- reduced execution window
- updated investigation guide
- adjusted tags
- added highlighted fields
- added Mitre subtechnique
Tuning - AWS Management Console Brute Force of Root User Identity
No major rule changes needed, telemetry is low as expected for this rule
- reduced execution window
- updated investigation guide
- adjusted tags
- added highlighted field (the only one available for threshold rule is the threshold field)
* adding AWS Sign-In tag
adding AWS Sign-In tag
* [Rule Tunings] AWS Root Password Recovery and Login Profile Created
AWS IAM Password Recovery Requested > AWS Sign-In Root Password Recovery Requested
- Name change to properly indicate the service Sign-In vs IAM which is used for this API call. Also highlights that this is `Root` activity. In AWS, the PasswordRecoveryRequested event from signin.amazonaws.com applies to the root user’s “Forgot your password?” flow. Other identity types, like IAM and federated users, do not generate this event.
- reduced execution window
- updated Investigation Guide
- updated tag
- added highlighted fields
AWS IAM Login Profile Added for Root
- changed rule type from esql to eql
- added index
- reduced execution window
- updated description and investigation guide to clarify emphasis on Root identity scope
- added highlighted fields
* increased severity score
increased severity score since this is related to root
* Update broken link
---------
Co-authored-by: shashank-elastic <91139415+shashank-elastic@users.noreply.github.com>
* Add schema validation for AlertSuppressionMapping
* Add support for indicator match alert suppression
* Add unit tests
* Update order and remove validates_schema method
* Add comments
* Add test for query rule duration only
* [Rule Tuning] AWS S3 Bucket Enumeration or Brute Force
- changed to threshold rule to improve context
- groups alerts by unique combination of `tls.client.server_name`(bucket name), `source.address` (can be either an ip or an internal AWS service address like ), and `aws.cloudtrail.user_identity.type` (this is to prevent capturing double events produced when a user Assumes a role inside another AWS account. This results in the same request being created twice, once as both AssumedRole and AWSAccount identity types)
- uses `event.id` as the cardinality field and counts >= 40
- checks that`tls.client.server_name` exists in the query, this is to prevent capturing denied internal AWS actions that may occur against no particular bucket but against the S3 service itself
- adds highlighted fields
- replaces mitre technique
- replaces more detailed investigation guide including specific details around investigating Threshold rule types via timeline
* kuery language update
* removing extra space
* adding integration
* removing filebeat because of tls.client.server_name
removing filebeat because of tls.client.server_name
* update IG references
updated the references listed in the IG
---------
Co-authored-by: Terrance DeJesus <99630311+terrancedejesus@users.noreply.github.com>
- changed rule from esql to new_terms. While details are limited in telemetry, the noise is evident. We've also gotten complaints about the noise from our own infosec team, prompting this tuning. Changes to a new terms rule will reduce noise by over 90% when tested against prod data.
- This originally only triggered for role chaining within a single AWS account, so excluded common cross-account role assumption. However, I am unable to apply a filter for that with KQL but the benefits to creating new-terms rule outweigh the benefits of keeping that exclusion with esql.
- looks for unique combination of `aws.cloudtrail.user_identity.session_context.session_issuer.arn` (originating role) and `aws.cloudtrail.resources.arn`(target role). Because the only identity type we are concerned with here are `AssumedRole` types, we don't have the same new_terms field limitations as with other rules that also must consider `IAMUser` types. So these fields will suffice.
- added highlighted fields
- added index pattern. rule is compatible with filebeat
- updated the investigation guide and description and description
Note: I may consider creating a broader BBR rule, with the same criteria just not new terms, as a way of capturing all instances of role chaining for investigative purposes
Co-authored-by: Terrance DeJesus <99630311+terrancedejesus@users.noreply.github.com>
* [Rule Tuning] Potential AWS S3 Bucket Ransomware Note Uploaded
- changed this from ESQL to EQL. While initially were only able to isolate uploaded file names using the `aws.cloudtrail.request_parameters` field, we now can use the target.entity.id field to isolate the uploaded file arn. I've adjusted the regex pattern to distinguish between the bucket name and the file uploaded, both of which are included in the target.entity.id field.
- I chose eql instead of esql to 1. provide more meaningful alert context to the user and 2. allow for easier exclusions for the user. Right now these alerts aren't generating much meaningful context.
- edits to description
- new investigation guide using specific AWS IR Ransomware Playbooks as additional context
- additional MITRE technique
* added highlighted fields
added highlighted fields
* fixed MITRE reference
* added cloudtrail index mapping
* Update rules/integrations/aws/impact_s3_bucket_object_uploaded_with_ransom_extension.toml
Co-authored-by: Jonhnathan <26856693+w0rk3r@users.noreply.github.com>
* using aws.cloudtrail.resources.arn instead of target.entity.id
using aws.cloudtrail.resources.arn instead of target.entity.id
* Apply suggestions from code review
---------
Co-authored-by: Jonhnathan <26856693+w0rk3r@users.noreply.github.com>
Co-authored-by: shashank-elastic <91139415+shashank-elastic@users.noreply.github.com>
* [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)?
<!--
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/5183
<!--
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
Tunes the `Azure Entra ID Rare App ID for Principal Authentication` rule to ignore specific first-party client IDs that generate FPs regarding this rule.
<!--
Summarize your PR. Animated gifs are 💯. Code snippets are ⚡️. Examples & screenshots are 🔥
-->
## How To Test
Query can be used in TRADE or telemetry 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)?
* [Tuning] Startup or Run Key Registry Modification
high percentage of the FPs are for programfiles and localappdata files in the registry data string value. This tuning should drop FPs/volume significantly.
* Update rules/windows/persistence_run_key_and_startup_broad.toml
---------
Co-authored-by: Jonhnathan <26856693+w0rk3r@users.noreply.github.com>
* [Rule Tuning] Update Azure / M365 Index Patterns and Lookback Windows
<!--
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/5154
<!--
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
Adjusts Azure / M365 rules regarding lookback windows, interval and index scopes. Please see related issue for more details.
<!--
Summarize your PR. Animated gifs are 💯. Code snippets are ⚡️. Examples & screenshots are 🔥
-->
## How To Test
<!--
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)?
* fixing timestamps
* Update rules/integrations/azure/initial_access_entra_illicit_consent_grant_via_registered_application.toml
Co-authored-by: Isai <59296946+imays11@users.noreply.github.com>
* Update rules/integrations/azure/credential_access_azure_key_vault_excessive_retrieval.toml
Co-authored-by: Jonhnathan <26856693+w0rk3r@users.noreply.github.com>
* update dates
* Update rules/integrations/o365/initial_access_microsoft_365_illicit_consent_grant_via_registered_application.toml
* Update rules/integrations/o365/initial_access_microsoft_365_illicit_consent_grant_via_registered_application.toml
---------
Co-authored-by: Isai <59296946+imays11@users.noreply.github.com>
Co-authored-by: Jonhnathan <26856693+w0rk3r@users.noreply.github.com>
* [Rule Tuning] Update Azure / M365 Mappings
<!--
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/5152
<!--
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
Updates all mappings for Azure / M365 rules for accuracy and missing mappings.
<!--
Summarize your PR. Animated gifs are 💯. Code snippets are ⚡️. Examples & screenshots are 🔥
-->
## How To Test
<!--
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)?
* reverting changes to unit test
* changed webhook rule back to persistence
* Update rules/integrations/azure/persistence_azure_automation_webhook_created.toml
* updated date
* updating date
---------
Co-authored-by: Jonhnathan <26856693+w0rk3r@users.noreply.github.com>
* updating Azure AD Global Administrator Role Assigned
* removed logic changes as it only effects outside of PIM. Adding a different rule for these
* slight change to query
* tuning severity
* Update rules/integrations/azure/persistence_azure_global_administrator_role_assigned.toml
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* Update rules/integrations/azure/persistence_azure_global_administrator_role_assigned.toml
* Update rules/integrations/azure/persistence_azure_global_administrator_role_assigned.toml
---------
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
Isai