Detects bursts of failed GKE API requests from a single user identity within a five-minute window. Repeated authorization failures across multiple actions can indicate credential stuffing, RBAC probing, or reconnaissance with stolen tokens.

Read More

Detects Kubernetes pod exec sessions whose decoded command line references cloud instance metadata endpoints or equivalent hostnames and paths. Workloads that reach the link-local metadata IP, AWS IMDS paths, GCP computeMetadata, Azure IMDS token routes, or encoded variants are often attempting to harvest role credentials, tokens, or instance attributes from the underlying node or hypervisor boundary. That behavior is high risk in multi-tenant and regulated environments because it can expose short-lived cloud credentials to code running inside a container. The rule classifies a coarse cloud target label and whether the string looks like credential retrieval versus lighter reconnaissance.

Read More

Flags exec into a pod when the URL-decoded command payload resembles reverse-shell or bind-shell one-liners invocation patterns. Legitimate debug sessions sometimes use similar building blocks, but together these patterns align with post-exploitation interactive access and command-and-control.

Read More

Detects Kubernetes pod exec sessions whose decoded command line references high-value host or in-cluster paths and material types: mounted service account or platform tokens, kubelet and control-plane configuration areas, host identity stores, root dot-directories for cloud and kubeconfig material, common private-key and keystore extensions, process environment dumps, and configuration filenames suggestive of embedded secrets. The intent is to catch interactive or scripted access that often precedes lateral movement, privilege escalation, or credential theft from the node or workload boundary. A narrow exclusion ignores benign reads of resolv.conf. The query also labels an access_type bucket to speed triage without altering the detection predicates you validated.

Read More

Detects pod or attach exec API calls where the decoded request query implies curl or wget fetching an https URL. Attackers with permission to exec into workloads often run one-liners to stage tooling, pull scripts or binaries, or exfiltrate data over HTTPS—activity that should be rare compared to shells, debuggers, or expected health checks. The rule decodes the audit requestURI, reconstructs a readable command string from repeated command parameters, and applies noise filters for common cluster health and OIDC/JWKS endpoints so benign automation is less likely to alert.

Read More

This rule detects the use of system search utilities like grep and find to search for AWS credentials inside a container. Unauthorized access to these sensitive files could lead to further compromise of the container environment or facilitate a container breakout to the underlying cloud environment.

Read More

Detects when the AmazonEKSClusterAdminPolicy or AmazonEKSAdminPolicy is associated with a principal via the EKS Access Entries API. This grants full cluster-admin equivalent access to the specified IAM user or role. Unlike the legacy aws-auth ConfigMap which is only visible in Kubernetes audit logs, Access Entries modifications appear in CloudTrail, providing an additional detection surface. Attackers who have obtained IAM permissions to manage EKS access entries can use this API to backdoor cluster access for persistence, mapping attacker-controlled IAM identities to cluster-admin privileges without modifying any Kubernetes resources.

Read More

Detects successful Amazon EKS Access Entries API operations that create, update, attach, detach, or delete authentication mappings between IAM principals and the cluster. Changes to access entries alter who can authenticate to Kubernetes and what Kubernetes-level permissions they receive, without requiring edits to in-cluster RBAC objects. Unexpected callers or timing may indicate persistence or privilege abuse. Common automation identities (service-linked roles, eksctl, Terraform, CloudFormation role patterns) are excluded to reduce noise; tune further for your deployment pipelines.

Read More

Detects successful Amazon EKS UpdateClusterConfig requests that disable control plane logging. Disabling EKS API server and control plane logs can reduce visibility into cluster activity and may indicate defense evasion following compromised AWS credentials or unauthorized administrative access. EKS control plane logging changes are typically rare and should align with approved maintenance or cost optimization workflows.

Read More

Detects a non-system identity using the AKS (Azure Kubernetes Service) API server nodes/proxy subresource to reach a node's Kubelet. Proxying through the API server reaches the Kubelet API to enumerate pods or run commands on nodes, a lateral-movement and privilege-escalation vector (kubeletctl, Peirates). Node, control-plane, and kube-system service account identities that routinely proxy for monitoring are excluded, so remaining matches, including compromised workload service accounts, are surfaced for review.

Read More

Detects an AKS (Azure Kubernetes Service) identity establishing an exec session into a pod. Interactive command execution inside a workload via kubectl exec is a common post-compromise technique used to access secrets, run tooling, and expand access from a foothold container. Node, control-plane, and kube-system service account identities are excluded, so workload service accounts and users, the identities an adversary is most likely to abuse, remain in scope.

Read More

Detects an identity creating a client-authentication CertificateSigningRequest (signer kubernetes.io/kube-apiserver-client) or approving a CSR on AKS (Azure Kubernetes Service), excluding node bootstrap and platform controllers. Adversaries submit and self-approve a CSR against the kube-apiserver-client signer to mint a long-lived client certificate for an arbitrary subject (for example a Common Name in system:masters), giving durable authenticated access that survives token revocation. Coverage includes workload service accounts (system:serviceaccount:*), so a compromised in-cluster token forging a certificate is not excluded.

Read More

Detects an identity creating or modifying the CoreDNS or kube-dns ConfigMap in the kube-system namespace on AKS (Azure Kubernetes Service), excluding known AKS control-plane and platform identities. Rewriting cluster DNS (by editing coredns/kube-dns or creating and editing coredns-custom) enables cluster-wide adversary-in-the-middle by redirecting internal service resolution to attacker-controlled IPs, allowing credential capture and traffic interception. Coverage includes workload service accounts (system:serviceaccount:*), so a compromised in-cluster token is not excluded.

Read More

Detects an identity injecting an ephemeral (debug) container into a running AKS (Azure Kubernetes Service) pod via the pods/ephemeralcontainers subresource, excluding known AKS control-plane and platform identities. Ephemeral containers share the target pod's namespaces and give stealthy interactive access to its processes and mounted secrets without creating a new pod. Coverage includes workload service accounts (system:serviceaccount:*), so a compromised in-cluster token used to attach a debug container is not excluded.

Read More

Detects use of the AKS (Azure Kubernetes Service) API server nodes/proxy subresource to reach a node's Kubelet command-execution endpoints (run, exec, attach, portforward, cri). Unlike benign monitoring that scrapes /metrics and /stats, a request to these endpoints executes commands inside a pod on the node, the core of the kubeletctl and Peirates lateral-movement technique. Even a GET to /exec is command execution because the Kubelet maps the WebSocket upgrade handshake to the RBAC get verb, so nodes/proxy GET is sufficient for remote code execution.

Read More

Detects an identity deleting Kubernetes events on AKS (Azure Kubernetes Service), excluding known AKS control-plane and platform identities. Adversaries delete events (individually or in bulk via deletecollection) to remove evidence of pod creation, exec, or scheduling activity and impair incident response after operating in the cluster. Coverage includes workload service accounts (system:serviceaccount:*), so a compromised in-cluster token wiping events is not excluded.

Read More

