Browse Rules

Forbidden Direct Interactive Kubernetes API Request

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 a

Direct Interactive Kubernetes API Request by Unusual Utilities

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 th

Direct Interactive Kubernetes API Request by Common Utilities

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 t

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. 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 contro

Kubernetes Pod Exec Potential Reverse Shell

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.

Service Account Token or Certificate Access Followed by Kubernetes API Request

This rule leverages a combination of Defend for Containers and Kubernetes audit logs to detect the access to the service account token or certificate followed by the execution of a direct interactive Kubernetes API request. An adversary may need to access the service account token or certificate 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 indi

Kubernetes Secret or ConfigMap Access via Azure Arc Proxy

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 directl

Kubernetes Pod Exec with Curl or Wget to HTTPS

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

Kubernetes Secret Get or List with Suspicious User Agent

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).

Kubernetes Pod Exec Sensitive File or Credential Path Access

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 prec

Kubernetes Pod Exec Cloud Instance Metadata Access

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 sho

Kubernetes Sensitive RBAC Change Followed by Workload Modification

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.

GKE Anonymous Endpoint Permission Enumeration

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".

Container Runtime CLI Execution with Suspicious Arguments

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 co

Suspicious Container Runtime CLI Execution

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 co

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.