* [New] Kubernetes Static Pod Manifest File Access
The kubelet watches this directory for static pod manifests, a newly dropped manifest can schedule privileged workloads, maintain persistence across kubelet restarts, or tamper with control plane components on affected nodes. Unexpected creations should be reviewed alongside process ancestry and cluster context.
* Update persistence_kubernetes_static_pod_manifest_path_process_execution.toml
* Update persistence_kubernetes_static_pod_manifest_path_process_execution.toml
* ++
* Update persistence_kubernetes_static_pod_manifest_file_creation.toml
* Update persistence_kubernetes_static_pod_manifest_path_process_execution.toml
* Delete rules/integrations/cloud_defend/persistence_kubernetes_static_pod_manifest_file_creation.toml
(cherry picked from commit 73b821198f)
* [New/Tuning] Potential Privilege Escalation via unshare Followed by Root Process
Detects a short sequence where a non-root user performs unshare-related namespace activity (often associated with user namespace privilege escalation primitives) and then a root process is executed shortly after. This can indicate a successful local privilege escalation attempt or suspicious namespace manipulation.
* Update privilege_escalation_unshare_to_root_process_auditd_sequence.toml
* Update rules/linux/privilege_escalation_unshare_to_root_process_auditd_sequence.toml
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
* Update privilege_escalation_unshare_to_root_process_auditd_sequence.toml
---------
Co-authored-by: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com>
(cherry picked from commit af50447032)
* [New] Kubernetes and Cloud Credential Path Access via Process Arguments
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 credential_access_kubernetes_and_cloud_credential_paths_via_process_args.toml
* Apply suggestion from @imays11
Co-authored-by: Isai <59296946+imays11@users.noreply.github.com>
---------
Co-authored-by: Isai <59296946+imays11@users.noreply.github.com>
(cherry picked from commit 87a88628ee)
The double slash // means this exclusion path will never match a real process argument of /opt/tomcat/statistics/statistics.jar.
(cherry picked from commit 36e6f54e43)
* [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
(cherry picked from commit 245956a8d6)
* [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>
Removed changes from:
- rules/integrations/cloud_defend/execution_kubeletctl_execution.toml
- rules/integrations/cloud_defend/execution_potential_direct_kubelet_access_via_process_args.toml
(selectively cherry picked from commit 83406d8ce1)
* [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>
(cherry picked from commit bf49a90eb0)
* [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>
(cherry picked from commit 838e926058)
* [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>
(cherry picked from commit 80f3ed464c)
* [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
(cherry picked from commit 40213fa041)
* [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>
(cherry picked from commit f0467c8bed)
Ruben Groenewoud