Detects successful AKS pod exec sessions whose command resembles reverse-shell or bind-shell one-liner patterns, including /dev/tcp, /dev/udp and gawk /inet redirection, interactive invocation of any common shell, the netcat and ncat exec/listener forms, socat command-execution and listener addresses, mkfifo and mknod pipelines, socket idioms across Python, Perl, PHP, Ruby, Lua and Node, and tooling such as gsocket, openssl s_server and xterm. Legitimate debug sessions sometimes use similar building blocks, but together these patterns align with post-exploitation interactive access and command-and-control.

Read More

Detects a single Kubernetes identity in AKS (Azure Kubernetes Service) that is denied (HTTP 403 Forbidden) across multiple distinct API resource types within a short window. Broad authorization failures spanning many resources are a strong signal of API enumeration (reconnaissance with a stolen service account token), as an actor probes what its credentials can reach before privilege escalation. Detection is based on the breadth of denied resources rather than the raw failure count, so single-resource controller retry loops do not trigger it.

Read More

Detects successful AKS (Azure Kubernetes Service) secret get or list operations where the user agent matches scripting runtimes (python, ruby, perl), command-line HTTP clients (curl, wget, HTTPie), or generic HTTP libraries (Go-http-client, okhttp, Apache-HttpClient, Guzzle, axios, undici) rather than typical kubectl or named controller traffic. Reading Kubernetes secrets with a generic client is a common credential-access step after a token or kubeconfig is stolen, and offensive tooling (for example peirates and kdigger) frequently reaches the API with a default Go HTTP client.

Read More

Detects an identity minting a service account token via the AKS (Azure Kubernetes Service) TokenRequest API (serviceaccounts/token), excluding known AKS control-plane and platform identities. Adversaries request service account tokens from a compromised identity to impersonate a workload, move laterally, or escalate privileges within the cluster. Coverage includes workload service accounts (system:serviceaccount:*), so a compromised in-cluster token minting a token for another service account is not excluded.

Read More

Detects AKS (Azure Kubernetes Service) service account or node identities invoking self-subject access or rules review APIs. Non-human identities rarely enumerate their own permissions outside known controllers; this can indicate stolen tokens probing effective RBAC before privilege escalation.

Read More

Identifies when events are deleted in Azure Kubernetes. Kubernetes events are objects that log any state changes. Example events are a container creation, an image pull, or a pod scheduling on a node. An adversary may delete events in Azure Kubernetes in an attempt to evade detection.

Read More

Identifies the deletion of Azure Kubernetes Pods. Adversaries may delete a Kubernetes pod to disrupt the normal behavior of the environment.

Read More

Identifies the creation of role binding or cluster role bindings. You can assign these roles to Kubernetes subjects (users, groups, or service accounts) with role bindings and cluster role bindings. An adversary who has permissions to create bindings and cluster-bindings in the cluster can create a binding to the cluster-admin ClusterRole or to other high privileges roles.

Read More

This rule detects when chroot is executed inside a container. Chroot is a Linux utility that allows a user to run a command in a different directory. This can be used to escape a container and gain access to the host system.

Read More

Detects chroot execution on Linux when the process appears to run in a container-oriented context: the process title matches runc init, the entry leader is a container workload, or the parent process is runc. Chroot from inside a container can pivot to an alternate root filesystem and is a common step in container breakout attempts when combined with sensitive host mounts.

Read More

This rule detects the use of system search utilities like grep and find to search for AWS credentials inside a container. Unauthorized access to these sensitive files could lead to further compromise of the container environment or facilitate a container breakout to the underlying cloud environment.

Read More

This rule detects when a container management binary is run from inside a container. These binaries are critical components of many containerized environments, and their presence and execution in unauthorized containers could indicate compromise or a misconfiguration.

Read More

This rule detects when a container management binary is run from inside a container. These binaries are critical components of many containerized environments, and their presence and execution in unauthorized containers could indicate compromise or a misconfiguration.

Read More

Detects execution of container runtime CLI tools (ctr, crictl, nerdctl) with arguments indicating container creation, command execution inside existing containers, image manipulation, or host filesystem mounting. These tools interact directly with the container runtime socket, bypassing the Kubernetes API server, RBAC authorization, admission webhooks, pod security standards, and Kubernetes audit logging entirely. Attackers with host-level access may use these tools to create privileged ghost containers, exec into other pods to steal service account tokens and secrets, pull attacker-controlled images, and destroy evidence, all while remaining invisible to Kubernetes-level monitoring.

Read More

Generates a detection alert each time a 'Container Workload Protection' alert is received. Enabling this rule allows you to immediately begin triaging and investigating these alerts.

Read More

Detects execution of curl or wget from processes whose title aligns with runc init, a common fingerprint for workloads running inside OCI/runc-backed containers on Linux hosts instrumented with Auditd Manager. After breaking out of an application container or abusing a privileged workload, attackers often pull ingress tooling (stagers, scripts, implants) or stage exfiltration with minimal HTTP clients. Those utilities are also used benignly in images, so context matters; the runc init anchor narrows the signal to the container runtime boundary where unexpected download clients are more worthy of review than the same binaries on a bare-metal admin shell.

Read More

This rule detects the use of the "curl" command-line tool with SOCKS proxy options. Attackers may use "curl" to establish a SOCKS proxy connection to bypass network restrictions and exfiltrate data or communicate with C2 servers.

Read More

This rule detects the use of the built-in Linux DebugFS utility from inside a privileged container. DebugFS is a special file system debugging utility which supports reading and writing directly from a hard drive device. When launched inside a privileged container, a container deployed with all the capabilities of the host machine, an attacker can access sensitive host level files which could be used for further privilege escalation and container escapes to the host machine.

Read More

This rule detects the execution of a base64 decoded payload to an interpreter inside a container. Attackers may use this technique to execute malicious code, while attempting to evade detection.

Read More

This rule leverages a combination of Defend for Containers and Kubernetes audit logs to detect the execution of direct interactive Kubernetes API requests. An adversary may need to execute direct interactive Kubernetes API requests to gain access to the Kubernetes API server or other resources within the cluster. These requests are often used to enumerate the Kubernetes API server or other resources within the cluster, and may indicate an attempt to move laterally within the cluster. Note that this rule may not trigger if the authorization token of the request is expanded within the process argument list, as the length of the "process.args" field may lead to the field being ignored.

Read More

This rule leverages a combination of Defend for Containers and Kubernetes audit logs to detect the execution of direct interactive Kubernetes API requests via unusual utilities. An adversary may need to execute direct interactive Kubernetes API requests to gain access to the Kubernetes API server or other resources within the cluster. These requests are often used to enumerate the Kubernetes API server or other resources within the cluster, and may indicate an attempt to move laterally within the cluster.

Read More

This rule detects the execution of direct Kubernetes API requests inside a container. An adversary may need to execute direct Kubernetes API requests to gain access to the Kubernetes API server or other resources within the cluster. These requests are often used to enumerate the Kubernetes API server or other resources within the cluster, and may indicate an attempt to move laterally within the cluster. Note that this rule may not trigger if the token is expanded within the process argument list, as the length of the "process.args" field may lead to the field being ignored.

Read More

This rule detects the execution of DNS enumeration tools inside a container. DNS enumeration tools are used to enumerate the DNS servers and domains of the container, which can be used by an adversary to gain information about the network configuration of the container and the services running inside it.

