* [New Rules] AWS Long-Term Creds Abuse Coverage
This adds a two-layer approach to long-term IAM access key (AKIA*) abuse, aligned with reporting on stolen or leaked keys often abused as seen in Kudelski Security — Trivy supply-chain report.
### Layer 1 — AWS Long-Term Access Key First Seen from Source IP (9f8e3c5e-f72e-4e91-93f6-e98a4fae3e4f)
New Terms on CloudTrail when a given AKIA succeeds from a new `source.ip` in the history window.
Goal: catch novel use of a durable key (travel, new egress, or attacker infrastructure).
### Layer 2 — AWS Long-Term Access Key Correlated with Elevated Detection Alerts
Higher-order rule on open alerts that requires both the Layer 1 rule and at least one other open alert on the same `source.ip` at medium+ severity (or equivalent risk score).
Goal: raise priority when “new IP for this key” happens together with stronger, post-compromise-style signals.
The higher-order rule correlates on `source.ip` in .alerts-security.* index. In testing, I chose to tie the same sessions together using `source.ip` vs `access_key.id` because the alerts index did not expose this field for queries.
Screenshots below show testing that verified the approach. The same operator/session across Layer 1 rule, the sibling alert, and the Layer 2 correlation rule for two separate lab scenarios (e.g. a high-severity sibling rule and a medium-severity sibling rule).
* adding IAM to rule names
* removing unnecessary ref
* Fixed Mitre tactics and tags
* [New Rules] AWS IAM Long-Term Creds Abuse Coverage
Adding min_stack to rule using the field user.entity.id, we determined AWS version 4.7.0 is compatible with Kibana versions '^8.19.4 || ^9.1.4'. We reverted the initial PR and this one adds the min_stack_version.
Original PR: - https://github.com/elastic/detection-rules/pull/5918
Revert PR: - https://github.com/elastic/detection-rules/pull/5923
* [New Rules] AWS Long-Term Creds Abuse Coverage
This adds a two-layer approach to long-term IAM access key (AKIA*) abuse, aligned with reporting on stolen or leaked keys often abused as seen in Kudelski Security — Trivy supply-chain report.
### Layer 1 — AWS Long-Term Access Key First Seen from Source IP (9f8e3c5e-f72e-4e91-93f6-e98a4fae3e4f)
New Terms on CloudTrail when a given AKIA succeeds from a new `source.ip` in the history window.
Goal: catch novel use of a durable key (travel, new egress, or attacker infrastructure).
### Layer 2 — AWS Long-Term Access Key Correlated with Elevated Detection Alerts
Higher-order rule on open alerts that requires both the Layer 1 rule and at least one other open alert on the same `source.ip` at medium+ severity (or equivalent risk score).
Goal: raise priority when “new IP for this key” happens together with stronger, post-compromise-style signals.
The higher-order rule correlates on `source.ip` in .alerts-security.* index. In testing, I chose to tie the same sessions together using `source.ip` vs `access_key.id` because the alerts index did not expose this field for queries.
Screenshots below show testing that verified the approach. The same operator/session across Layer 1 rule, the sibling alert, and the Layer 2 correlation rule for two separate lab scenarios (e.g. a high-severity sibling rule and a medium-severity sibling rule).
* adding IAM to rule names
* removing unnecessary ref
* Fixed Mitre tactics and tags
---------
Co-authored-by: Terrance DeJesus <99630311+terrancedejesus@users.noreply.github.com>
* [New Rule] AWS S3 Rapid Bucket Posture API Calls from a Single Principal
Detects the same principal (`aws.cloudtrail.user_identity.arn`) from the same `source.ip` successfully calling a tight set of read-only S3 management APIs: ``` GetBucketAcl, GetBucketPublicAccessBlock, GetBucketPolicy, GetBucketPolicyStatus, GetBucketVersioning ``` against more than 15 distinct buckets (`aws.cloudtrail.resources.arn`) within a 10-second window.
The idea is grounded in cloud reconnaissance and scanner-style behavior discussed in Kudelski Security’s analysis of the Trivy supply chain story and related cloud activity. It explicitly called out automated assessment tooling and posture-oriented API use across ~24 buckets in a short time. It also highlighted the user's blind spot in telemetry with no Data events captured for S3 buckets. So would need to rely on management APIs for detection.
All our existing detections related to S3 rely on Data events and we have no explicit detections for scanner style recon sweeps as described in this threat report.
### Rule Design
- ES|QL with date_trunc(10 seconds, …) and count_distinct(aws.cloudtrail.resources.arn) grouped by time bucket, identity ARN, and source.ip.
- Management level API calls that are commonly used to identify bucket posture including public accessibility status and whether or not versioning is enabled (necessary info for ransomeware objectives)
- Excludes AWSService, requires source.ip, non-null aws.cloudtrail.resources.arn and user_identity.arn, and session_credential_from_console IS NULL to capture programmatic sessions over console behavior.
- Threshold 15 after evaluating rule in production environment to reduce noise from benign scanners and automation.
- low severity as this rule is FP prone until users add exclusions for known scanner behaviors specific to their environment
* correcting highlighted fields
---------
Co-authored-by: Terrance DeJesus <99630311+terrancedejesus@users.noreply.github.com>
* [New Rule][Rule Tuning] AWS Organizations/Account Discovery Coverage
In response to the supply chain attack highlighted in (Kudelski’s Trivy / TeamPCP analysis)[https://kudelskisecurity.com/research/investigating-two-variants-of-the-trivy-supply-chain-compromise], I've added coverage for AWS Organization and Account reconnaissance which was called out in the research.
### AWS Discovery API Calls via CLI from a Single Resource
- Expanded our existing Multi-service discovery rule to include `event.provider: oraganizations.amazonaws.com`
- added the new `aws.cloudtrail.session_credential_from_console` field to exclude console behavior from this rule, and added appropriate `min_stack` to account for introduction of the field.
GAP: This rule detects aws-cli usage only. In the mentioned reference, attackers used Botocore and Boto3 tooling for this recon activity.
SOLUTION:
### AWS Account Discovery By Rare User
- Created a new Discovery rule focused solely on Organization/Account reconnaissance.
- Made it a new terms rule to reduce false positive noise from common behavior that might be seen using Boto3 or Botocore tooling.
- excluded console session behavior and service account behavior
Testing:
- Ran PACU's organization__enum module
- created a script that can be run to validate the query
- plenty of test data in our stack to run the query against
* Update rules/integrations/aws/discovery_organization_discovery_by_rare_user.toml
Co-authored-by: Terrance DeJesus <99630311+terrancedejesus@users.noreply.github.com>
---------
Co-authored-by: Terrance DeJesus <99630311+terrancedejesus@users.noreply.github.com>
* Expand AWS CloudTrail user-agent rule for TruffleHog and Kali
- Rename rule file to initial_access_suspicious_user_agent_detected_in_cloudtrail.toml
- Rule name: AWS Suspicious User Agent Fingerprint
- Match TruffleHog in user_agent.original (successful API calls)
- Retain Kali Linux distrib#kali fingerprint for aws-cli/Boto3
- Refresh narrative and references (incl. Kudelski Trivy supply-chain analysis)
Same rule_id f80ea920-f6f5-4c8a-9761-84ac97ec0cb2.
Made-with: Cursor
* Apply suggestion from @terrancedejesus
* Update euid job ids and min stack version
* Update euid job ids and min stack version
* Update job suffix from _euid to _ea
* Update pad okta rules
* Update min_stack_comments
* Update gcp audit rules
* Update rules based on new changes
* Add rule for v3_windows_rare_script_ea job
* Update updated_date for rule to pass test
* Remove integrations-only changes (moved to euid-rules-update-integrations branch)
DED, DGA, LMD, PAD, and ProblemChild ML rule changes have been moved to the
euid-rules-update-integrations branch which corresponds to integrations#17626.
This branch (euid-rules-update) now only contains Kibana-related ML rule changes.
Made-with: Cursor
* Update stale updated_date to 2026/04/01 across all modified ML rules
Made-with: Cursor
* Bump min_stack_version from 9.3.0 to 9.4.0 in azure/gcp city/country/user rules
Made-with: Cursor
* Add min_stack_comments to those missing
* [New Rule] AWS API Activity from S3 Browser Client
Detects AWS API activity originating from the S3 Browser application based on the user agent string. S3 Browser is a Windows-based graphical client for managing S3 buckets that is rarely used in enterprise environments but has been observed in use by threat actors for data exfiltration due to its ease of use and bulk download capabilities. This rule was inspired by the Permiso LUCR-3 research which documented Scattered Spider using S3 Browser (v10.9.9) for data theft operations. No usage captured in alert telemetry and only one user utilized this browser in prod data.
Existing Related Coverage: We have several S3-related exfiltration rules covering bucket replication, policy modifications, and ransomware indicators. This new rule closes a gap by detecting a specific attacker tooling fingerprint rather than relying solely on behavioral patterns.
* Update rules/integrations/aws/exfiltration_s3_browser_user_agent.toml
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
* [New Rule] AWS API Activity from Uncommon S3 Client by Rare User
This rule detects AWS API activity from S3 Browser and Cyberduck desktop clients based on user agent strings. Both are graphical S3 management tools that provide bulk upload/download capabilities and have been observed in use by threat actors for data exfiltration. S3 Browser usage is specifically documented in the Permiso blog on LUCR-3 (Scattered Spider), while Cyberduck is referenced in the MITRE ATT&CK Threat Emulation of Scattered Spider. The rule uses a New Terms approach on cloud.account.id and user.name to alert only on the first occurrence per user/account, reducing noise from repeated GetObject or PutObject operations while still capturing new suspicious tool usage.
No existing rules currently detect activity based on these specific S3 client user agents. This fills a gap in detecting exfiltration tooling commonly used in post-compromise data theft operations.
* adding space to S3 Browser
---------
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
Co-authored-by: Eric Forte <119343520+eric-forte-elastic@users.noreply.github.com>
## Summary
This PR adds a new detection rule for AWS CloudShell environment creation, based on the **T1059.009 - Command and Scripting Interpreter: Cloud API** technique as documented in the [AWS Threat Technique Catalog](https://aws-samples.github.io/threat-technique-catalog-for-aws/Techniques/T1059.009.html).
AWS CloudShell is a browser-based shell that provides command-line access to AWS resources directly from the AWS Management Console. While convenient for administrators, CloudShell can be abused by adversaries who gain access to compromised console sessions to execute commands, install tools, or interact with AWS services without needing local CLI credentials.
This rule detects the `CreateEnvironment` API call, which occurs when:
- A user launches CloudShell for the **first time**
- A user accesses CloudShell in a **new AWS region** (each region maintains a separate environment)
### Why `CreateEnvironment` instead of `CreateSession`?
`
While both `CreateEnviroment` and `CreateSession` are noted in the catalog for this technique, during testing I observed that:
- **`CreateEnvironment`** is called when a new CloudShell environment is created (first-time user OR new region)
- **`CreateSession`** is called when reconnecting to an existing CloudShell environment that was previously created
By focusing on `CreateEnvironment`, we capture the meaningful signal (new environment creation) while avoiding noise from users simply reconnecting to existing sessions.
* [Rule Tuning] AWS Access Token Used from Multiple Addresses
Summary
Tuning changes to reduce noise and improve fidelity for the AWS Access Token Used from Multiple Addresses rule. After several tuning this rule is still producing ~2000 alerts/day
- Added aws.cloudtrail.session_credential_from_console exclusion to filter out legitimate console login sessions
- Added Esql.event_provider_count_distinct > 1 condition requiring activity across multiple AWS services to reduce single-service noise
- Changed interval from 5m to 30m to reduce alert frequency
- Updated query time window from 30 minutes to 32 minutes to align with the from setting
- Added min_stack_version = "9.2.0" for the new console credential field (AWS integration 4.6.0+)
Rational
- Console login sessions generate temporary credentials that can appear from multiple IPs during VPN/network transitions
- Requiring activity across multiple AWS service providers increases confidence that the token is being used for broader reconnaissance rather than normal single-service operations
- Longer interval reduces duplicate alerting per access token while still catching the behavior within the 32-minute aggregation window
* Apply suggestions from code review
* Update rules/integrations/aws/initial_access_iam_session_token_used_from_multiple_addresses.toml
* Update initial_access_iam_session_token_used_from_multiple_addresses.toml
* [Rule Tuning] AWS STS Role Assumption by User
Removed AssumedRole from the `aws.cloudtrail.user_identity.type` filter to eliminate redundancy with the AWS STS Role Chaining rule. The AWS STS Role Chaining rule already covers AssumedRole identity types assuming other roles. This change ensures each rule has distinct coverage without overlapping alerts.
- Changed query filter from `aws.cloudtrail.user_identity.type: ("AssumedRole" or "IAMUser")` to `aws.cloudtrail.user_identity.type: "IAMUser"`
- Updated description to clarify the rule focuses on user-initiated role assumptions
- Minor formatting fixes to investigation guide headings
* reducing new_terms fields
reducing new_terms fields to only use "aws.cloudtrail.user_identity.arn" since we do not have to account for roles, this field is unique for IAMUsers
* [Rule Tuningw] Add Console Session Filtering to AWS Temporary Credential Detection Rules
Added `aws.cloudtrail.session_credential_from_console` field filtering to 2 rules to reduce false positives from legitimate console login sessions. Console logins automatically issue temporary "ASIA" credentials, which previously triggered alerts for rules monitoring session token abuse.
- Updated false positives sections to reflect automatic console session filtering
- Updated investigation guides to note that alerts indicate non-console temporary credential usage
- min_stack_version = "9.2.0" because this field was introduced in AWS Integration version 4.6.0. 9.2.0 is the earliest major stack version supported.
Impact
- Significantly reduces false positives from legitimate AWS Management Console usage
- Improves rule fidelity by focusing detection on programmatic abuse of temporary credentials (CLI, SDK, stolen credentials)
* update boolean field value for aws.cloudtrail.session_credential_from_console
update boolean field value for aws.cloudtrail.session_credential_from_console
* removing filebeat compatibility
removing filebeat compatibility
Tuning based on telemetry from recent rule version 9. There are many false positives for what look like typical S3 storage object names like `BillingInformation`, `InstanceInformation` created by AWS Service accounts. I'm excluding AWS service account types from the rule for now which eliminated ~97% of the false positives over last 30 days. leaving only 66 which is acceptable for this rule and should be addressed via local exclusions.
Co-authored-by: Colson Wilhoit <48036388+DefSecSentinel@users.noreply.github.com>
* [New Rule] AWS SSM Inventory Reconnaissance by Rare User
This rule detects the first time a user or role accesses AWS Systems Manager (SSM) inventory APIs or runs the AWS-GatherSoftwareInventory job. SSM Inventory provides detailed information about managed EC2 instances including installed software, patch compliance, network configurations, and command execution history. Threat actors, including Scattered Spider (LUCR-3), have been observed leveraging these APIs to enumerate targets for lateral movement while blending in with legitimate AWS operations. The rule uses a New Terms approach on cloud.account.id and user.name to identify when users access these reconnaissance APIs for the first time.
No existing rules specifically detect SSM inventory reconnaissance activity. This fills a gap in detecting cloud infrastructure discovery techniques used for target enumeration prior to lateral movement.
| API | Purpose |
|-----|---------|
| `GetInventory` | Query inventory data (installed software, OS details) |
| `GetInventorySchema` | Discover available inventory types |
| `ListInventoryEntries` | Get specific instance inventory |
| `DescribeInstancePatches` | Find patch compliance/vulnerabilities |
| `ListCommands` | View SSM command execution history |
| `CreateAssociation` | Trigger AWS-GatherSoftwareInventory job |
* Apply suggestions from code review
* [New Rule] AWS Sensitive IAM Operations Performed via CloudShell
This rule detects sensitive AWS IAM operations performed via CloudShell based on the user agent string. CloudShell is a browser-based shell that provides command-line access to AWS resources directly from the console without requiring local tooling. When attackers gain access to a compromised console session, CloudShell enables them to perform privileged operations such as creating users, access keys, roles, or attaching policies—leaving no artifacts on their local system. This behavior is documented in the Permiso blog on LUCR-3 (Scattered Spider) and the CISA Scattered Spider advisory, where threat actors leveraged CloudShell for post-compromise credential harvesting and privilege escalation.
No existing rules specifically detect CloudShell as the origin for sensitive IAM operations. This fills a gap by identifying high-risk actions from this browser-based execution context.
* adding iam provider
* primary tactic change
* updating highlighted fields
* removed bold from IG
* Apply suggestions from code review
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
---------
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* [New Rules] AWS IAM new identity federation provider rules
AWS IAM SAML Provider Created and AWS IAM OIDC Provider Created by Rare User detect the creation of new identity federation providers in AWS IAM. SAML and OIDC providers establish trust relationships with external identity providers, enabling federated access to AWS resources. Adversaries who gain administrative access may create rogue providers to establish persistent access that survives credential rotation, allowing them to assume roles using tokens from an IdP they control. These rules map to MITRE ATT&CK T1484.002 (Trust Modification), which is referenced in the CISA Scattered Spider advisory (AA23-320A) under the Privilege Escalation tactic.
Existing Related Coverage: We already detect `UpdateSAMLProvider` via privilege_escalation_iam_saml_provider_updated.toml. These new rules close the gap by detecting the creation of federation providers, the initial step required to establish rogue trust relationships.
* Update rules/integrations/aws/persistence_iam_oidc_provider_created.toml
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
* Update rules/integrations/aws/persistence_iam_oidc_provider_created.toml
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
* Apply suggestion from @imays11
---------
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
* [New Rule] AWS GuardDuty Member Account Manipulation
Detects attempts to manipulate GuardDuty member account relationships within AWS Organizations. This includes actions like `DisassociateFromAdministratorAccount`, `DeleteMembers`, `StopMonitoringMembers`, and `DeleteInvitations` that break centralized security visibility. These actions are often precursors to or alternatives for fully deleting GuardDuty detectors, allowing adversaries to operate undetected in member accounts. The idea for this rule was inspired by defense evasion techniques highlighted in Permiso's research on Scattered Spider, and expanded to include other relevant API calls that could be abused for the same purpose.
Existing Related Coverage: We already detect `DeleteDetector` via defense_evasion_guardduty_detector_deletion.toml. This new rule complements that coverage by catching the manipulation of GuardDuty member relationships, actions that break org-level visibility without requiring full detector deletion.
* toml file name change
* Apply suggestions from code review
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 EC2 Serial Console Access Enabled
Detects when an adversary enables the EC2 Serial Console feature at the AWS account level. This technique was documented by Permiso in their LUCR-3 Scattered Spider research as a defense evasion method that provides out-of-band access to EC2 instances, completely bypassing network-based security monitoring, VPCs, and security groups. Enabling serial console access is extremely rare in production environments, making this a high-signal detection with minimal false positive risk. I've tested this query against alert and prod telemetry and found rare instances.
Existing Related Coverage: We already detect `SendSerialConsoleSSHPublicKey` via lateral_movement_ec2_instance_connect_ssh_public_key_uploaded.toml, which catches the usage of serial console. This new rule closes the gap by detecting the enablement of serial console access, the prerequisite step that must occur before an attacker can leverage this out-of-band channel.
* raising severity and risk score
* [Rule Tuning] Potential AWS S3 Bucket Ransomware Note Uploaded
This rule was very loud in telemetry since it's last tuning. ~8,938 alerts in last 24 hours. All false positives due to regex pattern matches for file names like `enc` as part of /filetransfertmsadherence/ and absence/; `lock` as part of citations-blocks/.
I've reworked this rule based on more research into common ransom note file name keywords and replaced the list here with the most common keywords. For `file` (the most common) and `back`, I was still seeing false positives so decided to alert on a combination of either or these 2 words in conjunction with any of the other words from the list. I also changed the regex to be case-insensitive.
With this new query, I see only true positive results within the last year all from known testing events.
I changed the toml file name so the rule looks new but it is just tuned.
I've updated the description and investigation guide, and added the study I used as a reference: https://www.mdpi.com/2073-431X/10/11/145#computers-10-00145-f002
Test data is in our stack, script for executing is here:
Screenshot of new working query in our test stack
* Apply suggestions from code review
* removing redundany regex pattern
* [Rule Tunings] AWS removal of target.entity.id and actor.entity.id fields
Related Issue : - https://github.com/elastic/security-team/issues/14019
`target.entity.id` and `related.entity.id` fields will soon be fully removed from the AWS Integration. This rule tuning replaces rule queries that relied on `target.entity.id` with the equivalent field `entity.target.id` which was introduced with AWS version 4.7.0 along with several new entity classification fields. This tuning also removes references to these fields in highlighted fields and investigation guides for several rules.
* update data for defense_evasion_route53_dns_query_resolver_config_deletion.toml
update data for defense_evasion_route53_dns_query_resolver_config_deletion.toml
* updated_dates
* [Rule Tunings] AWS remove target.entity.id and actor.entity.id fields
adding min_stack to rules using the field `entity.target.id`, we determined AWS version 4.7.0 is compatible with Kibana versions '^8.19.4 || ^9.1.4'. We reverted the initial PR and this one adds the min_stack_version.
Original PR: - https://github.com/elastic/detection-rules/pull/5563
______
### Issue Link
- https://github.com/elastic/ia-trade-team/issues/781
## Summary - What I changed
`target.entity.id` and `actor.entity.id` fields will soon be fully removed from the AWS Integration. This rule tuning replaces rule queries that relied on `target.entity.id` with the equivalent field `entity.target.id` which was introduced with AWS version 4.7.0 along with several new entity classification fields. This tuning also removes references to these fields in highlighted fields and investigation guides for several rules.
<img width="1622" height="1488" alt="image" src="https://github.com/user-attachments/assets/024fbdb2-c0e4-4785-9735-5285218e4fa9" />
## Rules with Query Changes
**AWS IAM Customer-Managed Policy Attached to Role by Rare User
AWS IAM Assume Role Policy Update**
Both of these rules relied on `target.entity.id` as a new terms field, this field has been replaced with `entity.target.id` field which is populating the same value for the event.actions these rules trigger on, as shown in the screenshot below.
<img width="1600" height="445" alt="Screenshot 2026-01-15 at 12 13 17 PM" src="https://github.com/user-attachments/assets/27e482fe-2a09-4dfb-8337-2e5070422183" />
## How To Test
- recent test data is in our stack for the 2 rules that have changes to their new terms values.
- test scripts for each:
- [trigger_privilege_escalation_iam_customer_managed_policy_attached_to_role.py](https://github.com/elastic/elastic-aws-ruleset-testing/blob/main/IAM/trigger_privilege_escalation_iam_customer_managed_policy_attached_to_role.py)
- [trigger_privilege_escalation_update_assume_role_policy.py](https://github.com/elastic/elastic-aws-ruleset-testing/blob/main/IAM/trigger_privilege_escalation_update_assume_role_policy.py)
* [Rule Tunings] AWS removal of target.entity.id and actor.entity.id fields
Related Issue : - https://github.com/elastic/security-team/issues/14019
`target.entity.id` and `related.entity.id` fields will soon be fully removed from the AWS Integration. This rule tuning replaces rule queries that relied on `target.entity.id` with the equivalent field `entity.target.id` which was introduced with AWS version 4.7.0 along with several new entity classification fields. This tuning also removes references to these fields in highlighted fields and investigation guides for several rules.
* update data for defense_evasion_route53_dns_query_resolver_config_deletion.toml
update data for defense_evasion_route53_dns_query_resolver_config_deletion.toml
* updated_dates
Completing the Deprecation process for these rules as they have been shipped at least 2 release cycles with "Deprecated - " prefix.
All have the following metadata changes
maturity = "deprecated"
updated_date = "2026/01/16"
deprecation_date = "2026/01/16"
- Removing the genAI disclaimer for the AWS ruleset Investigation guides which were all manually modified during the most recent audit.
- Removing any numbering in the investigation guides to maintain better consistency across guides
- Fixed any spacing inconsistencies
* [Rule Tuning] AWS Service Quotas Multi-Region GetServiceQuota Requests
This rule is alerting as expected with very few instances in telemetry (only have data from 1 cluster).
- added more fields for context in the query.
- added metadata fields to query
- reduced execution window
- added highlighted fields
#### screenshot of working query with additional context
* Update rules/integrations/aws/discovery_servicequotas_multi_region_service_quota_requests.toml
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
---------
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
This rule is triggering as expected with moderate telemetry volume (high spikes for what looks like expected cleanup jobs) in specific cluster. No changes needed to the rule query.
- updated description, FP and IG
- reduced execution window
- updated highlighted fields
### AWS Config Resource Deletion
- added exclusions for services that perform Config modifications by design, reducing noise by 97% over the last 30 days.
- added success criteria to query as well
- increased severity to medium as this alert should be triaged
- updated description, false positive and investigation guide sections
- reduced execution window
- updated MITRE
- updated tags
- added highlighted fields
### AWS Configuration Recorder Stopped
no major query changes needed for this rule, performing as expected in telemetry with low volume as this is more rare activity.
- updated description, false positive and investigation guide sections
- reduced execution window
- updated MITRE
- updated tags
- added highlighted fields
* [Rule Tunings] AWS Lambda Rules
#### AWS Lambda Layer Added to Existing Function
This rule was missing alerts for the `UpdateFunctionConfiguration` action due to a missing wildcard.
- added missing wildcard to query
- reduced execution window
- updated description, FP and IG sections
- added highlighted fields
#### AWS Lambda Function Policy Updated to Allow Public Invocation
- changed this query to use EQL instead of KQL to optimize wildcard usage
- uses `event.type` as `event_category_override`
- reduced execution window
- updated description, FP and IG sections
- added highlighted fields
* Update rules/integrations/aws/persistence_lambda_backdoor_invoke_function_for_any_principal.toml
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
---------
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
There was a mistake in the query for this rule. It was looking for `event.provider: eventbridge.amazonaws.com` instead of `events.amazonaws.com`. So we have no existing telemetry for this rule. However, I have tested the behavior properly and ensured the new query does alert as expected. I will monitor this rule in telemetry moving forward to gauge it's performance.
- query change `event.provider: events.amazonaws.com`
- reduced execution window
- updated description, FP and IG sections
- updated tags
- added highlighted fields
* [Rule Tuning] AWS CLI with Kali Linux Fingerprint Identified
This rule is performing well in telemetry as expected. I changed this to EQL to avoid the multiple wildcards needed with KQL.
- changed rule type to EQL
- reduced execution window
- updated description, false positive and investigation guide
Script for testing this rule:
Manually perform any action against our AWS account using Kali Linux distribution
#### Screenshot showing working EQL query, still captures the BitPanda behavior this rule was initially designed around.
* add highlighted fields
add highlighted fields
* Update initial_access_kali_user_agent_detected_with_aws_cli.toml
I reduced the history window for new terms rules that were either:
- `now-14 days`
- showing slow performance metrics
There are still several AWS rules with a `now-10d` window but they are not showing any performance issues so I'd like to leave them as is for now.
First Time Seen AWS Secret Value Accessed in Secrets Manager
- removed `BatchGetSecretValue` API call since this calls `GetSecretValue`
- removed the user_agent exclusions from this one, too easy to bypass.
AWS EC2 User Data Retrieval for EC2 Instance
- excluded more benign AWS services from telemetry
AWS IAM Assume Role Policy Update
- removed use of cloudformation exclusion, this should be captured as well
* [Tuning] Windows BruteForce Rules Tuning
#1 Multiple Logon Failure from the same Source Address: converted to ES|QL and raised the threshold to 100 failed auths, alert quality should be better since it aggregates all failed auths info into one alert vs multiple EQL matches. (expected reduction more than 50%)
#2 Privileged Account Brute Force - coverted to ESQL and set the threshold to 50 in a minute. this should drop noise volume by more than 50%.
* ++
* Update execution_shell_evasion_linux_binary.toml
* Update execution_shell_evasion_linux_binary.toml
* Update defense_evasion_indirect_exec_forfiles.toml
* Update lateral_movement_remote_file_copy_hidden_share.toml
* Update lateral_movement_remote_file_copy_hidden_share.toml
* Update persistence_service_windows_service_winlog.toml
* Update credential_access_lsass_openprocess_api.toml
* Update persistence_suspicious_scheduled_task_runtime.toml
* Update impact_hosts_file_modified.toml
* Update defense_evasion_process_termination_followed_by_deletion.toml
* Update rules/windows/credential_access_lsass_openprocess_api.toml
* Update rules/windows/credential_access_bruteforce_admin_account.toml
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
* Update rules/windows/credential_access_lsass_openprocess_api.toml
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
* Update rules/windows/credential_access_bruteforce_multiple_logon_failure_same_srcip.toml
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
* Update credential_access_lsass_openprocess_api.toml
* Update impact_hosts_file_modified.toml
* Update credential_access_dollar_account_relay.toml
* Update credential_access_new_terms_secretsmanager_getsecretvalue.toml
---------
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
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
Terrance DeJesus