<!--
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
* [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
* [Rule Tuning] SSM Session Started to EC2 Instance
Role/role session noise seen in telemetry due to new fields term using `aws.cloudtrail.user_identity.arn`, which is unique for each role session and does not isolate the role itself.
- new fields term change to `cloud.account.id` and `user.name` combination to account for both IAMUsers and Roles across multiple accounts.
- added AWS to the rule name
- reduced execution window
- small edits to description and IG
- added reference from IG to Reference section
* adding highlighted fields
* added EC2 tag
* Update lateral_movement_aws_ssm_start_session_to_ec2_instance.toml
* Apply suggestions from code review
* [Rule Tunings] AWS Route Table Created / AWS EC2 Route Table Modified or Deleted
AWS Route Table Created
- turned this into a new_terms rule to reduce noise and be more indicative of potential malicious behavior. Used `cloud.account.id`, `user.name` combination to account for both roles and users doing this behavior for the first time.
- changed execution interval
- changed the name to add EC2
- slight adjustments to IG and description
- fixed tagging error
- added investigation fields
AWS EC2 Route Table Modified or Deleted
- replaced new terms field to `cloud.account.id`, `user.name` combination to account for both roles and users doing this behavior for the first time.
- removed the exclusions from this rule. These exclusions, while meant to reduce noise caused by automation tools, actually just provide an easy bypass. A user can simply use CloudFormation to perform the exact same behaviors and avoid detection. I've shown this in the screenshot below, I ran a nearly identical script, one with and one without using CloudFormation. While `source.address` is `cloudformation.amazonaws.com` the behavior was still performed by an IAMUser and should still be evaluated. The fact that this is a new terms rule will reduce the risk of noise due to automation using these tools.
- changed execution interval
- slight adjustments to IG and description
- added investigation fields
* Update persistence_route_table_created.toml
* Update rules/integrations/aws/persistence_ec2_route_table_modified_or_deleted.toml
- query change : I chose to replace `aws.cloudtrail.user_identity.arn` with `user.id` and a more accurate wildcard pattern. This will reduce the chances of this rule triggering for role sessions outside of those started by EC2 instances. The wildcard pattern looks for a role session name that starts with `i-` this is because when an EC2 instance operates using it's attached Role (instance profile), the session name attached to that role name is the instance id (`i-......`). The `user.id` field appends this session name to the role name via a standard pattern `:[session_name]`, making it a more reliable field to use in this case.
- small edits to description and IG
- reduced execution window
- reduced history window
- edited highlighted fields
Note: the new_terms field here remains `aws.cloudtrail.user_identity.arn` because we are only interested in assumed roles, and even more particular, only those used by an EC2 instance. This means we want to evaluate each individual instance's behavior rather than the broader behavior of the role itself. The arn field will capture each instance id (session name) alongside the role itself.
* adding new rule 'Threat Intelligence Signal - Microsoft Defender for Office 365'
* added mitre mapping
* Update rules/integrations/o365/initial_access_defender_for_m365_threat_intelligence_signal.toml
Co-authored-by: Isai <59296946+imays11@users.noreply.github.com>
* added note for max signals
* linted
* fixed unit test failure
---------
Co-authored-by: Isai <59296946+imays11@users.noreply.github.com>
* tuning rule 'Multi-Factor Authentication Disabled for User'
* adjusted query logic
* fixed query logic for optimization that passes unit tests; changed severity and risk back to medium
Rule is executing as expected, however it is alerting on failed requests. Low alert telemetry.
This tuning:
- removed markdown and edited description to be more specific
- reduced execution window for 1 min lookback
- name change to add `AWS` consistent with all other rules
- added references that reflect in the wild threats and persistence usage
- increased risk_score and severity to medium accounting for usage as persistence mechanism in the wild
- added Persistence tag and Mitre tactic, technique, subtechnique
- added `event.outcome: success` criteria to query
- edited investigation guide to be more accurate reflection of steps required for investigating alert, including appropriate response action
- added highlighted fields
** Note: only IAMUser and Root user identities can call this actions so we can use `aws.cloudtrail.user_identity.arn` as the new terms field without worrying about Role vs Role + Session issue seen with other new_terms rules
* [Tuning] First Time AWS Cloudformation Stack Creation by User
- corrected a creation_date error
- Removed `CreateStackSet` API call as this only creates a blueprint for creating stack instances across multiple AWS accounts and regions but does not actually create the resources
- Added `CreateStackInstances` API call which is used to create resources defined in the StackSet
- removed user from rule name as this also triggers for roles
- edited description and investigation guide
- added Mitre technique
* adding highlighted fields
This rule is evaluating the "new terms" against every individual role session, rather than against the Role itself. This is causing a massive volume of alerts
- updated rule description and investigation guide
- reduced execution window and interval
- replaced new terms from `user.id` to combination of `cloud.account.id` and `user.name` to account for evaluation against Roles and in the event that separate AWS accounts under the same Org reuse IAM user names. This will only evaluate the Role instead of each individual role session, which should greatly improve performance.
* [Rule Tuning] AWS STS GetCallerIdentity API Called for the First Time
Rule is executing as expected with no troubling alerts in telemetry. For tuning I've:
- reduced the execution window
- removed MD from description and FP as it's not supported in Kibana UI
- edited some of the language of IG to speak about the exclusion of AssumedRoles
- edited the highlighted fields for consistency across AWS rules
* updated broken link
updated broken reference link
* [Rule Tuning] AWS STS AssumeRole with New MFA Device
This rule is triggering as expected and low volume of alerts in telemetry. This tuning:
- slight edits to IG
- removed user.id wildcard usage in query as this field always exists for these events
- added the from and interval fields for consistency across rules (they are currently using the same values by default so no real change here)
* adding investigation fields
adding investigation fields
* [Tuning] SDH - Investigating MFA Deactivation with no Re-Activation for Okta User Account
This tuning addresses SDH ticket by:
- replacing sequence by `okta.actor.id` with `okta.target.id` in query. This will ensure the deactivation and activation attempts are measured against the target entity. To account for instances where separate users (okta.actor.id) perform deactivation and activation actions against the same target account (okta.target.id)
- Adjusts the investigation guide to use correct target vs. actor fields
* add actor and target id fields to investigation guide
Co-authored-by: Terrance DeJesus <99630311+terrancedejesus@users.noreply.github.com>
---------
Co-authored-by: Terrance DeJesus <99630311+terrancedejesus@users.noreply.github.com>
* adjusted Potential Widespread Malware Infection Across Multiple Hosts
* adjusted Microsoft Azure or Mail Sign-in from a Suspicious Source
* adjusted AWS EC2 Multi-Region DescribeInstances API Calls
* adjusted AWS Discovery API Calls via CLI from a Single Resource
* adjusted AWS Service Quotas Multi-Region Requests
* adjusted AWS EC2 EBS Snapshot Shared or Made Public
* adjusted AWS S3 Bucket Enumeration or Brute Force
* adjusted AWS EC2 EBS Snapshot Access Removed
* adjusted Potential AWS S3 Bucket Ransomware Note Uploaded
* adjusted AWS S3 Object Encryption Using External KMS Key
* adjusted AWS S3 Static Site JavaScript File Uploaded
* adjusted AWS Access Token Used from Multiple Addresses
* adjusted AWS Signin Single Factor Console Login with Federated User
* adjusted AWS IAM AdministratorAccess Policy Attached to Group
* adjusted AWS IAM AdministratorAccess Policy Attached to Role
* adjusted AWS IAM AdministratorAccess Policy Attached to User
* adjusted AWS Bedrock Invocations without Guardrails Detected by a Single User Over a Session
* adjusted AWS Bedrock Guardrails Detected Multiple Violations by a Single User Over a Session
* adjusted AWS Bedrock Guardrails Detected Multiple Policy Violations Within a Single Blocked Request
* adjusted Unusual High Confidence Content Filter Blocks Detected
* adjusted Potential Abuse of Resources by High Token Count and Large Response Sizes
* AWS Bedrock Detected Multiple Attempts to use Denied Models by a Single User
* Unusual High Denied Sensitive Information Policy Blocks Detected
* adjusted Unusual High Denied Topic Blocks Detected
* adjusted AWS Bedrock Detected Multiple Validation Exception Errors by a Single User
* adjusted Unusual High Word Policy Blocks Detected
* adjusted Microsoft Entra ID Concurrent Sign-Ins with Suspicious Properties
* adjusted Azure Entra MFA TOTP Brute Force Attempts
* adjusted Microsoft Entra ID Sign-In Brute Force Activity
* adjusted Microsoft Entra ID Exccessive Account Lockouts Detected
* adjusted Microsoft 365 Brute Force via Entra ID Sign-Ins
* deprecated Azure Entra Sign-in Brute Force Microsoft 365 Accounts by Repeat Source
* adjusted Microsoft Entra ID Session Reuse with Suspicious Graph Access
* adjusted Suspicious Microsoft OAuth Flow via Auth Broker to DRS
* adjusted Potential Denial of Azure OpenAI ML Service
* adjusted Azure OpenAI Insecure Output Handling
* adjusted Potential Azure OpenAI Model Theft
* adjusted M365 OneDrive Excessive File Downloads with OAuth Token
* adjusted Multiple Microsoft 365 User Account Lockouts in Short Time Window
* adjusted Potential Microsoft 365 User Account Brute Force
* adjusted Suspicious Microsoft 365 UserLoggedIn via OAuth Code
* adjusted Multiple Device Token Hashes for Single Okta Session
* adjusted Multiple Okta User Authentication Events with Client Address
* adjusted Multiple Okta User Authentication Events with Same Device Token Hash
* adjusted High Number of Okta Device Token Cookies Generated for Authentication
* adjusted Okta User Sessions Started from Different Geolocations
* adjusted High Number of Egress Network Connections from Unusual Executable
* adjusted Unusual Base64 Encoding/Decoding Activity
* adjusted Potential Port Scanning Activity from Compromised Host
* adjusted Potential Subnet Scanning Activity from Compromised Host
* adjusted Unusual File Transfer Utility Launched
* adjusted Potential Malware-Driven SSH Brute Force Attempt
* adjusted Unusual Process Spawned from Web Server Parent
* adjusted Unusual Command Execution from Web Server Parent
* adjusted Rare Connection to WebDAV Target
* adjusted Potential PowerShell Obfuscation via Invalid Escape Sequences
* adjusted Potential PowerShell Obfuscation via Backtick-Escaped Variable Expansion
* adjusted Unusual File Creation by Web Server
* adjusted Potential PowerShell Obfuscation via High Special Character Proportion
* adjusted Potential Malicious PowerShell Based on Alert Correlation
* adjusted Potential PowerShell Obfuscation via Character Array Reconstruction
* adjusted Potential PowerShell Obfuscation via String Reordering
* adjusted Potential PowerShell Obfuscation via String Concatenation
* adjusted Potential PowerShell Obfuscation via Reverse Keywords
* adjusted PowerShell Obfuscation via Negative Index String Reversal
* adjusted Dynamic IEX Reconstruction via Method String Access
* adjusted Potential Dynamic IEX Reconstruction via Environment Variables
* adjusted Potential PowerShell Obfuscation via High Numeric Character Proportion
* adjusted Potential PowerShell Obfuscation via Concatenated Dynamic Command Invocation
* adjusted Rare Connection to WebDAV Target
* adjusted Potential PowerShell Obfuscation via Invalid Escape Sequences
* adjusted Potential PowerShell Obfuscation via Backtick-Escaped Variable Expansion
* adjusted Potential PowerShell Obfuscation via Character Array Reconstruction
* adjusted Potential PowerShell Obfuscation via High Special Character Proportion
* adjusted Potential PowerShell Obfuscation via Special Character Overuse
* adjusted Potential PowerShell Obfuscation via String Reordering
* adjusted Suspicious Microsoft 365 UserLoggedIn via OAuth Code
* adjusted fields that were inconsistent
* adjusted additional fields
* adjusted esql to Esql
* adjusted several rules for common field names
* updating rules
* updated dates
* updated dates
* updated ESQL fields
* lowercase all functions and logical operators
* adjusted dates for unit tests
* Update Esql_priv to Esql_temp as these don't hold PII
* PowerShell adjustments
* Make query comments consistent
* update comment
* reverted 2856446a-34e6-435b-9fb5-f8f040bfa7ed
* Update rules/windows/discovery_command_system_account.toml
* removed dot notation
---------
Co-authored-by: Jonhnathan <26856693+w0rk3r@users.noreply.github.com>
Completing Deprecation process for AWS EC2 Snapshot Activity
- It's been 2 rule releases since initial name change
- changed maturity to deprecation
- updated deprecation_date
- moved file to _deprecated folder
* [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>
Eric Forte