Read More

This rule detects the creation of files named release_agent or notify_on_release, which are commonly associated with the abuse of Linux cgroup release mechanisms. In Docker or containerized environments, this behavior may indicate an attempt to exploit privilege escalation vulnerabilities such as CVE-2022-0492, where attackers use the release_agent feature to execute code on the host from within a container.

Read More

This rule detects potential Docker socket enumeration activity by monitoring processes that attempt to interact with the Docker socket file (/var/run/docker.sock). Docker socket enumeration is a common technique used by attackers to interact with the Docker daemon and perform various operations, such as creating, starting, stopping, and removing containers. Attackers may abuse Docker socket enumeration to gain unauthorized access to the host system, escalate privileges, or move laterally within the environment.

Read More

This rule detects the creation or modification of the dynamic linker preload shared object (ld.so.preload) inside a container. The Linux dynamic linker is used to load libraries needed by a program at runtime. Adversaries may hijack the dynamic linker by modifying the /etc/ld.so.preload file to point to malicious libraries. This behavior can be used to grant unauthorized access to system resources and has been used to evade detection of malicious processes in container environments.

Read More

This rule identifies a sequence of events where a process named "entrypoint.sh" is started in a container, followed by a network connection attempt. This sequence indicates a potential egress connection from an entrypoint in a container. An entrypoint is a command or script specified in the Dockerfile and executed when the container starts. Attackers can use this technique to establish a foothold in the environment, escape from a container to the host, or establish persistence.

Read More

Detects modifications to the aws-auth ConfigMap in Amazon EKS clusters. The aws-auth ConfigMap maps AWS IAM roles and users to Kubernetes RBAC groups, an attacker who modifies it can grant any IAM role cluster-admin access by adding a mapping to the system:masters group. This is a well-documented persistence technique that survives pod restarts, node replacements, and RBAC changes because the authentication mapping exists outside of normal Kubernetes Role objects. Modifications to aws-auth are rare in normal operations, the ConfigMap is typically set during cluster provisioning and updated only during node group or access configuration changes.

Read More

This rule detects the execution of potential defense evasion techniques via encoded payloads inside a container. Attackers may use base64 encoding/decoding to obfuscate data, such as command and control traffic or payloads, to evade detection by host- or network-based security controls.

Read More

This rule detects the execution of the "env" or "printenv" commands inside a container. The "env" command is used to display all the environment variables for the current shell, and the "printenv" command is used to print the values of environment variables. These commands are used to enumerate the environment variables of the container, which can be used by an adversary to gain information about the container and the services running inside it.

Read More

This rule detects 'exec' events launched against a container using the 'exec' command. Using the 'exec' command in a pod allows a user to establish a temporary shell session and execute any process/command inside the container. This rule specifically targets higher-risk commands that allow real-time interaction with a container's shell. A malicious actor could use this level of access to further compromise the container environment or attempt a container breakout.

Read More

This rule detects when a process creates a file inside of a running container, followed by its execution. This could indicate a potential container breakout attempt, an attacker's attempt to gain unauthorized access to the underlying host, or to evade detection by security controls.

Read More

This rule detects the download of files from inside a container. The files are downloaded using the "curl" or "wget" command-line tools. Adversaries may use these tools to download files from the internet to gain access to sensitive data or communicate with C2 servers.

Read More

This rule detects when chmod is used to add the execute permission to a file inside a container. Modifying file permissions to make a file executable could indicate malicious activity, as an attacker may attempt to run unauthorized or malicious code inside the container.

Read More

This rule detects the use of the built-in Linux DebugFS utility from inside a container. DebugFS is a special file system debugging utility which supports reading and writing directly from a hard drive device. When launched inside a privileged container, a container deployed with all the capabilities of the host machine, an attacker can access sensitive host level files which could be used for further privilege escalation and container escapes to the host machine.

Read More

This rule leverages a combination of Defend for Containers and Kubernetes audit logs to detect the execution of forbidden interactive Kubernetes API requests. An adversary may need to execute interactive Kubernetes API requests to gain access to the Kubernetes API server or other resources within the cluster. These requests are often used to enumerate the Kubernetes API server or other resources within the cluster, and may indicate an attempt to move laterally within the cluster. Attackers may attempt to access resources that are forbidden by the authorization policy. Note that this rule may not trigger if the authorization token of the request is expanded within the process argument list, as the length of the "process.args" field may lead to the field being ignored.

Read More

Detects creation or modification of GKE mutating or validating admission webhook configurations by non-system identities. Malicious webhooks can inject workloads, block security tooling, or intercept API traffic for persistence and defense evasion.

Read More

Detects bursts of GKE API requests from an anonymous identity that probe many distinct actions and resources with mostly failed outcomes. This pattern is consistent with unauthenticated permission enumeration against an exposed API server. On GKE GCP audit logs, unauthenticated probes often omit "client.user.email" (null principal) with Unauthorized failures; those events are included alongside "system:anonymous" / "system:unauthenticated".

Read More

Detects create, update, or patch of pods by an unauthenticated anonymous GKE identity. Anonymous pod mutation is a critical misconfiguration signal and a common path for unauthenticated attackers to deploy workloads or maintain access. Includes "system:anonymous" / "system:unauthenticated" and GKE audit rows with a missing principal (seen on unauthenticated Unauthorized/forbidden pod writes).

Read More

Detects successful GKE API requests from unauthenticated anonymous identities using an unusual user agent. Attackers may rely on anonymous access for initial cluster access or to avoid attribution. Matches "system:anonymous" / "system:unauthenticated" and GKE audit rows where the principal is missing (common for unauthenticated clients). Common kube-probe health checks (readyz/livez/healthz/version) are excluded.

Read More

Detects GKE API requests where a caller is impersonating a privileged cluster identity such as system:kube-controller-manager, system:admin, system:anonymous, or a kube-system service account. These identities have broad cluster-wide permissions including unrestricted access to secrets, the ability to create tokens for any service account, schedule pods on any node, and modify RBAC. Impersonating system:kube-controller-manager grants access to secrets across namespaces and service account token minting for lateral movement.

Read More

Detects non-system identities using the GKE nodes/proxy API to reach a node's Kubelet through the API server. The nodes/proxy subresource allows any principal with this permission to call the Kubelet API without direct node network access or Kubelet TLS certificates. Through this path an attacker can list pod specs (including environment secrets), read Kubelet configuration, retrieve container logs, and access running pod metadata on the target node. Monitoring endpoints such as metrics, healthz, and stats/summary are excluded to reduce noise from observability tooling.

Read More

Detects creation of a GKE CertificateSigningRequest (CSR) that requests the kubernetes.io/kube-apiserver-client signer. This signer issues general API client certificates with few subject restrictions, unlike the restricted kubelet signers used for node certificate rotation. Attackers with CSR permissions use this signer to mint long-lived credentials for privileged identities such as system:kube-controller-manager, enabling persistence and privilege escalation that survives token revocation and RBAC changes.

Read More

