* [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
* new rule 'AWS EC2 Deprecated AMI Discovery'
* updated type
* updated non-ecs; bumped package version
* updated query
* added missing index
* updated patch version
* rule tuning Okta and AWS lookback times
* adjusted Query Registry using Built-in Tools
* adjusted My First Rule
* Update rules/cross-platform/guided_onboarding_sample_rule.toml
Co-authored-by: Mika Ayenson <Mikaayenson@users.noreply.github.com>
* Update rules/integrations/okta/lateral_movement_multiple_sessions_for_single_user.toml
Co-authored-by: Mika Ayenson <Mikaayenson@users.noreply.github.com>
---------
Co-authored-by: Mika Ayenson <Mikaayenson@users.noreply.github.com>
* adding new rule 'AWS IAM Customer-Managed Policy Attached to Role by Rare User'
* adding investigation guide tag
* adds new hunting query
* updated notes
* changed name
* adjusting pyproject.toml version
* adding new rule 'AWS IAM Create User via Assumed Role on EC2 Instance'
* adding false-positive note
* changed file name
* added event.provider
* tuned 'AWS EC2 Instance Interaction with IAM Service' to be BBR
* updated query
* added BBR tag
* moved rule to BBR
* fixed BBR query
* moved rule to BBR
* [New Rule] [Rule Tuning] AWS STS AssumeRole with New MFA Device, AWS IAM Deactivation of MFA Device
New terms rule for new MFA device with AssumeRole action. Rule tuning to add MITRE technique to "AWS IAM Deactivation of MFA Device"
* add serialNumber to non-ecs schema file
* fixed misspelled toml file name
* Update rules/integrations/aws/persistence_sts_assume_role_with_new_mfa.toml
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
---------
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
* [New Rule] AWS STS Role Chaining
Identifies role chaining activity. Role chaining is when you use one assumed role to assume a second role through the AWS CLI or API.
While this a recognized functionality in AWS, role chaining can be abused for privilege escalation if the subsequent assumed role provides additional privileges.
Role chaining can also be used as a persistence mechanism as each AssumeRole action results in a refreshed session token with a 1 hour maximum duration.
This rule looks for role chaining activity happening within a single account, to eliminate false positives produced by common cross-account behavior.
* adding metadata query fields
* removing index field
* updating ES|QL rules to include KEEP command
* fixed some ES|QL rules with typos; added validation for KEEP command
* fixed ES|QL errors from missing fields
* fixed flake errors
* updated date
* added best practices to hunt docs
shashank-elastic