Kubernetes

This rule detects Linux process executions that reference /etc/kubernetes/manifests in process arguments, which may indicate tampering with static pod manifests for persistence or privilege escalation in Kubernetes environments.

This rule detects Linux process executions that access high-value Kubernetes service-account material, kubeconfig or node PKI paths, or common cloud files, potentially indicating credential theft within in-cluster and hybrid environments.

Detects Kubernetes API requests where a user is impersonating a privileged cluster identity such as system:kube-controller-manager, system:admin, system:anonymous, or a member of the system:masters group, potentially leading to privilege escalation and unauthorized access.

Detects potential reconnaissance activity in Kubernetes environments where adversaries or automated scripts attempt to map the environment by rapidly querying multiple API resource kinds, indicative of initial setup before actions like privilege escalation or data exfiltration.

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 namespaces, indicating potential credential access or discovery attempts.

This rule detects Kubernetes audit events where node or pod service accounts are accessing secrets via `get` or `list` operations, which may indicate credential access attempts by attackers sweeping Secret objects for sensitive information.

This rule detects an unusual volume of Kubernetes API get requests against multiple distinct Secret objects from the same client fingerprint, potentially indicating credential access or in-cluster reconnaissance.

Modification of the CoreDNS or kube-dns ConfigMap in the kube-system namespace can lead to cluster-wide DNS poisoning, enabling man-in-the-middle attacks against internal services and the Kubernetes API server.

This rule detects allowed updates to Kubernetes pods/ephemeralcontainers subresource by non-system identities, which can be abused for privilege escalation, lateral movement, or persistence by injecting tooling into running pods.

Detection of non-system identities using the Kubernetes nodes/proxy API to proxy requests through the API server directly to a node's Kubelet, potentially leading to privilege escalation and sensitive information exposure.

Detects creation or approval of a Kubernetes CertificateSigningRequest (CSR) by a non-system identity, indicating an attacker attempting to obtain a long-lived client certificate for persistent cluster access with elevated privileges.

This brief outlines how Linux cgroups, a kernel feature for resource management, can be repurposed to provide valuable telemetry for detecting malicious processes, particularly in systemd, Docker, and Kubernetes environments, aiding in investigations of server compromises.

The Shai-Hulud malware was used in a large-scale software supply-chain attack compromising hundreds of packages across open-source software ecosystems by compromising developer secrets and CI/CD pipelines.

The rule detects the creation of Kubernetes service account tokens through the TokenRequest API by non-system identities, which can be abused to escalate privileges, pivot to cloud resources, or generate persistent tokens, bypassing file system-based detection.

An attacker may deploy a pod within the kube-system namespace in Kubernetes to mimic legitimate system pods and evade detection.

An adversary may delete Kubernetes events to evade detection and hide malicious activity within a Kubernetes environment by removing audit logs.

Detects the creation or modification of Kubernetes Roles or ClusterRoles that grant high-risk permissions, such as wildcard access or RBAC escalation verbs, potentially leading to privilege escalation or unauthorized access within the cluster.

The rule detects when a Kubernetes Role or ClusterRole is patched or updated to grant wildcard verbs and resources, effectively granting cluster-admin-like privileges, which is often a deliberate privilege expansion and could indicate malicious activity.

The rule detects creation, modification, or deletion of Kubernetes MutatingWebhookConfigurations or ValidatingWebhookConfigurations by non-system identities, allowing attackers to inject malicious sidecars, block security tooling, or exfiltrate pod specifications.

This rule detects Kubernetes audit events where a node or pod service account attempts to read secrets directly, which is often a sign of credential access.

This rule detects Kubernetes pod exec API calls using curl or wget to fetch HTTPS URLs, potentially indicating malicious activity such as staging tools or exfiltrating data.

Detects read access to Kubernetes Secrets (`get`/`list`) with a user agent matching a curated set of non-standard or attacker-leaning clients, indicating potential credential access.

Detects an unusual volume of Kubernetes API get requests against multiple distinct Secret objects from the same client fingerprint, potentially indicating credential access or in-cluster reconnaissance.

This rule flags potential reverse shell activity via kubectl exec commands in Kubernetes pods by detecting specific shell and socket idioms within URL-decoded command payloads in Kubernetes audit logs, indicating post-exploitation interactive access and command-and-control.

Detection of Kubernetes Secrets listing from non-loopback clients targeting cluster-wide secrets or sensitive namespaces, potentially indicating unauthorized credential access or discovery.