Detects creation of a GKE CertificateSigningRequest (CSR) whose decoded subject requests a highly privileged Kubernetes identity in the Common Name (CN), such as system:masters, system:kube-controller-manager, or system:admin. This rule is scoped to identities with cluster-admin-equivalent or control-plane impersonation value. Attackers who can create and approve CSRs can use this technique to clone credentials for powerful identities and obtain durable cluster access. This signal applies to any actor, including compromised node identities that use legitimate kubelet signers but request a privileged CN.

Read More

Detects when the same non-system GKE identity creates a CertificateSigningRequest (CSR) and then approves that same CSR within five minutes, consistent with self-approval abuse. Attackers who gain CSR create and approval RBAC can submit a certificate request and approve it themselves to obtain a long-lived client certificate without involving cluster operators, a pattern documented in Kubernetes persistence research and adversary emulation.

Read More

Detects creation or approval of a GKE CertificateSigningRequest (CSR) by a non-system identity. This is a breadth baseline rule for human or custom automation CSR activity on GKE. Attackers with cluster access can submit and approve CSRs to obtain long-lived client certificates that survive token revocation and RBAC changes. Use companion rules to evaluate signer choice, requested identity, and self-approval behavior.

Read More

Detects creation or modification of a GKE ClusterRoleBinding that grants the cluster-admin ClusterRole, providing unrestricted cluster access and enabling rapid privilege escalation or persistence.

Read More

Detects GKE pod creation with dangerous Linux capabilities that are commonly abused in container escape techniques. Standalone pods are included; controller-owned ReplicaSet, DaemonSet, and StatefulSet workloads are excluded.

Read More

Detects modifications to the CoreDNS or kube-dns ConfigMap in the kube-system namespace on GKE. These ConfigMaps control cluster DNS resolution for all pods. An attacker who modifies the CoreDNS Corefile can redirect internal service DNS names to attacker-controlled IP addresses, enabling man-in-the-middle attacks against the Kubernetes API server, database services, and other internal endpoints. Pods that resolve service names via cluster DNS will transparently connect to the attacker instead of the legitimate service, allowing interception of service account tokens, database credentials, and API traffic. DNS poisoning at the cluster level is particularly dangerous because it affects every pod in every namespace simultaneously and does not require any modification to the victim workloads. CoreDNS configuration changes are rare in normal operations and any unexpected modification should be investigated immediately.

Read More

Detects creation of a GKE RoleBinding or ClusterRoleBinding that grants permissions to a ServiceAccount, which may indicate privilege delegation or RBAC misconfiguration leading to elevated access.

Read More

Detects creation or modification of GKE Roles or ClusterRoles that grant high-risk permissions, such as wildcard access or RBAC escalation verbs (bind, escalate, impersonate), which may enable privilege escalation or unauthorized access within the cluster.

Read More

Detects a single authenticated GKE identity from one source IP issuing a burst of API calls across many distinct actions and resources with a mix of successful and failed outcomes. That pattern is consistent with automated RBAC permission enumeration rather than steady-state controller traffic. Anonymous probing is covered by a separate rule.

Read More

Detects allowed updates or patches to the pods/ephemeralcontainers subresource on GKE by a non-system identity. Ephemeral containers are commonly used for debugging (kubectl debug) but can also be abused to inject tooling into a running pod, access mounted secrets, and execute commands in the target pod context. Attackers with sufficient RBAC may use ephemeral containers to escalate privileges, move laterally, or establish persistence without deploying a new workload.

Read More

Detects creation or modification of a GKE Service with type NodePort. NodePort exposes a static port on every worker node that hosts matching pods, which widens the cluster's external attack surface and can bypass load-balancer and firewall controls. Attackers may create NodePort Services to intercept traffic or establish a direct path into the cluster.

Read More

Detects denied GKE API create requests from non-control-plane identities. Failed creates can indicate RBAC probing, stolen credentials with insufficient privileges, or attempts to deploy unauthorized workloads.

Read More

Detects the first occurrence of a failed GKE API request from a previously unseen user agent. Adversary tooling often uses non-standard clients; combined with authorization failures this can indicate RBAC probing or exploitation attempts.

Read More

Adversaries who land credentials in a GKE cluster—or abuse an over-privileged token, often map the environment before exfiltration or privilege escalation. A practical first pass is to learn where workloads run, how the cluster is partitioned, and what RBAC exists at namespace vs cluster scope. Rapid get/list traffic across many distinct API resource kinds that answer those questions (namespaces, workloads, roles, cluster-wide roles) is a common setup and orientation pattern for both interactive attackers and automated recon scripts. This rule highlights that cross-resource burst from a single client fingerprint within a one-minute bucket when both cluster-layout and RBAC resource kinds are touched, so analysts can separate routine automation from potential discovery ahead of follow-on actions.

Read More

Detects GKE pod create, update, or patch events that mount sensitive hostPath volumes such as the root filesystem, kubelet paths, or container runtime sockets. This can enable container escape and credential theft. System identities and controller-owned workloads are excluded.

Read More

Detects GKE pod create, update, or patch events that enable host IPC namespace sharing. This exposes host inter-process communication mechanisms and can support privilege escalation. Controller-owned workloads are excluded.

Read More

Detects GKE pod create, update, or patch events that enable host network namespace sharing. HostNetwork grants access to the node network stack and can bypass namespace network policies. System identities and controller-owned workloads are excluded.

Read More

Detects GKE pod create, update, or patch events that enable host PID namespace sharing. HostPID exposes host processes and can support privilege escalation, especially with ptrace or privileged containers. System identities and controller-owned workloads are excluded.

Read More

Detects successful GKE pod exec sessions whose command references Google Cloud instance metadata endpoints, including metadata.google.internal, computeMetadata/v1, or the link-local metadata IP 169.254.169.254. Workloads that reach the GKE metadata service from an exec session are often attempting to harvest short-lived credentials or instance attributes from the node or workload identity boundary. That behavior is high risk because it can expose cloud credentials to code running inside a container. GKE records the command in gcp.audit.labels.command.gke.io/command when an explicit command is passed to exec.

Read More

Detects successful GKE pod exec sessions whose command resembles reverse-shell or bind-shell one-liner patterns, including /dev/tcp and /dev/udp redirection, netcat/ncat exec-style flags, socat shell handoff, mkfifo pipelines, and common language socket idioms. Legitimate debug sessions sometimes use similar building blocks, but together these patterns align with post-exploitation interactive access and command-and-control. Common localhost /dev/tcp health-check ports are excluded. GKE records the command in gcp.audit.labels.command.gke.io/command when an explicit command is passed to exec.

Read More

Detects successful GKE pod exec sessions where the executed command references high-value host or in-cluster paths: mounted service account or platform tokens, kubelet and control-plane configuration areas, host identity stores, root or home credential directories, common private-key and keystore extensions, process environment dumps, and configuration filenames suggestive of embedded secrets. Attackers with pods/exec often use these one-liners to steal credentials before lateral movement or privilege escalation. A narrow exclusion ignores benign resolv.conf reads. GKE records the command in gcp.audit.labels.command.gke.io/command when an explicit command is passed to exec.

Read More

