* [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
* [New Rule] Okta User Authentication via Proxy Followed by Security Alert
Fixes#5751
* adjusted to EQL
* fixed syntax
* Update rules/integrations/okta/initial_access_first_occurrence_user_session_started_via_proxy.toml
Co-authored-by: Isai <59296946+imays11@users.noreply.github.com>
* removed defense evasion; adjusted maxspan to 30m
* removed Okta tag
* adding Okta back as integration tag
---------
Co-authored-by: Isai <59296946+imays11@users.noreply.github.com>
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>
* [Tuning] Adds host metadata to the setup requirements
Rules requiring host.ip and that are compatible with Elastic Defend integration can be impacting by windows].advanced.set_extended_host_information if set to the default value (false), host.ip won't be populated from 8.18+ (only host.name and host.os and host.id).
Related SDH https://github.com/elastic/sdh-endpoint/issues/722
* ++
* Update rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_process_args.toml
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* Update rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_session_duration.toml
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* Update rules/integrations/lmd/lateral_movement_ml_high_remote_file_size.toml
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* Update rules/integrations/lmd/lateral_movement_ml_high_variance_rdp_session_duration.toml
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* Update rules/integrations/lmd/lateral_movement_ml_rare_remote_file_directory.toml
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* Update rules/integrations/lmd/lateral_movement_ml_unusual_time_for_an_rdp_session.toml
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* Update rules/integrations/lmd/lateral_movement_ml_spike_in_connections_from_a_source_ip.toml
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* Update rules/integrations/lmd/lateral_movement_ml_rare_remote_file_extension.toml
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* Update rules/integrations/lmd/lateral_movement_ml_spike_in_connections_to_a_destination_ip.toml
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* Update lateral_movement_ml_spike_in_rdp_processes.toml
* Apply suggestion from @Mikaayenson
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 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>
* [Rule Tuning] M365 Identity Excessive SSO Login Errors Reported
<!-- This issue will be created in repo elastic/detection-rules (https://github.com/elastic/detection-rules). Changing this line has no effect. -->
Fixes#5676
* adjusted file name
* adjusted message to STS codes; removed generic SAML request andresponse codes
* [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
* Updated kubernetes.audit.requestObject.spec.containers.image type of text to Keyword
* [New Rules] Misc. K8s RBAC Abuse Rules
* --
* Update non-ecs-schema
* Update to make unit tests happy
* Mitre mapping updates
* Fix query logic for service account role bindings
* Fix formatting in persistence_service_account_bound_to_clusterrole rule
* Updated kubernetes.audit.requestObject.spec.containers.image type of text to Keyword
* [Rule Tuning] Dormant & Deprecated Rule Clean-Up
* [Rule Tuning] Dormant & Deprecated Rule Clean-Up
* Few more deprecations
* ++
* Update unit test syntax fix
* Update bad bytes
* ++
* [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)
Ruben Groenewoud