This rule is performing well in telemetry and producing alerts as expected for both explicit external account sharing and making snapshots public. Both scenarios tested.
- updated description, FP and IG
- added highlighted fields
- added `event.type` as `event_category_override` field because `event.category` is not populated for these events.
Co-authored-by: shashank-elastic <91139415+shashank-elastic@users.noreply.github.com>
This rule is performing well in telemetry, low volume and expected alerts. No major changes to rule query.
- reduced execution window
- updated description and IG
- added highlighted fields
Co-authored-by: shashank-elastic <91139415+shashank-elastic@users.noreply.github.com>
AWS S3 Bucket Replicated to Another Account
- updated description and IG
- added `event.type` as `event_category_override` field
- adjusted query to use `info` instead of `any` and added `Account=` instead of `Account` to help reduce chances of capturing unintended requests.
- added highlighted fields
AWS S3 Bucket Policy Added to Share with External Account
- added `event.outcome = success` to query to reduce noise from failed attempts
Co-authored-by: shashank-elastic <91139415+shashank-elastic@users.noreply.github.com>
* [Rule Tunings] AWS Multiple API Calls rules
AWS EC2 Multi-Region DescribeInstances API Calls
Over 2,000 alerts in the last 24 hours. This is a very noisy rule, by design it is alerting on quite normal behavior. There is not much in-the-wild threat behavior that justifies keeping this rule as a standalone alert. As a threat indicator, this is best used as a hunting rule or in correlation with another rule, for example: (GetCallerIdentity new terms + multi region DescribeInstances by same principal) or (Multiple Discovery API calls + multi region DescribeInstances by same principal) or (multi region DescribeInstances + snapshot/AMI activity by same principal). However, on its own it’s not adding much value over the noise.
- I’m keeping this as ESQL rule but converting it to a BBR
- keeping more fields for further context
- Changing investigation guide to be more relevant for hunting/correlation rule
AWS Discovery API Calls via CLI from a Single Resource
This rule is alerting as expected with low telemetry. It has to remain an ESQL rule as no other rule types can truncate the time window to 10 sec looking for a threshold of unique API calls coming from a single user.
- Keeping as ESQL rule
- Reduced execution window
- Keeping more fields for further context
- Adding highlighted fields
- Updated Investigation guide
* adding highlighted fields to keep parameter
* Apply suggestions from code review
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* Apply suggestion from @imays11
---------
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
Co-authored-by: Samirbous <64742097+Samirbous@users.noreply.github.com>
Co-authored-by: Terrance DeJesus <99630311+terrancedejesus@users.noreply.github.com>
This rule is performing as expected in telemetry, low volume rare behavior. No query changes needed.
- increased the severity and risk score
- reduced execution window
- reduced lookback window for new terms
- updated description and investigation guide
- slight edits to highlighted fields
Rule is alerting as expected, with low telemetry volume. Updates to rule query are to provide more alert context as an ESQL rule.
- reduced execution window
- added additional fields for more alert context, include customer-requested `data_stream.namespace` field
- added highlighted fields
- updated description and investigation guide
* [Rule Tuning] AWS Access Token Used from Multiple Addresses
This rule is extremely loud in telemetry ~2612 alerts in last 24 hours. There have also been a couple community requests for changes.
- reduced the scope of the alerts to only surface the "high" fidelity_score cases for `"multiple_ip_network_city"` or `"multiple_ip_network_city_user_agent"` criteria. This reduced telemetry by ~90%
- excluded 2 more benign service providers `support` which reduced volume by another 6%.
- added the `data_stream.namespace` field as requested.
- kept the rest of the rule logic visible so that if customers would like to broaden the scope of this rule again, they can duplicate the rules and revert back to the broader condition `Esql.activity_type != "normal_activity"`. This has been included as a comment in the rule query.
I will keep an eye on this rule in telemetry to determine it's value moving forward.
* nit IG format changes
`CreateCluster` is a common Redshift lifecycle operation that occurs frequently in normal workflows. Creating a new Redshift cluster offers no real advantage to an attacker and outside of cost, does not produce material impact for a target environment. This behavior aligns more with cloud infrastructure monitoring or posture management, which is important but not the focus of our detection ruleset.
Real world Redshift abuse centers on misuse of existing resources, such as snapshot sharing or copying or exposing the cluster through permissive VPC security group changes. These threat paths should be covered by other rules. Deprecating this creation-focused rule reduces noise and keeps the AWS ruleset aligned with real threat surfaces rather than infrastructure management.
* [Rule Tuning] AWS IAM Brute Force of Assume Role Policy
Description and primary tactic for this rule is misleading. The rule captures an IAM principal enumeration technique used by tools like PACU, it does not capture AssumeRole brute-force attempts. I've changed the primary tactic to Discover, changed the rule name and updated the rule description and Investigation Guide to more clearly reflect what behavior is being captured.
The query itself remains the same and the threshold values. I changed the execution window to the standard 5 min + 1 min lookback and was still able to capture the behavior.
* Apply suggestions from code review
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
* adding rule.threshold values
adding ["cloud.account.id", "user.name", "source.ip"] as group by fields
---------
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
`DeleteFileSystem` permanently removes an Amazon EFS file system and all stored data. This operation has no recovery path and represents a clear Impact-level destructive action when performed unintentionally or by an unauthorized actor. It is rare in most environments and typically limited to infrastructure teardown or automated provisioning workflows.
Currently this rule also matches `DeleteMountTarget` events. This action appears frequently in normal EFS lifecycle workflows and is not, by itself, a strong indicator of malicious intent. Since only `DeleteFileSystem` represents irreversible destructive impact, the rule has been narrowed to focus exclusively on the meaningful threat behavior.
- removed `DeleteMountTarget` scope from query
- rule name change and toml file name change to match new scope
- reduced execution window
- updated tags
- updated description, FP and IG
- added highlighted fields
* [Rule Tunings] AWS RDS Rules
#### AWS RDS DB Instance Made Public
- updated description and investigation guide
- added highlighted fields
#### AWS RDS DB Instance or Cluster Deletion Protection Disabled
- updated description and investigation guide
- added highlighted fields
#### AWS RDS Snapshot Deleted
- excluded `backup.amazonaws.com` as this is expected behavior. This exclusion reduces noise in telemetry by ~77%
- updated description and investigation guide
- added highlighted fields
#### AWS Deletion of RDS Instance or Cluster > AWS RDS DB Instance or Cluster Deleted
- reduced execution window
- slight name change to align with other rules
- updated description and investigation guide
- added highlighted fields
#### AWS RDS DB Instance Restored
- `event.type` used for `event_category_override` because event.category is not mapped for these API calls
- updated description and investigation guide
- added highlighted fields
#### AWS RDS DB Instance or Cluster Password Modified
- `event.type` used for `event_category_override` because event.category is not mapped for these API calls
- updated description and investigation guide
- added highlighted fields
#### AWS RDS Snapshot Export
- reduced execution window
- updated mitre mapping
- updated description and investigation guide
- added highlighted fields
* rule type change from eql to kql
changing rule type to kql since there's not eql specific functions needed for the query
Both these rules are have low volume in telemetry as expected, this is quite rare behavior. No major changes to the rule logic itself.
AWS IAM Roles Anywhere Profile Creation
- updated description and investigation guide
- reduced execution window
- added highlighted fields
AWS IAM Roles Anywhere Trust Anchor Created with External CA
- changed rule type to EQL to use `stringContains` instead of leading wildcard
- uses `event.type` as event category override field
- reduced execution window
- updated description and investigation guide
- added highlighted fields
This rule is performing as expected in telemetry, no query changes needed.
- reduced execution window
- updated description and investigation guide
- updated tags
- added highlighted fields
Noticed some false positives in alert telemetry leading to high alert volume. For all 3 rules I've added `source.ip:*` and excluded `user_agent.original: AWS Internal` to reduce noise from internal AWS services and backend API calls made on a user's behalf. These rules will instead stay focused on direct SDK/CLI triggered API calls.
- reduced execution window
- updated description, false positive and investigation guide sections
- added highlighted fields
- udpated tags and MITRE mapping
This rule is quite loud in telemetry. However over 80% of alerts come from a single cluster, which seems to have a lot of role usage and operation-type IAM Users which assume other roles constantly. This makes me think the majority of these alerts may be from multiple role sessions retrieving secrets, rather than a single user retrieving multiple secrets rapidly. I've looked at the prod telemetry data we have access to and found a few instances where a single secret is accessed multiple times or certain AWS services retrieve multple secrets rapidly. All of these instances have been accounted for in the tunings here.
- query has been changed to remove `GetBatchSecretValue` from the query since this API call actually calls the `GetSecretValue` for each of the secrets it's retrieving. So we only need to look for `GetSecretValue`
- I've added the AWS services found in prod data that contribute to rapid secret retrieval
- Changed the threshold parameters to look for a single `user.id` retrieving more than 20 unique secret values (`aws.cloudtrail.request_parameters`)
- updated the description and investigation guide
- reduced execution window
* [Rule Tuning] AWS IAM API Calls via Temporary Session Tokens
Came across some false positives as I was rule testing.
Temporary credentials are also created for AWS Internal operations and when an AWS service operates on your behalf. These both should be excluded from results. I saw this in my own testing, in prod data and in our alert telemetry. These cases can be excluded by looking for `source.ip:*` as this field is not populated for those internal AWS operations.
NOTE: Another false positive instance has been highlighted in the investigation guide. A legitimate AWS console login session is given temporary (ASIA) credentials which are populated for all the operations performed during that session. The only way to distinguish between these events and other temporary session token events, like those granted via AssumeRole or GetSessionToken, is with a field populated as `sessionCredentialFromConsole: true`. Right now our Integration does not map this field and it can only be found in `event.original`. I am putting in an Integration request to populate this field, which we could then use to further reduce false positives for rules like this.
- updated description , false positives, and investigation guide
- added `source.ip:*` to query
* excluding AWS Internal user agent
excluding AWS Internal user agent
#### Deprecate RDS DB Instance/Cluster lifecycle detections
`CreateDBInstance`, `CreateDBCluster`, `StopDBInstance`, `StopDBCluster`. These events occur frequently in normal workflows and do not reflect known attacker techniques. They are simply RDS lifecycle operations, with no real impact from an attacker-target perspective. These actions don't have a meaningful benefit for an attacker or cause a meaningful impact for a target. Threat activity around RDS is typically centered around snapshot sharing, export, and public exposure, which is already covered by other rules. There is also a theoretical case to be made for detecting destructive actions against RDS resources like `instance|cluster|snapshot Deletion`, this is covered by other rules. Removing these creation and stoppage rules reduces noise and keeps the AWS ruleset more aligned with real threat surfaces rather than infrastructure management.
#### Deprecate Outdated DBSecurityGroup API rules
`CreateDBSecurityGroup` and `DeleteDBSecurityGroup` were only used by RDS deployments on EC2-Classic, which AWS has fully retired. Modern RDS uses VPC Security Groups, making these APIs obsolete. These rules can no longer trigger and provide no threat-detection value.
Network-permission manipulation is fully covered by our existing VPC Security Group rule - "AWS EC2 Security Group Configuration Change".
Completing Deprecation Process for this rule. It has now been included in our ruleset with `Deprecated -` prefix for 2 release cycles and should now be moved to our `_deprecated` folder.
ElastiCache cache security groups are only used with EC2-Classic deployments.
AWS officially retired EC2-Classic and no longer supports launching ElastiCache
clusters in EC2-Classic networking environments.
All modern ElastiCache deployments run in a VPC and rely on standard EC2
security groups (ec2.amazonaws.com APIs) rather than CacheSecurityGroup APIs
(elasticache.amazonaws.com).
This behavior is covered by this existing rule:
- https://github.com/elastic/detection-rules/blob/fe642a879a412db71492f5d776e1e3338a531266/rules/integrations/aws/persistence_ec2_security_group_configuration_change_detection.toml
These rules no longer match any behavior in supported AWS
environments and so should be deprecated. This PR:
- Marks both rules with `Deprecated - ` title to start deprecation process
- Updates rule description to clarify that they are only relevant for historical
EC2-Classic log analysis.
- Recommends relying on the existing EC2 security group rule for network-control
changes impacting ElastiCache in VPC-based deployments.
I've tested this scenario by creating an Elasticache cluster, creating, and modifying security group rules. Below is a screenshot verifying that the activity is indeed captured by the normal EC2/VPC security group rule. There were no alerts triggered for the "Elasticache Security Group" Rules
This rule is working as expected, only instances of this alert in telemetry is for testing environments.
- uses `iam` instead of `any` for eql query
- added highlighted fields
* [Rule Tuning] AWS EC2 Instance Console Login via Assumed Role
No hits in telemetry for this rule yet. Which is good as it is extremely rare and high-risk behavior for an EC2 instance to exhibit any console login behavior.
- used `event.type` as event_category_override field to remove use of `any` in query
- updated description and investigation guide
- updated tags
- updated Mitre mapping
- added highlighted fields
* normalized Sign-In tag
normalized Sign-In tag
* fixing Mitre mapping
* Update rules/integrations/aws/lateral_movement_ec2_instance_console_login.toml
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
---------
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
* [Rule Tuning] AWS IAM SAML Provider Updated
Rule is performing well in telemetry, low volume as expected. The only obvious false positives are from AWS SSO service so that internal behavior has been excluded from the rule.
- added AWS SSO exclusion to query
- updated description and IG
- added highlighted fields
* Update rules/integrations/aws/privilege_escalation_iam_saml_provider_updated.toml
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
---------
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
### AWS IAM Virtual MFA Device Registration Attempt with Session Token
- rule change kql to eql so that I could use startsWith function instead of wildcard for the `ASIA*`, temporary session determination.
- there is a known false positive for rules like this. When you login to the AWS console, a temporary session token is created in the back-end so in cloudtrail the token id looks the same (`ASIA*`) as temporary session tokens created by actions like `GetSessionToken` or `AssumeRole`, which is what this rule meant to capture. Our current data source does now allow us to distinguigh between these type of events. However, cloudtrail does provide a field `sessionCredentialFromConsole:true` that I am putting in a request for Integrations to include. This would allow us to exclude Console login sessions from rules like this that look for temporary token abuse.
- reduced execution window
- updated description, FP and IG
- update MITRE mapping
- added highlighted fields
AWS IAM Deactivation of MFA Device
- removed `DeleteVirtualMFADevice` from the scope of this rule. When Deleting an MFA device you must deactivate it first if it is associated with a user. You can also Create an MFA device and then Delete it without it being activated for a particular user. By capturing both Deactivation and Deletion events we have duplicate alerts for the same activity (This duplication of events is seen in telemetry.) We also capture benign instances where un-used MFA devices are deleted (which is a clean-up best practice). By reducing the scope to only `DeactivateMFADevice` actions, we capture the most threat-centric behavior which should be investigated.
- reduced execution window
- updated Description, FP and IG
- added highlighted fields
This rule is extremely loud in telemetry with no meaningful way to reduce false positives. The behavior it's capturing is common behavior, however can be used for threat hunting, investigation and further correlation with other detection rules. I'm moving this to a BBR rule with a few changes:
- removed IAMUser specification in the query. Temporary sessions can be created by both IAM Users and the Root Account. This rule should capture both instances.
- reduced execution window
- name change to AWS GetSessionToken Usage as this captured behavior is not indicative of abuse
- added highlighted fields
- updated description, FP and IG
These Cloudtrail lifecycle rules are performing as expected in telemetry, very low volume. No major changes needed
- updated Descriptions and IGs
- added highlighted fields
- added missing tags
- reduced execution windows
* [Rule Tuning][New Rule] AWS S3 Bucket Policy Added to Share with External Account/ to Allow Public Access
AWS S3 Bucket Policy Added to Share with External Account
Low telemetry volume overall, however false positives were seen for cloudfront identity and service accounts being given access to a bucket
- Reduced the scope of this rule to only analyze policy that include account ids or account ARNs (which include an account ID). This eliminates the false positives triggered by sharing buckets with a service account (i.e. cloudtrail.amazonaws.com)
- Excluded cloudfront identity, which should be treated the same way service accounts are being treated and be excluded as they do not include account IDs in their ARN
- This rule wasn't explicitly capturing the use of `Principal: *` which is a public sharing method, often accompanied by a Condition statement (i.e. aws.SourceAccount = OR aws.PrincipalAccount= OR ip.address = ....). The new query will capture Condition statements that include an account id. However there is still a gap for Policies that have explicit `Principal:*` with or without a condition, so another rule was created that will account for these scenarios.
- added highlighted fields
- updated investigation guide and description
- updated Mitre tactics and tags
- `event.type` used in place of `event.category` field
### AWS S3 Bucket Policy Added to Allow Public Access
Rule added to cover gap in public bucket policy added which includes an `Effect=Allow` and `Principal: *`. While an additional condition might be added to this policy which would exclude public access, cases where the condition is not included mean the bucket is publicly accessible. Both cases need to be verified, because even the condition could be giving access to an attacker owned account. There is also the chance that an `Effect=Deny` for `Principal:*` will trigger a false positive for this rule if the same policy also includes an `Effect=Allow` statement. We call this out in the description, false positive and investigation guide sections of the rule.
* [Rule Tunings] AWS Group Creation, User Added to Group, Group Deletion
All 3 rules are showing extremely low telemetry volume as expected. No major changes needed to these queries.
- updated the descriptions, investigation guides and false positive sections
- reduced execution window
- added highlighted fields
* slight edit to description
* Revert "[Rule Tuning][New Rule] AWS S3 Bucket Policy Added to Share with External Account/ to Allow Public Access"
This reverts commit 776d748a11d11f2c0e974e68c9e3adc77dcb3d9f.
* Update rules/integrations/aws/persistence_iam_group_creation.toml
No major query logic changes needed. This rule is performing as expected in telemetry, known to be a bit noisier in development environments where bucket configuration changes and deletions happen often.
- updated Description and IG
- reduced execution window
- updated MITRE mapping
- updated tags
- added highlighted fields
* [Rule Tunings] AWS EC2 EBS Snapshot and Encryption Rules
AWS EC2 Encryption Disabled
rule performance is good, telemetry looks low as expected
- additional context to description to emphasize the security concern and purpose of the rule
- updated investigation guide
- added highlighted fields
- reduced execution window
AWS EC2 EBS Snapshot Access Removed
rule alerts as expected, telemetry volume is low as expected. however, this rule can be accomplished using EQL so I've changed the rule type
- changed rule type to eql
- added index
- updated IG
- added highlighted fields
note: I have to use `any` for the query since there is no `event.category` defined for `event.action: ModifySnapshotAttribute`
AWS EC2 EBS Snapshot Shared or Made Public
Converted to EQL. As an ESQL rule the primary benefit was being able to definitely exclude instances where a user adds their own account id when calling the ModifySnapshotAttribute instead of an external account id. This is a redundant action as the snapshot when created is automatically shared with the account it's created in. But this could be a false positive if it's done by mistake. Instead of keeping this as an ESQL rule, I still think there is more value to converting this to EQL for both customer alert context and telemetry. When looking at production data, I saw no instances where the owning account id was added in this way. Its a rare mistake that shouldn't happen often enough to support keeping this as an ESQL rule.
- converted to EQL
- added index
- updated IG
- updated description
- added highlighted fields
* adding event_category_override = "event.provider"
override event.category to event.provider to account for the use of "any" in EQL query
* normalizing IG title capitalization
normalizing IG title capitalization
* bumping severity to medium
since EC2 snapshot data can be sensitive, unauthorized sharing or access removal should be triaged
* updated event_category_override field
replaced event.provider with event.type to satisfy EQL library parsing requirements
#### AWS S3 Bucket Server Access Logging Disabled
Rule is triggering as expected with low telemetry
- removed `any` from EQL query by replacing event category field with `event.type` as this is mapped for the API action `PutBucketLogging`
- added `event.provider` as part of query
- updated Investigation guide
- Added highlighted fields
* [Rule Tuning] AWS S3 Bucket Expiration Lifecycle Configuration Added
AWS S3 Bucket Expiration Lifecycle Configuration Added
- changed rule type to EQL so as not to use the double wildcard
- used `event.type` as event category override field because `event.category` is not mapped for `PutBucketLifecycle` action
- removed unnecessary `*LifecycleConfiguration*` check from query, this field is required for any `PutBucketLifecycle` API call so unnecessary to include in the query.
- updated description and IG
- reduced execution window
- updated Mitre mapping
- removed incorrect setup notes
- added highlighted fields
* fixing Mitre mapping error
* adding IG disclaimer
* [New Rule][Deprecation] AWS EC2 Export Tasks Rules
**AWS EC2 VM Export Failure**
Starting Deprecation process for this rule. I cannot see the value in alerting on a failed VM export attempt. This is rare behavior in general but failed attempts don't warrant an alert especially considering we have no coverage for an actual successful VM Export. This rule has had no alerts in telemetry, I've seen no hits in prod data either. VM exports have a very specific use-case, they can be used to create VM image files that can be downloaded and used to run a VM locally. Successful exports warrant an alert.
**AWS EC2 Export Task**
This new rule is meant to fill the previously mentioned gap regarding successful VM exports. But also includes other forms of EC2 export tasks.
`CreateImageExportTask`
`ExportImage`
`CreateStoreImageTask`
* adding highlighted fields
adding highlighted fields
* Update rules/integrations/aws/exfiltration_ec2_vm_export_failure.toml
* Update rules/integrations/aws/exfiltration_ec2_vm_export_failure.toml
* [Rule Tuning] AWS EC2 Full Network Packet Capture Detected
**AWS EC2 Full Network Packet Capture Detected**
Alert telemetry is low in general however the alerts that do exist are unnecessarily duplicative in nature. When a traffic mirror session is created (CreateTrafficMirrorSession), it is typcially created alongside A filter and filter rules (CreateTrafficMirrorFilter, CreateTrafficMirrorFilterRule) which determines what traffic will be mirrored. There is also a traffic mirror target (CreateTrafficMirrorTarget), which is the destination for the mirrored traffic to go. The original scope of this rule included all of those APIs when really the only API needed here is `CreateTrafficMirrorSession`, which is the actual network mirroring behavior. The rest of those calls can be used as additional context during alert triage, but I've significantly reduced the scope of this rule to only capture the actual traffic mirroring behavior.
- reduced the query scope to `CreateTrafficMirrorSession` only
- reduced the execution window
- update description and investigation guide
- replaced API reference link
- added highlighted fields
* updating mitre technique
updating mitre technique
* updated Mitre mapping
adding network sniffing technique
* updating references to include relevant threat blog
updating references to include relevant threat blog
* adding EC2 tag
adding EC2 tag
* updating EC2 tagging
* [Rule Tuning] AWS S3 Object Versioning Suspended
AWS S3 Object Versioning Suspended
This rule is performing well in telemetry, no major query changes in terms of detection logic or rule type.
- to improve performance, changed event category field to `event.type` since `event.category` is not mapped for `PutBucketVersioning` event.action. This avoids use of `any` in query.
- added `event.provider == "s3.amazonaws.com"` to query
- added highlighted fields
- updated investigation guide
* removed some copy errors
This rule is triggering as expected. However, the threat this rule is meant to capture is a potential malicious .js file upload. Currently it is capturing both GetObject (read file) and PutObject (write file) API calls which is adding noise without adding much threat detection value.
- Removed `GetObject` API call from scope, so this rule focuses only on write activity. This reduced alert telemetry volume by ~73%
- added `event.outcome == success` criteria to exclude failed upload attempts
- corrected `Pulumi` typo in user agent exclusion criteria
- reduced execution window
- added highlighted fields
* [Rule Tuning][New Rule] AWS S3 Bucket Policy Added to Share with External Account/ to Allow Public Access
AWS S3 Bucket Policy Added to Share with External Account
Low telemetry volume overall, however false positives were seen for cloudfront identity and service accounts being given access to a bucket
- Reduced the scope of this rule to only analyze policy that include account ids or account ARNs (which include an account ID). This eliminates the false positives triggered by sharing buckets with a service account (i.e. cloudtrail.amazonaws.com)
- Excluded cloudfront identity, which should be treated the same way service accounts are being treated and be excluded as they do not include account IDs in their ARN
- This rule wasn't explicitly capturing the use of `Principal: *` which is a public sharing method, often accompanied by a Condition statement (i.e. aws.SourceAccount = OR aws.PrincipalAccount= OR ip.address = ....). The new query will capture Condition statements that include an account id. However there is still a gap for Policies that have explicit `Principal:*` with or without a condition, so another rule was created that will account for these scenarios.
- added highlighted fields
- updated investigation guide and description
- updated Mitre tactics and tags
- `event.type` used in place of `event.category` field
### AWS S3 Bucket Policy Added to Allow Public Access
Rule added to cover gap in public bucket policy added which includes an `Effect=Allow` and `Principal: *`. While an additional condition might be added to this policy which would exclude public access, cases where the condition is not included mean the bucket is publicly accessible. Both cases need to be verified, because even the condition could be giving access to an attacker owned account. There is also the chance that an `Effect=Deny` for `Principal:*` will trigger a false positive for this rule if the same policy also includes an `Effect=Allow` statement. We call this out in the description, false positive and investigation guide sections of the rule.
* [Rule Tunings] AWS Group Creation, User Added to Group, Group Deletion
All 3 rules are showing extremely low telemetry volume as expected. No major changes needed to these queries.
- updated the descriptions, investigation guides and false positive sections
- reduced execution window
- added highlighted fields
* Revert "[Rule Tunings] AWS Group Creation, User Added to Group, Group Deletion"
This reverts commit c66a4f11e1c690a856b1c2f4cbb03077739629d7.
* [Rule Tuning] AWS User Created Access Key For Another User
Telemetry looks good for this rule, no way to change this from ESQL as we need to be able to compare fields.
- added event.dataset to query
- added source.ip, cloud.account.id, event.dataset, aws.cloudtrail.user_identity.access_key_id, and source.geo.* fields to `keep`
- added to highlighted fields
- updated IG
* toml-lint
* [Rule Tuning][New BBR Rule] AWS Sign-In Token Creation and Console Login
### Tuning - "AWS Signin Single Factor Console Login with Federated User"
Rule scope change and name change to match
- This original rule description suggests that it was designed to capture console login sessions by a Federated User without the use of MFA. However, AWS does not capture MFA usage for Federated Users (only for Root and IAM users). Federated identities will often use 3rd party IDP apps like Okta to enforce MFA, that data is not captured in Cloudtrail. So, the fields `MFAUsed` of `mfaAuthenticated` will always show as False/No in Cloudtrail.
- I changed the scope of this rule to simply capture Console Login by a Federated User. For security reasons this behavior should be correlated with 3rd party IDP data to ensure MFA was established by the identity requesting the Federated Console login. This is very low noise behavior both in telemetry and prod data.
- added highlighted fields
- edited investigation guide to align with scope change
### New BBR
- `GetSigninToken` exchanges existing temporary AWS credentials (e.g., from STS GetFederationToken or AssumeRole) for a short-lived sign-in token that is embedded in a one-click URL to the AWS Management Console.
- ConsoleLogin API often follows a `GetSignInToken` request in normal operations. However, suspicious circumstances like both requests coming from different IPs or geo locations might indicate some form of compromise and should be investigated.
- This BBR rule is created to capture all successful `GetSigninToken` requests for any identity type. It can be used for further correlation with other rules or as an investigative/hunting rule during alert triage.
* adding FederatedUser to query
adding FederatedUser to query
* changed ig title to match rule name
changed ig title to match rule name
* toml-lint
* [Rule Tunings] AWS IAM Administrator Access Policy Attached to Group/Role/User
All 3 rules triggering as expected, low telemetry volume. However, the same rule logic can be applied via EQL so I've changed the rule types for all 3 from ESQL to EQL. To provide better telemetry and alert context for users.
- changed rule type to EQL
- updated all IGs
- added highlighted fields
- added index
* removed double note key
removed double note key
* adding iam event.category
* removed file beat compatibility missing category for AttachRolePolicy
filebeat does not have category mapping for AttachRolePolicy event
* toml-lint
* [Rule Tuning][Deprecation] AWS Root Console Login Rules
Deprecate - AWS Root Login Without MFA
- Starting deprecation process for this rule. While root login without MFA should certainly be investigated, this rule overlaps with the broader AWS Successful Root Console login rule. Between the 2, the broader rule should remain since all succesful Root console login events should be investigated. Part of the investigation can include determining if MFA was or was not enabled.
Tuning - AWS Management Console Root Login
No major rule changes needed, telemetry is low as expected for this rule
- reduced execution window
- updated investigation guide
- adjusted tags
- added highlighted fields
- added Mitre subtechnique
Tuning - AWS Management Console Brute Force of Root User Identity
No major rule changes needed, telemetry is low as expected for this rule
- reduced execution window
- updated investigation guide
- adjusted tags
- added highlighted field (the only one available for threshold rule is the threshold field)
* adding AWS Sign-In tag
adding AWS Sign-In tag
* [Rule Tunings] AWS Root Password Recovery and Login Profile Created
AWS IAM Password Recovery Requested > AWS Sign-In Root Password Recovery Requested
- Name change to properly indicate the service Sign-In vs IAM which is used for this API call. Also highlights that this is `Root` activity. In AWS, the PasswordRecoveryRequested event from signin.amazonaws.com applies to the root user’s “Forgot your password?” flow. Other identity types, like IAM and federated users, do not generate this event.
- reduced execution window
- updated Investigation Guide
- updated tag
- added highlighted fields
AWS IAM Login Profile Added for Root
- changed rule type from esql to eql
- added index
- reduced execution window
- updated description and investigation guide to clarify emphasis on Root identity scope
- added highlighted fields
* increased severity score
increased severity score since this is related to root
* Update broken link
---------
Co-authored-by: shashank-elastic <91139415+shashank-elastic@users.noreply.github.com>
* [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
Isai