Detects successful GKE pod exec sessions where the executed command implies curl or wget fetching an HTTPS URL. Attackers with pods/exec often run one-liners to stage tooling, pull scripts or binaries, or exfiltrate data over HTTPS—activity that should be rare compared to shells, debuggers, or expected health checks. Common cluster health, localhost, and OIDC/JWKS endpoint patterns are excluded to reduce benign automation noise. GKE records the command in gcp.audit.labels.command.gke.io/command when an explicit command is passed to exec.

Read More

Detects successful GKE audit events where a pod is created with allowPrivilegeEscalation enabled. This weakens container isolation and can help an attacker escalate toward host access. Standalone pods are included; workloads owned by ReplicaSet, DaemonSet, or StatefulSet controllers are excluded.

Read More

Detects an unusual volume of GKE API get requests against multiple distinct Secret objects from the same client fingerprint (user, source IP, and user agent) within the rule lookback window. This can indicate credential access or in-cluster reconnaissance, where a user or token is used to enumerate and retrieve sensitive data such as service account tokens, registry credentials, TLS material, or application configuration. Failed get requests are included and can signal RBAC probing; system service accounts are excluded only when secret reads succeed, since failed secret access by a service account may indicate compromise or misconfiguration worth investigating.

Read More

Flags an existing GKE Role or ClusterRole being changed (patch or update) so the effective rules become cluster-admin-like: wildcard on every API resource and wildcard on every verb. That is usually a deliberate privilege expansion, not a typo. GKE audit logs with response body capture are required so the detection reads the merged role after apply; loopback source IPs are ignored.

Read More

Detects GKE Secrets API activity that should not occur in normal cluster operation: a node identity (system:node:*) performing secrets get or list, or a pod service account failing a secrets get. Kubelet and node credentials are not expected to call the Secrets API for enumeration or direct reads, and a denied service-account secret get could indicate stolen-token probing or over-privileged tooling reaching beyond its RBAC.

Read More

Detects GKE secrets get or list requests from a previously unseen combination of source IP, identity, and user agent, excluding the default Kubernetes client placeholder. Attackers who compromise a pod or steal a kubeconfig often use curl, custom scripts, or atypical clients from a new host to read service-account tokens, registry credentials, or application secrets. Anonymous identities are excluded; use dedicated anonymous-access rules for unauthenticated probing.

Read More

Detects successful GKE secret get or list operations where the user agent matches scripting runtimes, minimal HTTP clients, or offensive-distribution fingerprints rather than typical kubectl or controller traffic.

Read More

Detects the first time a human GKE caller lists secrets cluster-wide or in default or kube-system from a source autonomous system that is not attributed to common cloud provider organizations. This can indicate remote secret enumeration using stolen credentials from an unusual network.

Read More

Detects when the same GKE identity creates or modifies a Role or ClusterRole with high-risk permissions (wildcard access, RBAC escalation verbs, or access to secrets / privileged APIs) and also creates or patches a DaemonSet, Deployment, or CronJob within five minutes. This correlation is consistent with RBAC-based privilege escalation followed by payload deployment.

Read More

Detects write operations performed by GKE service accounts against RBAC resources (Roles, ClusterRoles, RoleBindings, ClusterRoleBindings). Service accounts typically do not manage RBAC directly; this activity may indicate token abuse or unauthorized privilege escalation.

Read More

Detects a request to attach a built-in kube-controller-manager service account to a pod running in the kube-system namespace on GKE. These service accounts are admin-equivalent and are not normally assigned to arbitrary pods. An attacker who can create pods in kube-system can abuse these tokens for cluster-wide privilege escalation.

Read More

Detects GKE service account or node identities invoking self-subject access or rules review APIs. Non-human identities rarely enumerate their own permissions outside known controllers; this can indicate stolen tokens probing effective RBAC.

Read More

Detects the first occurrence of create or patch activity against sensitive GKE workloads (DaemonSets, Deployments, or CronJobs) from an unusual combination of user agent, source IP, and user identity, which may indicate privilege escalation or unauthorized access within the cluster.

Read More

Detects the first successful GKE secrets.get by a pod service account from a previously unseen combination of service-account identity, user agent, and source IP. Controllers routinely read secrets with a stable client fingerprint; a new user agent or source for that service account could indicate a stolen token used outside the workload (for example curl, a custom script, or kubectl from an unexpected host).

Read More

Detects the first occurrence of a non-system GKE identity establishing an exec session into a pod. kubectl exec enables interactive command execution inside workloads and is a common post-compromise technique to access secrets and expand access.

Read More

This rule detects the creation, execution, and deletion of files inside a container, a common technique used by attackers to evade detection.

Read More

This rule detects when an interactive shell process is launched via an unusual parent processes inside a container. Interactive processes are typically run in the foreground and require user input, which is unusual behavior for a containerized environment. This activity could indicate an attacker attempting to gain access to the container environment or perform malicious actions.

Read More

This rule detects when an interactive shell is spawned inside a running container. This could indicate a potential container breakout attempt or an attacker's attempt to gain unauthorized access to the underlying host.

Read More

The kubeconfig file is a critical component in Kubernetes environments, containing configuration details for accessing and managing Kubernetes clusters. Attackers may attempt to get access to, create or modify kubeconfig files to gain unauthorized initial access to Kubernetes clusters or move laterally within the cluster.

Read More

The kubeconfig file is a critical component in Kubernetes environments, containing configuration details for accessing and managing Kubernetes clusters. Attackers may attempt to get access to, create, or modify kubeconfig files to gain unauthorized initial access to Kubernetes clusters or move laterally within the cluster. This rule detects process discovery executions that involve kubeconfig files, particularly those executed from common shell environments or world-writeable directories.

Read More

This rule detects the execution of the "kubectl apply" command with a URL argument. This command is often used to apply configurations or deploy resources in a Kubernetes cluster. Attackers may use this command to deploy malicious pods or modify existing ones, potentially leading to unauthorized access or data exfiltration.

Read More

This rule detects potential kubectl network configuration modification activity by monitoring for process events where the kubectl command is executed with arguments that suggest an attempt to modify network configurations in Kubernetes. This could indicate an adversary trying to manipulate network settings for malicious purposes, such as establishing unauthorized access or exfiltrating data.

Read More

This rule detects the use of the "kubectl auth --can-i" command, which is used to check permissions in Kubernetes clusters. Attackers may use this command to enumerate permissions and discover potential misconfigurations in the cluster, allowing them to gain unauthorized access or escalate privileges.

Read More

This rule detects the use of the "kubectl get secrets --all-namespaces" command, which enumerates secret resources across the entire Kubernetes cluster. Attackers may use this command to identify accessible secrets in multiple namespaces, aiding credential discovery, privilege escalation, or lateral movement.

Read More

Detects network connection attempts to the Kubernetes Kubelet API port (10250/10255) on internal IP ranges from Linux hosts. This rule focuses on common request and scripting utilities (curl, wget, python, node, etc.) and executions from world-writable or ephemeral paths (/tmp, /var/tmp, /dev/shm, /var/run), which are frequently abused during container and cluster lateral movement.

Read More

