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
* Add alignment checking for sub-queries
* Allow field to be over written with original field
* Update rule prompt to allow for int 0 values
* Support custom schema index overwrite
---------
Co-authored-by: shashank-elastic <91139415+shashank-elastic@users.noreply.github.com>
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* rule-tuning: Elastic Agent service termination improve for detection
* [Rule Tuning]: Elastic Agent Service terminated, updated date field
* Enhance detection rules for stopping Elastic Agent
* Fix syntax for process name checks in TOML file
---------
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
* Revise USB device mounting detection rule
Updated detection rule for USB device mounting to use device serial number instead of friendly name. Enhanced investigation steps and response actions for better clarity.
* Update initial_access_exfiltration_new_usb_device_mounted.toml
* Update rules/cross-platform/initial_access_exfiltration_new_usb_device_mounted.toml
* Update initial_access_exfiltration_new_usb_device_mounted.toml
---------
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
Resolves#5202Resolves#5203Resolves#5204
The gen_ai.policy.action field is an array, so an additional mv_expand
is necessary for the rules to work correctly with AWS Bedrock integration
events that contain multiple policy actions.
Updated rules:
- Unusual High Word Policy Blocks Detected
- Unusual High Denied Topic Blocks Detected
- Unusual High Denied Sensitive Information Policy Blocks Detected
- Unusual High Confidence Content Filter Blocks Detected
- AWS Bedrock Guardrails Detected Multiple Policy Violations Within a Single Blocked Request
Co-authored-by: shashank-elastic <91139415+shashank-elastic@users.noreply.github.com>
* [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] File Transfer or Listener Established via Netcat
* Formatting
* Update execution_file_transfer_or_listener_established_via_netcat.toml
* Update execution_file_transfer_or_listener_established_via_netcat.toml
* Add timestamp override to netcat execution rule
---------
Co-authored-by: Eric Forte <119343520+eric-forte-elastic@users.noreply.github.com>
* [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.
shashank-elastic