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>
* [New Rule] Pod or Container Creation with Suspicious Command-Line
* Added container domain tag
* Update execution_suspicious_pod_or_container_creation_command_execution.toml
* Refine EQL query for suspicious pod/container creation
* Update rules/linux/execution_suspicious_pod_or_container_creation_command_execution.toml
* Update execution_suspicious_pod_or_container_creation_command_execution.toml
* Update process name conditions for suspicious execution
`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
shashank-elastic