This rule detects the access of the Kubelet certificate file inside a container. The Kubelet certificate file is used to authenticate the container to the Kubernetes API server, and may be used by an adversary to gain access to the Kubernetes API server or other resources within the cluster. These files are a common target for adversaries to gain access to the cluster. There is a current limitation in the defend for containers file sensor that prevents file open events from being logged for file open events without write intent.

Read More

This rule detects the use of built-in utilities to discover running pods on a Kubernetes cluster. The utilities used are du, nice, find, locate, and ls. These utilities are commonly used to discover running pods on a Kubernetes cluster. The "/var/lib/kubelet/pods" directory is the default location for Kubelet pod information.

Read More

Detects creation, modification, or deletion of Kubernetes MutatingWebhookConfigurations or ValidatingWebhookConfigurations by non-system identities. Admission webhooks intercept every API request matching their rules before persistence, giving an attacker powerful capabilities: injecting malicious sidecars into every new pod via a mutating webhook, blocking security tooling deployments via a validating webhook, or silently exfiltrating pod specifications to an external server. Webhook manipulation is a stealthy persistence and defense evasion technique because the webhook configuration itself looks benign in kubectl output while actively modifying or intercepting all matching Kubernetes API traffic.

Read More

Flags Linux process executions whose arguments reference high-value Kubernetes service-account material, kubeconfig or node PKI paths, or common cloud files, when invoked via typical file-reading utilities or from ephemeral directories. Useful for spotting in-cluster and hybrid credential theft early.

Read More

This rule detects when an unauthenticated user request is authorized within the cluster via an unusual user agent. Attackers may attempt to use anonymous accounts to gain initial access to the cluster or to avoid attribution of their activities within the cluster. This rule excludes the /healthz, /livez, /version and /.well-known/oauth-authorization-server endpoints which are commonly accessed anonymously.

Read More

This rule detects attempts to create, update, or patch pods by an anonymous user. An anonymous user is a user that is not authenticated or authorized to access the Kubernetes API server. Creating, updating, or patching pods is a common activity for attackers to gain access to the cluster and execute commands.

Read More

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. These identities have broad cluster-wide permissions including unrestricted access to all secrets, the ability to create tokens for any service account, schedule pods on any node, and modify RBAC policies. An attacker impersonating system:masters gains full cluster-admin equivalent access, while impersonating system:kube-controller-manager grants access to every secret in every namespace and the ability to mint service account tokens for lateral movement.

Read More

Detects non-system identities using the Kubernetes nodes/proxy API to proxy requests through the API server directly to a node's Kubelet. The nodes/proxy subresource allows any principal with this RBAC permission to reach the Kubelet API on any worker node without needing direct network access or Kubelet TLS certificates. Through this proxy path, an attacker can list all pod specifications including environment variable secrets, read Kubelet configuration and PKI material, retrieve container logs, and access running pod metadata across all workloads on the target node. Monitoring and health check endpoints such as /metrics, /healthz, and /stats are excluded to reduce noise from legitimate observability tooling.

Read More

Detects creation or approval of a Kubernetes CertificateSigningRequest (CSR) by a non-system identity. Attackers who have gained cluster access can submit a CSR with a privileged Common Name such as system:kube-controller-manager or system:masters, then approve it themselves to obtain a long-lived client certificate. Unlike service account tokens which expire in hours, client certificates persist until they expire or the cluster CA is rotated, providing durable access that survives pod termination, token revocation, and RBAC changes. On non-EKS clusters, the signed certificate allows the attacker to authenticate as the privileged identity from anywhere without needing cluster network access, making it one of the most persistent backdoor mechanisms available in Kubernetes.

Read More

This rule detects the creation of a RoleBinding or ClusterRoleBinding that grants the cluster-admin ClusterRole, which provides unrestricted access to all Kubernetes resources and represents a high-risk privilege escalation or misconfiguration.

Read More

This rule detects a container deployed with one or more dangerously permissive Linux capabilities. An attacker with the ability to deploy a container with added capabilities could use this for further execution, lateral movement, or privilege escalation within a cluster. The capabilities detected in this rule have been used in container escapes to the host machine.

Read More

Detects modifications to the CoreDNS or kube-dns ConfigMap in the kube-system namespace. These ConfigMaps control cluster DNS resolution for all pods. An attacker who modifies the CoreDNS Corefile can redirect internal service DNS names to attacker-controlled IP addresses, enabling man-in-the-middle attacks against the Kubernetes API server, database services, and other internal endpoints. Pods that resolve service names via cluster DNS will transparently connect to the attacker instead of the legitimate service, allowing interception of service account tokens, database credentials, and API traffic. DNS poisoning at the cluster level is particularly dangerous because it affects every pod in every namespace simultaneously and does not require any modification to the victim workloads. CoreDNS configuration changes are rare in normal operations and any unexpected modification should be investigated immediately.

Read More

This rule detects the creation of RoleBindings or ClusterRoleBindings that reference a ServiceAccount, which may indicate privilege delegation or potential RBAC misconfiguration leading to elevated access.

Read More

Detects the creation or modification of Kubernetes Roles or ClusterRoles that grant high-risk permissions, such as wildcard access or RBAC escalation verbs (e.g., bind, escalate, impersonate), which may enable privilege escalation or unauthorized access within the cluster.

Read More

This rule monitors for the execution of curl or wget commands that directly access Kubernetes API endpoints, which may indicate an attempt to interact with Kubernetes resources in a potentially unauthorized manner. This technique is often used by adversaries to gather information about the Kubernetes environment, such as secrets, config maps, and other sensitive data, without using the official Kubernetes client tools such as "kubectl".

Read More

Detects allowed updates to the pods/ephemeralcontainers subresource by a non-system identity. Ephemeral containers are commonly used for debugging (kubectl debug) but can also be abused to inject tooling into a running pod, access mounted secrets, and execute commands in the target pod context. Attackers with sufficient RBAC may use ephemeral containers to escalate privileges, move laterally, or establish persistence without deploying a new workload.

Read More

This rule detects the deletion of Kubernetes events, which can indicate an attempt to cover up malicious activity or misconfigurations. Adversaries may delete events to remove traces of their actions, making it harder for defenders to investigate and respond to incidents.

Read More

This rule detects an attempt to create or modify a service as type NodePort. The NodePort service allows a user to externally expose a set of labeled pods to the internet. This creates an open port on every worker node in the cluster that has a pod for that service. When external traffic is received on that open port, it directs it to the specific pod through the service representing it. A malicious user can configure a service as type Nodeport in order to intercept traffic from other pods or nodes, bypassing firewalls and other network security measures configured for load balancers within a cluster. This creates a direct method of communication between the cluster and the outside world, which could be used for more malicious behavior and certainly widens the attack surface of your cluster.

Read More

This rule detects attempts to create resources in Kubernetes clusters that are forbidden by the authorization policy. It specifically looks for creation requests that are denied with a "forbid" decision, indicating that the user or service account does not have the necessary permissions to perform the action. This activity is commonly associated with adversaries attempting to create resources in a Kubernetes environment without proper authorization, which can lead to unauthorized access, manipulation of cluster resources, lateral movement and/or privilege escalation.

Read More

