* [New] AWS Lateral Movement from Kubernetes SA via AssumeRoleWithWebIdentity
Detects when credentials issued through `AssumeRoleWithWebIdentity` for a Kubernetes service account identity are later used for several distinct AWS control-plane actions on the same session access key. Workloads that use EKS IAM Roles for Service Accounts routinely exchange a projected service-account token for short-lived IAM credentials; this rule highlights sessions where that exchange is followed by a spread of sensitive APIs—reconnaissance, secrets and parameter
access, IAM changes, or compute creation—beyond what routine pod traffic usually shows.
* Update initial_access_assumed_web_identity_session_with_multi_phase_api_use.toml
* Update and rename initial_access_assumed_web_identity_session_with_multi_phase_api_use.toml to lateral_movement_k8_assumed_web_identity_session_with_multi_phase_api_use.toml
* Create initial_access_assume_role_with_web_identity_kubernetes_sa_from_external_asn.toml
* Update initial_access_assume_role_with_web_identity_kubernetes_sa_from_external_asn.toml
* Update initial_access_assume_role_with_web_identity_kubernetes_sa_from_external_asn.toml
* Update initial_access_assume_role_with_web_identity_kubernetes_sa_from_external_asn.toml
* [New] Potential Privilege Escalation in Container via Runc Init
Identifies audit events for `runc init` child processes where the effective user is root and the login user ID is not root. This pattern can indicate privilege escalation or credential separation abuse inside container runtimes, where a process executes with elevated effective privileges while retaining a non-root audit identity.
* Update rules/linux/privilege_escalation_container_runc_init_effective_root_auditd.toml
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* Delete rules/linux/privilege_escalation_container_runc_init_effective_root_auditd.toml
* Update rules/integrations/aws/initial_access_assume_role_with_web_identity_kubernetes_sa_from_external_asn.toml
Co-authored-by: Isai <59296946+imays11@users.noreply.github.com>
* Apply suggestion from @imays11
Co-authored-by: Isai <59296946+imays11@users.noreply.github.com>
* Update rules/integrations/aws/lateral_movement_k8_assumed_web_identity_session_with_multi_phase_api_use.toml
Co-authored-by: Isai <59296946+imays11@users.noreply.github.com>
* Update rules/integrations/aws/lateral_movement_k8_assumed_web_identity_session_with_multi_phase_api_use.toml
Co-authored-by: Isai <59296946+imays11@users.noreply.github.com>
* Update rules/integrations/aws/initial_access_assume_role_with_web_identity_kubernetes_sa_from_external_asn.toml
Co-authored-by: Terrance DeJesus <99630311+terrancedejesus@users.noreply.github.com>
* Apply suggestion from @terrancedejesus
Co-authored-by: Terrance DeJesus <99630311+terrancedejesus@users.noreply.github.com>
* Apply suggestion from @terrancedejesus
Co-authored-by: Terrance DeJesus <99630311+terrancedejesus@users.noreply.github.com>
* Update lateral_movement_k8_assumed_web_identity_session_with_multi_phase_api_use.toml
---------
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
Co-authored-by: Isai <59296946+imays11@users.noreply.github.com>
Co-authored-by: Terrance DeJesus <99630311+terrancedejesus@users.noreply.github.com>
* [New] Suspicious SUDI Binary Execution
Detects execution of common privilege elevation helpers (su, sudo, pkexec, passwd, chsh, newgrp) under the root effective user when the real user and parent user are not root, combined with minimal argument counts and suspicious parent context (interpreters, short shell -c invocations, or parents running from user-writable paths) :
* Update rules/linux/privilege_escalation_suspicious_sudi_binary_execution.toml
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
* Update rules/linux/privilege_escalation_suspicious_sudi_binary_execution.toml
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
* Update privilege_escalation_suspicious_sudi_binary_execution.toml
* Update privilege_escalation_suspicious_sudi_binary_execution.toml
* Rename privilege_escalation_suspicious_sudi_binary_execution.toml to privilege_escalation_suspicious_suid_binary_execution.toml
* Update privilege_escalation_suspicious_suid_binary_execution.toml
* Update privilege_escalation_suspicious_suid_binary_execution.toml
---------
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
* [New] AWS Credentials Used from GitHub Actions and Non-CI/CD Infrastructure
Detects AWS access keys that are used from both GitHub Actions CI/CD infrastructure and non-CI/CD infrastructure. This pattern indicates potential credential theft where an attacker who has stolen AWS credentials configured as GitHub Actions secrets and is using them from their own infrastructure.
* Update initial_access_github_actions_oidc_credentials_used_from_suspicious_network.toml
* ++
* Update initial_access_github_actions_oidc_credentials_used_from_suspicious_network.toml
---------
Co-authored-by: shashank-elastic <91139415+shashank-elastic@users.noreply.github.com>
* [New] AWS Rare Source AS Organization Activity
Surfaces an AWS identity whose successful API traffic is dominated by a small set of large cloud-provider source AS organization labels, yet also shows a very small share of traffic from other AS organization names—including at least one sensitive control-plane, credential, storage, or model-invocation action on that uncommon network path with recent
activity from the uncommon path. The intent is to highlight disproportionate “baseline” cloud egress versus sparse use from rarer networks on the same principal, a shape that can appear when automation or CI credentials are reused or pivoted outside their usual hosted-cloud footprint.
* Apply suggestion from @eric-forte-elastic
Co-authored-by: Eric Forte <119343520+eric-forte-elastic@users.noreply.github.com>
* Update initial_access_aws_api_unusual_asn.toml
* Update initial_access_aws_api_unusual_asn.toml
* Update initial_access_aws_api_unusual_asn.toml
---------
Co-authored-by: Eric Forte <119343520+eric-forte-elastic@users.noreply.github.com>
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
Co-authored-by: shashank-elastic <91139415+shashank-elastic@users.noreply.github.com>
* [New] Long Base64 Encoded Command via Scripting Interpreter
Identifies oversized command lines used by Python, PowerShell, Node.js, or Deno that contain base64 decoding or encoded-command patterns. Adversaries may embed long inline encoded payloads in scripting interpreters to evade inspection and execute malicious content across Windows, macOS, and Linux systems.
* Update defense_evasion_long_base64_encoded_interpreter_command_line.toml
* Update defense_evasion_long_base64_encoded_interpreter_command_line.toml
* [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>
Ruben Groenewoud