* [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>
* [Rule Tuning] Potential Port Scanning Activity from Compromised Host
* Update rules/linux/discovery_port_scanning_activity_from_compromised_host.toml
* Update port scanning detection query
Refine query to include source IP and limit destination port range.
* Update discovery_port_scanning_activity_from_compromised_host.toml
* Update query in discovery port scanning rule
* Update discovery_port_scanning_activity_from_compromised_host.toml
* Add Required to the Annotation
* Additional required fields
* remove nonempty sting validation
* Required Types via Annotated and Dataclass
* remove space
* Remove inline comment
* Switch to getting a list
* Fix typo and sort
---------
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
<!--
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/5140
<!--
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 missing detection coverage for retrieving Azure Storage Account keys by a user with highly-privileged roles. 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 telemetry visbility.
<!--
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 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 rule Microsoft Entra ID Elevated Access to User Access Administrator
* revert changes
* Added operation name to query logic
* [Rule Tuning] Windows High Severity - 2
* [Rule Tuning] Windows High Severity - 3
* Revert "[Rule Tuning] Windows High Severity - 3"
This reverts commit 32c8348072ab1629e2a164a3579d866b2682f234.
* [Tuning] AWS Access Token Used from Multiple Addresses
Tuning was triggered by a community member
- fixes wildcard and `Pulumi` typos to exclude common IaC tools
- adds exclusion for ``source.as.organization.name` == "AMAZON-02" and aws.cloudtrail.event_category == "Data"` to exclude the noisy multi-IP traffic coming from Amazon-02 networks performing high-throughput data-plane operations. I didn't exclude this network completely because this network can also indicate user-triggered events that are worth keeping in the alert.
- added additional high noise service providers that may be more indicative of console browsing
- added a field for pairing source.ip & network
- added highlighted fields
* Update rules/integrations/aws/initial_access_iam_session_token_used_from_multiple_addresses.toml
* Update rules/integrations/aws/initial_access_iam_session_token_used_from_multiple_addresses.toml
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 Tuning] AWS S3 Unauthenticated Bucket Access by Rare Source
No query changes as this rule is alerting as expected, however I did change the new terms field to be a combination of an IP address and a particular bucket name. Rather than just alerting for the IP address itself. Perhaps an IP is seen retrieving a doc from a public bucket in the environment (expected behavior) but then it also accesses a file in a bucket meant to be private (unexpected behavior). With new terms only on the IP address we would miss the private bucket access.
- added `tls.client.server_name` to new terms field (bucket name)
- reduced execution window
- removed duplicate IG
- added setup note for turning on data events
- small edits to description and highlighted fields
* Update collection_s3_unauthenticated_bucket_access_by_rare_source.toml
* Update collection_s3_unauthenticated_bucket_access_by_rare_source.toml
* Update collection_s3_unauthenticated_bucket_access_by_rare_source.toml
* Update collection_s3_unauthenticated_bucket_access_by_rare_source.toml
* [Rule Tunings] AWS DynamoDB new terms Rules
### AWS DynamoDB Scan by Unusual User
- changed new terms field to use cloud.account.id and user.name combination to account for roles and users
- reduced execution window
- reduced history window
- small edits to description, IG and highlighted fields
### AWS DynamoDB Table Exported to S3
- removed inaccurate setup notes
- reduced history window
- small edits to description and highlighted fields
* Apply suggestions from code review
This rule is performing as expected and low noise in telemetry so no changes to query
- added investigation fields
- small edits to description and IG
- added a reference from Unit42 showing real world threat case
- reduced execution window
Terrance DeJesus