This rule detects when a forbidden request is made from an unusual user agent in a Kubernetes environment. Adversary tooling may use non-standard or unexpected user agents to interact with the Kubernetes API, which can indicate an attempt to evade detection or blend in with legitimate traffic. In combination with a forbidden request, this behavior can suggest an adversary is attempting to exploit vulnerabilities or misconfigurations in the Kubernetes cluster.

Read More

Adversaries who land credentials in a cluster—or abuse an over-privileged token—often map the environment before exfiltration or privilege escalation. A practical first pass is to learn where workloads run, how the cluster is partitioned, and what RBAC exists at namespace vs cluster scope. Rapid get/list traffic across distinct API resource kinds that answer those questions (namespaces, workloads, roles, cluster-wide roles) is a common setup and orientation pattern for both interactive attackers and automated recon scripts. It is less typical for steady-state controllers, which usually touch a narrow set of resources repeatedly. This rule highlights that cross-resource burst from a single client fingerprint within a one-minute bucket so analysts can separate routine automation from potential discovery and permission reconnaissance ahead of follow-on actions.

Read More

This rule detects when a pod is created with a sensitive volume of type hostPath. A hostPath volume type mounts a sensitive file or folder from the node to the container. If the container gets compromised, the attacker can use this mount for gaining access to the node. There are many ways a container with unrestricted access to the host filesystem can escalate privileges, including reading data from other containers, and accessing tokens of more privileged pods.

Read More

This rule detects an attempt to create or modify a pod using the host IPC namespace. This gives access to data used by any pod that also use the hosts IPC namespace. If any process on the host or any processes in a pod uses the hosts inter-process communication mechanisms (shared memory, semaphore arrays, message queues, etc.), an attacker can read/write to those same mechanisms. They may look for files in /dev/shm or use ipcs to check for any IPC facilities being used.

Read More

This rules detects an attempt to create or modify a pod attached to the host network. HostNetwork allows a pod to use the node network namespace. Doing so gives the pod access to any service running on localhost of the host. An attacker could use this access to snoop on network activity of other pods on the same node or bypass restrictive network policies applied to its given namespace.

Read More

This rule detects an attempt to create or modify a pod attached to the host PID namespace. HostPID allows a pod to access all the processes running on the host and could allow an attacker to take malicious action. When paired with ptrace this can be used to escalate privileges outside of the container. When paired with a privileged container, the pod can see all of the processes on the host. An attacker can enter the init system (PID 1) on the host. From there, they could execute a shell and continue to escalate privileges to root.

Read More

This rule detects potential endpoint enumeration attempts by an anonymous user. An anonymous user is a user that is not authenticated or authorized to access the Kubernetes API server. By looking for a series of failed API requests, on multiple endpoints, and a limited number of documents, this rule can detect automated permission enumeration attempts. This behavior is uncommon for regular Kubernetes clusters.

Read More

This rule detects potential endpoint enumeration attempts by a single user and source IP address. By looking for a combination of failed/successful API requests across multiple endpoints and a limited number of documents, this rule can detect automated permission enumeration attempts. This behavior is uncommon for regular Kubernetes clusters.

Read More

This rule detects when a user creates a pod/container running in privileged mode. A highly privileged container has access to the node's resources and breaks the isolation between containers. If compromised, an attacker can use the privileged container to gain access to the underlying host. Gaining access to the host may provide the adversary with the opportunity to achieve follow-on objectives, such as establishing persistence, moving laterally within the environment, or setting up a command and control channel on the host.

Read More

This rule detects an unusual volume of Kubernetes API get requests against multiple distinct Secret objects from the same client fingerprint (user, source IP, and user agent) within a defined lookback window. This can indicate credential access or in-cluster reconnaissance, where a user or token is used to enumerate and retrieve sensitive data such as service account tokens, registry credentials, TLS material, or application configuration. Failed get requests are also included, as they may reveal RBAC boundaries, confirm the existence of targeted secrets, or reflect automated probing activity.

Read More

Flags an existing Role or ClusterRole being changed (patch or update) so the effective rules become cluster-admin-like: wildcard on every API resource and wildcard on every verb. That is usually a deliberate privilege expansion, not a typo. RequestResponse audit and the response body are required so the detection reads the merged role after apply; loopback source IPs are ignored.

Read More

This rule detects when secrets are accessed via an unusual user agent, user name and source IP. Attackers may attempt to access secrets in a Kubernetes cluster to gain access to sensitive information after gaining access to the cluster.

Read More

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. Attackers who stole a pod service-account token or node credentials sweep Secret objects for tokens, registry credentials, TLS keys, or application configuration. Even denied attempts still reveal intent to reach sensitive material. Legitimate controllers do read secrets they mount or manage, so this signal is most valuable when paired with triage (namespace scope, user agent, RBAC, and whether the identity should touch those secret names at all).

Read More

Detects read access to Kubernetes Secrets (get/list) with a user agent matching a curated set of non-standard or attacker-leaning clients, for example minimal HTTP tooling, common scripting stacks, default library fingerprints, or distribution-tagged strings associated with offensive-security Linux images. Legitimate in-cluster automation usually presents stable, purpose-specific user agents (for example controller or client-go variants used by known components).

Read More

Detects when secrets or configmaps are accessed, created, modified, or deleted in a Kubernetes cluster by the Azure Arc AAD proxy service account. When operations are routed through the Azure Arc Cluster Connect proxy, the Kubernetes audit log records the acting user as system:serviceaccount:azure-arc:azure-arc-kube-aad-proxy-sa with the actual caller identity in the impersonatedUser field. This pattern indicates that someone is accessing the cluster through the Azure ARM API rather than directly via kubectl against the API server. While legitimate for Arc-managed workflows, adversaries with stolen service principal credentials can abuse Arc Cluster Connect to read, exfiltrate, or modify secrets and configmaps while appearing as the Arc proxy service account in K8s audit logs. This rule uses a 5-day new-terms history window keyed on the impersonated identity and alerts the first time that Azure AD principal performs this activity.

Read More

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.

Read More

This rule detects the creation or modification of sensitive Kubernetes configuration files on Linux systems. These files include Kubernetes manifests, PKI files, and configuration files that are critical for the operation of Kubernetes clusters. Monitoring these files helps identify potential unauthorized changes or misconfigurations that could lead to security vulnerabilities in Kubernetes environments. Attackers may attempt to modify these files to gain persistence or to deploy malicious containers within the Kubernetes cluster.

Read More

Detects a sequence where a principal creates or modifies a Role/ClusterRole to include high-risk permissions (e.g., wildcard access or escalation verbs) and then creates or patches a workload resource (DaemonSet, Deployment, or CronJob) shortly after, which may indicate RBAC-based privilege escalation followed by payload deployment. This pattern is often used by adversaries to gain unauthorized access to sensitive resources and deploy malicious payloads.

Read More

Detects write operations performed by Kubernetes service accounts against RBAC resources (Roles, ClusterRoles, RoleBindings, ClusterRoleBindings). Service accounts typically do not manage RBAC directly; this activity may indicate token abuse, misconfigured permissions, or unauthorized privilege escalation.

Read More

