* [New/Tuning] Direct Kubelet API Access rules
- tuned existing rule for D4C to bump-up severity to high (low FP and very susp behavior) + added 10255 port and wss url.
- duplicated same rule logic for auditd/endpoint compatibility for both 10250 port in args and kubeletctl exec.
- added a new one using network event vs process argument for more resilience.
* ++
* Update discovery_potential_direct_kubelet_access_via_process_args.toml
* Update and rename discovery_potential_direct_kubelet_access_via_process_args.toml to lateral_movement_direct_kubelet_access_via_process_args.toml
* Update rules/linux/lateral_movement_direct_kubelet_access_via_process_args.toml
Co-authored-by: Isai <59296946+imays11@users.noreply.github.com>
* Update rules/linux/discovery_potential_kubeletctl_execution.toml
Co-authored-by: Isai <59296946+imays11@users.noreply.github.com>
* Update discovery_potential_kubeletctl_execution.toml
* Update lateral_movement_kubelet_api_connection_attempt_internal_ip.toml
* Apply suggestion from @Aegrah
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
* Apply suggestion from @Aegrah
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
---------
Co-authored-by: Isai <59296946+imays11@users.noreply.github.com>
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
* [New] Kubernetes Secret get or list via Scripting or Generic HTTP Client
After obtaining Kubernetes API credentials, adversaries often reach for generic HTTP stacks and scripting runtimes (curl, wget, Python requests, Go’s default client, and similar) instead of kubectl or in-cluster controllers that advertise purpose-built user agents. Those clients are easy to drive from a stolen kubeconfig, a compromised bastion, or a reverse shell and are commonly used to enumerate or download Secret objects (tokens, registry credentials, TLS material, application keys).
* ++
* Update credential_access_kubernetes_secret_access_scripting_http_clients.toml
* [New/Tuning] K8 RBAC Privs
- new rule with high severity for wildcards for both verb/resource
- added responseObject to an existing rule as on my testing it did not trigger on requestObject (unknown type of on EKS logs), also added few sensitive resources and adjusted logic to ignore list/get on things like roles/clusterroles etc.
* ++
* Rename persistence_kubernetes_role_patch_wildcard_verbs_resources_response.toml to privilege_escalation_role_patch_wildcard_verbs_resources_response.toml
* Update and rename privilege_escalation_role_patch_wildcard_verbs_resources_response.toml to privilege_escalation_role_patch_wildcard_verbs_resources_response.toml
* Update privilege_escalation_role_patch_wildcard_verbs_resources_response.toml
* Update privilege_escalation_role_patch_wildcard_verbs_resources_response.toml
* Update persistence_sensitive_role_creation_or_modification.toml
* Update persistence_sensitive_role_creation_or_modification.toml
* Update privilege_escalation_role_patch_wildcard_verbs_resources_response.toml
* [New] Nsenter to PID 1 Namespace via Auditd
we have an existing rule https://github.com/elastic/detection-rules/blob/0f521a0848420844f3af383f1dee8481d41b2e5b/rules/linux/privilege_escalation_docker_escape_via_nsenter.toml#L15 (compatible only with Elastic Defend `process.entry_leader.entry_meta.type == "container"`).
This rule is compatible with the auditd integration and scoped to Init/systemd PID namespace commonly targeted for container escape.
* Create privilege_escalation_nsenter_execution_inside_container.toml
* Update privilege_escalation_auditd_nsenter_target_host_pid.toml
* Update privilege_escalation_auditd_nsenter_target_host_pid.toml
* Update privilege_escalation_auditd_nsenter_target_host_pid.toml
* Update privilege_escalation_auditd_nsenter_target_host_pid.toml
* Update rules/linux/privilege_escalation_auditd_nsenter_target_host_pid.toml
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* Update privilege_escalation_nsenter_execution_inside_container.toml
* Update privilege_escalation_auditd_nsenter_target_host_pid.toml
---------
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* [New] Kubernetes Secret get or list from Node or Pod Service Account
Kubernetes audit identities for kubelet (`system:node:*`) and workloads (`system:serviceaccount:*`) are meant to operate with tight, predictable API usage. Direct `get` or `list` on the Secrets API from those principals is
often a sign of credential access.
* Update credential_access_kubernetes_secret_read_by_node_or_pod_service_account.toml
* Update credential_access_kubernetes_secret_read_by_node_or_pod_service_account.toml
* [New] Kubernetes Secrets List Across Cluster or Sensitive Namespaces
Detects `list` operations on Kubernetes Secrets from a non-loopback client when the request URI targets cluster-wide secrets or list operations under `kube-system` or `default`. Useful for spotting broad secret enumeration from remote clients.
* Update credential_access_kubernetes_secrets_list_cluster_and_sensitive_namespaces.toml
* Update credential_access_kubernetes_secrets_list_cluster_and_sensitive_namespaces.toml
* Update rules/integrations/kubernetes/credential_access_kubernetes_secrets_list_cluster_and_sensitive_namespaces.toml
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
---------
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
* [New] Kubernetes Rapid Secret GET Activity Against Multiple Objects
Detects multiple k8 get secret calls for unique secret names in a short period of time (rule interval default to every 5m):
* Update credential_access_kubernetes_multiple_secret_retrieval_burst.toml
* Update credential_access_kubernetes_multiple_secret_retrieval_burst.toml
* Update credential_access_kubernetes_multiple_secret_retrieval_burst.toml
* Update credential_access_kubernetes_multiple_secret_retrieval_burst.toml
* [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] 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 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
Samirbous