* [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 privilege_escalation_container_runc_init_effective_root_auditd.toml
* Update privilege_escalation_container_runc_init_effective_root_auditd.toml
* Update privilege_escalation_container_runc_init_effective_root_auditd.toml
* Update privilege_escalation_container_runc_init_effective_root_auditd.toml
* Update privilege_escalation_container_runc_init_effective_root_auditd.toml
* [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] Sensitive Identity File Open by Suspicious Process via Auditd
Detects Auditd opened-file reads on sensitive root and cluster paths (Kubernetes token mounts, kubelet and admin kubeconfig, PKI material, shadow, root SSH keys, root cloud CLI and Docker config) when the process looks like common copy or scripting utilities or the binary runs from temp or run staging. User home paths are excluded so file watches
stay explicit and aligned with auditd:
* ++
* Update credential_access_auditd_sensitive_cloud_and_host_identity_file_open.toml
* Update credential_access_auditd_sensitive_cloud_and_host_identity_file_open.toml
* Update rules/linux/credential_access_auditd_sensitive_cloud_and_host_identity_file_open.toml
Co-authored-by: Terrance DeJesus <99630311+terrancedejesus@users.noreply.github.com>
* Apply suggestion from @imays11
Co-authored-by: Isai <59296946+imays11@users.noreply.github.com>
* Apply suggestion from @Mikaayenson
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@users.noreply.github.com>
---------
Co-authored-by: Terrance DeJesus <99630311+terrancedejesus@users.noreply.github.com>
Co-authored-by: Isai <59296946+imays11@users.noreply.github.com>
Co-authored-by: Mika Ayenson, PhD <Mikaayenson@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/Tuning] Chroot Execution in Container Context on Linux
New rule compatible with auditd and ED using process.title and process.entry_leader.entry_meta.type and tuned an existing one (bum-up severity to high).
* Update rules/linux/privilege_escalation_chroot_execution_container_context.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 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] Unusual Process Connection to Docker or Containerd Socket
Detects a process connecting to a container runtime Unix socket (containerd or Docker) that is not a known legitimate runtime component. Direct access to the container runtime socket allows an attacker to create, exec into, or manipulate containers without going through the Kubernetes API server, bypassing RBAC, admission webhooks, pod security standards, and Kubernetes audit logging entirely.
* Update discovery_unusual_process_connection_to_container_runtime_socket.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] 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
yuriShafet