* 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
Tuning this rule to exclude identity type `AssumedRole` as this is too common a behavior, often automated, and used to verify current identity and role assumptions. Therefore it is not as indicative of suspicious behavior when used by assumed roles. This rule will still trigger for `IAM User` and `Federated User` identity types. In telemetry this change reduces alerts from ~240,000 to 43 in the last 30 days.
* adding new rule for Okta public client app OAuth token request with client credentials
* Update detection_rules/etc/non-ecs-schema.json
* changing new terms to okta.actor.display_name
* linted; added references
* deprecated rule; tuned for single source inclusion
* adjusted query comments
* added min-stack
* updated date
* added Azure-based rule for brute forcing
* added reference to o365spray
* fixed tag
* adjusted query comment
* added rule for repeat source
* adjusted query to use count distinct
* added intervals; adjusted lookback window according to time truncation
* new impossible travel rules for o365; deprecated development rule
* deleted development rule as it has not lock version
* reverted rule deletion, added note about reliability and related rules
* [Rule BugFix] Google Workspace Oauth2 new app
In our extended testing the changed rule with latest Google Workspace
integration generates the following errors which make the rule fail everytime:
```
unsupported_operation_exception: [wildcard] queries are not currently supported on keyed [flattened] fields.
```
After careful investigation this happens since the field google_workspace.token.scope.data is a flattened
JSON filed that contains one or more key/value pairs and ES does not support wildcard matches withing flattened
fields as the error suggests.
We instead query the whole field (that contains the flattened fields) with the wildcard characters and achieve
the same outcome without the error.
* [Rule BugFix] Google Workspace Oauth2 new app update (#3436)
In our extended testing the changed rule with latest Google Workspace
integration generates the following errors which make the rule fail everytime:
```
unsupported_operation_exception: [wildcard] queries are not currently supported on keyed [flattened] fields.
```
After careful investigation this happens since the field google_workspace.token.scope.data is a flattened
JSON filed that contains one or more key/value pairs and ES does not support wildcard matches withing flattened
fields as the error suggests.
We instead query the whole field (that contains the flattened fields) with the wildcard characters and achieve
the same outcome without the error.
---------
Co-authored-by: Mika Ayenson <Mikaayenson@users.noreply.github.com>
Co-authored-by: Terrance DeJesus <99630311+terrancedejesus@users.noreply.github.com>
* [New Rule] AWS S3 Object Encryption Using External KMS Key
Identifies encryption events for S3 bucket objects using an AWS KMS key from an external account. Adversaries with access to a misconfigured S3 bucket and the proper permissions may encrypt objects with an external KMS key to deny their victims access to their own data.
* Update impact_s3_object_encryption_with_external_key.toml
* Update impact_s3_object_encryption_with_external_key.toml
* missing coma after tag
* missing backslash on technique reference
Terrance DeJesus