This rule detects when a process accesses Kubernetes service account secrets. Kubernetes service account secrets are files that contain sensitive information used by applications running in Kubernetes clusters to authenticate and authorize access to the cluster. These secrets are typically mounted into pods at runtime, allowing applications to access them securely. Unauthorized access to these secrets can lead to privilege escalation, lateral movement and unauthorized actions within the cluster.

Read More

Detects the creation of a Kubernetes service account token through the TokenRequest API by a non-system identity. The TokenRequest API allows users and workloads to programmatically generate short-lived tokens for any service account they have create permissions on, without accessing the filesystem or the mounted projected token. Attackers who have gained initial access to a cluster can abuse this API to mint tokens for more privileged service accounts, pivot to cloud provider resources via IRSA/workload identity, or generate long-lived tokens that persist beyond pod termination. Unlike mounted service account tokens which are detectable through file access monitoring, tokens created via the TokenRequest API leave no filesystem footprint, they are only visible in Kubernetes audit logs as a create verb on the serviceaccounts/token subresource. This rule excludes legitimate system components such as the kubelet, kube-controller-manager, and cloud provider managed identities (EKS, AKS, GKE) that routinely create tokens for pod lifecycle management.

Read More

Detects Linux process executions where shells, editors, interpreters, or file/stream utilities reference /etc/kubernetes/manifests in process arguments. That directory holds static pod manifests read by the kubelet; interaction via editors, downloaders, kubectl, redirection helpers (tee, dd), or scripting runtimes may indicate staging or tampering with manifests for persistence or privileged workload placement. Pairs with file-telemetry rules that flag direct manifest creation on container workloads.

Read More

This rule detects a request to attach a controller service account to an existing or new pod running in the kube-system namespace. By default, controllers running as part of the API Server utilize admin-equivalent service accounts hosted in the kube-system namespace. Controller service accounts aren't normally assigned to running pods and could indicate adversary behavior within the cluster. An attacker that can create or modify pods or pod controllers in the kube-system namespace, can assign one of these admin-equivalent service accounts to a pod and abuse their powerful token to escalate privileges and gain complete cluster control.

Read More

This rule detects when a service account or node attempts to enumerate their own permissions via the selfsubjectaccessreview or selfsubjectrulesreview APIs via an unusual user agent. This is highly unusual behavior for non-human identities like service accounts and nodes. An adversary may have gained access to credentials/tokens and this could be an attempt to determine what privileges they have to facilitate further movement or execution within the cluster.

Read More

This rule detects a user attempt to establish a shell session into a pod using the 'exec' command. Using the 'exec' command in a pod allows a user to establish a temporary shell session and execute any process/commands in the pod. An adversary may call bash to gain a persistent interactive shell which will allow access to any data the pod has permissions to, including secrets.

Read More

This rule detects attempts from within a Linux container to create or modify files commonly used for persistence on native Linux systems, including cron jobs, systemd units, sudoers files, and shell profile configurations. While many of these mechanisms do not provide reliable persistence in typical containerized workloads, such modifications are unusual and may indicate persistence attempts, privilege abuse, or preparation for container escape, especially when performed outside normal image build or package management processes.

Read More

This rule detects the use of the mount utility from inside a privileged container. The mount command is used to make a device or file system accessible to the system, and then to connect its root directory to a specified mount point on the local file system. When launched inside a privileged container--a container deployed with all the capabilities of the host machine-- an attacker can access sensitive host level files which could be used for further privilege escalation and container escapes to the host machine. Any usage of mount inside a running privileged container should be further investigated.

Read More

This rule detects the use of the mount utility from inside a container. The mount command is used to make a device or file system accessible to the system, and then to connect its root directory to a specified mount point on the local file system. When launched inside a privileged container--a container deployed with all the capabilities of the host machine-- an attacker can access sensitive host level files which could be used for further privilege escalation and container escapes to the host machine. Any usage of mount inside a running privileged container should be further investigated.

Read More

This rule detects authenticated sessions accessing secret stores across multiple environments from the same source address within a short period of time, including cloud providers (AWS, GCP, Azure) and Kubernetes clusters. Adversaries with access to compromised credentials or session tokens may attempt to retrieve secrets from services such as AWS Secrets Manager, Google Secret Manager, Azure Key Vault, or Kubernetes Secrets in rapid succession to expand their access or exfiltrate sensitive information.

Read More

Identifies suspicious usage of unshare to manipulate system namespaces. Unshare can be utilized to escalate privileges or escape container security boundaries. Threat actors have utilized this binary to allow themselves to escape to the host and access other resources or escalate privileges.

Read More

This rule detects an established netcat file transfer or listener running inside a container. Netcat is a utility used for reading and writing data across network connections, and it can be used for malicious purposes such as establishing a backdoor for persistence, exfiltrating data or file transfer.

Read More

Detects nsenter executions from inside a monitored Linux container that include a namespace target flag (-t or --target). Adversaries abuse nsenter to attach to host or sibling namespaces and escape container isolation when combined with privileged mounts, exposed PIDs, or shared namespaces.

Read More

Detects nsenter executions that target PID with a namespace target flag, a pattern commonly used to attach to the host init namespace from a container or session and run with host context.

Read More

This rule detects when a payload is downloaded and piped to a shell inside a running container. This could indicate a threat actor downloaded a payload and executed it using a shell without the payload being stored on the filesystem.

Read More

This rule detects the creation of pods or containers that execute suspicious commands often associated with persistence or privilege escalation techniques. Attackers may use container orchestration tools like kubectl or container runtimes like docker to create pods or containers that run shell commands with arguments that indicate attempts to establish persistence (e.g., modifying startup scripts, creating backdoors).

Read More

Monitors for the execution of a file system mount followed by a chroot execution. Given enough permissions, a user within a container is capable of mounting the root file system of the host, and leveraging chroot to escape its containarized environment. This behavior pattern is very uncommon and should be investigated.

Read More

This rule detects the enumeration of the cluster by the "jq" command inside a container. The "jq" command is used to parse JSON data, and may be used by an adversary to gain information about the cluster and the services running inside it. This behavior is uncommon within a container, and is commonly leveraged by attackers to help parse cluster information in a more readable format, or set the output as environment variables.

Read More

The Linux kernel invokes the program named in "/proc/sys/kernel/core_pattern" whenever a process core-dumps. When that value begins with a pipe (|), the kernel runs the handler from the host's initial namespace as root, regardless of where the crashing process lived. Because the core-dump up-call is not namespaced, a process inside a container that can write core_pattern can register an attacker-controlled handler and then deliberately crash a process to have it execute on the host as root, resulting in a full container-to-host escape.

Read More

Detects potential direct Kubelet API access attempts on Linux by identifying process executions whose arguments contain URLs targeting Kubelet ports (10250/10255). Adversaries may probe or access Kubelet endpoints to enumerate pods, fetch logs, or attempt remote execution, which can enable discovery and lateral movement in Kubernetes environments.

Read More

This rule detects potential direct Kubelet access via process arguments. An adversary may need to access the Kubelet API to gain access to the Kubernetes API server or other resources within the cluster. These requests are often used to enumerate or execute commands on the Kubernetes API server or other resources within the cluster, and may indicate an attempt to move laterally within the cluster.

Read More