* [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>
* [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.
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
* 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>
* [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
AWS Role Assumption By Service
The newest versions of this rule seem fine in telemetry and the rule executes as expected
- removed MD from description
- adjusted execution window for 1 m look back
- fixed inaccuracies in Investigation Guide
- added Lateral Movement tag
- adjusted highlighted fields
- reduced history window from 14 to 10 days
AWS Role Assumption By User
This rule seem fine in telemetry and the rule executes as expected
- removed MD from description
- fixed inaccuracies in Investigation Guide
- added Lateral Movement tag
- adjusted highlighted fields
- added `cloud.account.id` to new_terms field to account for duplicate user.names across cloud accounts
- replaced new terms flattened field for `aws.cloudtrail.resources.arn`, which gives the same result and remains consistent with the other rule.
Rule is triggering as expected, very low instances of alerts in telemetry
- adjusted execution window
- slight edits to IG for accuracy
- removed exclusion `and not aws.cloudtrail.user_identity.arn: *AWSServiceRoleForAmazonSSM/StateManagerService*` from the query. This is a service-linked role meant to be used by AWS internal services. Therefore, the existing exclusion `and not source.address: "ssm.amazonaws.com"` already excludes the use of this role by the SSM service. I show this in the screenshot below. This will remove the use of wildcards in the query and improve performance.
- changed the new terms fields to use combination of `cloud.account.id` and `user.name` so that only roles (and not individual role sessions) are being evaluated. adding `cloud.account.id` accounts for duplicate user.names across multiple accounts.
* [Rule Tuning] AWS IAM Assume Role Policy Update
- changed time window to have only 1 minute lookback
- changed the new terms field to look at combination of cloud.account.id, user.name, and roleName. This is to account for the problem with using user_identity.arn for AssumedRoles. Roles are identities in AWS that are granted a set of permissions and can then be assumed by various users across many different sessions. Each of these sessions is designated a session name which is attached to the `user_identity.arn`. This means that each time a Role is assumed, there is a unique user_identity.arn created. This rule is meant to capture unique instances of the Role itself which is captured separate from the individual session names in the `user.name` field. `cloud.account.id` has been added to the new_terms fields to account for organizations with multiple AWS account ids, which may reuse certain user.names across accounts.
This may improve performance especially in environments where there are many users assuming the same role and updating it's trust policy as a part of normal operations.
* remove markdown from description
* [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
* [Rule Tuning] AWS EC2 Unauthorized Admin Credential Fetch via Assumed Role
- Edited Rule Name, Description, and Investigation Guide to better align with the behavior captured by this rule
- adjusted execution window
- added highlighted fields
* adding account id to highlighted fields
adding account id to highlighted fields
* changing AWS EC2 tag for consistency across EC2 rules
changing AWS EC2 tag for consistency across EC2 rules
* [Rule Tuning][New Rule][Deprecation] AWS EC2 EBS Snapshot Activity Rules
1. Rule Tuning - to prevent duplicate alerts for AWS EC2 EBS Snapshot Shared of Made Public, the execution interval has been adjusted from 5m interval with 4m lookback to 5m interval with 1m lookback.
2. New Rule - to capture when access is removed from an EBS Snapshot. While this may be intentional behavior it could indicate malicious attempts to inhibit system recovery efforts post-compromise, or to maintain exclusive access to critical backups by removing permissions for all users except their own controlled account.
3. Deprecate - AWS EC2 Snapshot Activity is too broad a rule and the behavior of the other 2 rules resulting in duplicate alerts and non-specific context for which permission change type is happening (`add` vs `remove`).
* adding updated_date to new rule
* adding Deprecated to IG title
* adding source.address to keep fields
* [Tuning] AWS Access Token Used from Multiple Addresses
Rule tuning for AWS STS Temporary IAM Session Token Used from Multiple Addresses
* update min stack
* add access key identification to IG
add access key identification to IG
---------
Co-authored-by: shashank-elastic <91139415+shashank-elastic@users.noreply.github.com>
* 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>
* new rule 'AWS SNS Topic Created by Rare User'
* changed file name
* Update rules/integrations/aws/resource_development_sns_topic_created_by_rare_user.toml
* moved new terms link to investigation guide
* [Rule Tuning] AWS Monthly Rule Tunings
* Adding several more AWS tunings
* updating patch version
* updating non-ecs type to boolean
* fixed cloudtrail index
Isai