EXPLORE DETECTIONS
GKE Pod Exec with Curl or Wget to HTTPS
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.
GKE Privileged Pod Created
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.
GKE Rapid Secret GET Activity Against Multiple Objects
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.
GKE RBAC Wildcard Elevation on Existing Role
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.
GKE Secret Access from Node or Denied Service Account
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.
GKE Secret Access via Unusual User Agent
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.
GKE Secret get or list with Suspicious User Agent
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.
GKE Secrets List from Unusual Source AS Organization
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.
GKE Sensitive RBAC Change Followed by Workload Modification
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.
GKE Service Account Modified RBAC Objects
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.
GKE Service Account Token Created via TokenRequest API
Detects creation of a GKE service account token through the TokenRequest API by a non-system identity. TokenRequest allows programmatic minting of short-lived tokens for any service account the caller can create tokens for, without reading a mounted projected token from disk. Attackers with initial cluster access can abuse this API to obtain tokens for more privileged service accounts, pivot via Workload Identity to GCP APIs, or retain access after pod termination. Unlike filesystem token theft, TokenRequest activity is visible only in Kubernetes audit logs as create against the serviceaccounts/token subresource.
GKE Suspicious Assignment of Controller Service Account
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.
GKE Suspicious Self-Subject Review via Service Account
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.
GKE Unusual Sensitive Workload Modification
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.
GKE Unusual Service Account Secret Access via New User Agent
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).
GKE User Exec into Pod
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.
Google Calendar C2 via Script Interpreter
Detects a two-stage Google Calendar C2 pattern where a scripting runtime (Node.js, Python, osascript) first connects to calendar.app.google to retrieve a hidden C2 address, then initiates a secondary connection to the decoded C2 host. This sequence is characteristic of packages using Unicode steganography in Google Calendar events to stage dynamic command-and-control endpoints.
Google SecOps External Alerts
Generates a detection alert for each Google SecOps alert written to the configured indices. Enabling this rule allows you to immediately begin investigating Google SecOps alerts in the app.
Google Workspace 2SV Policy Disabled By User
Detects when a Google Workspace user disables 2-step verification (2SV) on their account. An adversary with access to a compromised account may remove 2SV to eliminate the second authentication factor, leaving password-only access and making future sign-ins easier to abuse, relay, or maintain without triggering MFA challenges.
Google Workspace Admin Role Assigned to a User or Group
Assigning an administrative role to a user or group grants elevated privileges within Google Workspace, including access to the Google Admin console and the ability to manage domain resources and applications. Adversaries may assign administrator roles to an existing account or a newly created account/group to establish persistence, facilitate privilege escalation, and enable follow-on actions across the tenant. In particular, users with Super Admin privileges can bypass single sign-on (SSO) if it is enabled in Google Workspace.
Google Workspace Admin Role Deletion
Detects when a custom administrative role is deleted in Google Workspace. Adversaries may delete a custom admin role to disrupt delegated administration, remove security team access, or hinder incident response. Deleting a role removes the privileges it granted from all assigned users and groups, which can cause operational impact or blind spots during an active investigation.
Google Workspace API Access Granted via Domain-Wide Delegation
Detects when a super administrator authorizes domain-wide delegation (DWD) API client access for a Google Cloud service account or OAuth client. DWD lets an application impersonate users and access Workspace APIs across the tenant. Adversaries with admin access may register or authorize a malicious client with broad scopes to maintain API-based persistence and access mail, drive, and directory data without relying on a single user's password alone.
Google Workspace Bitlocker Setting Disabled
Google Workspace administrators whom manage Windows devices and have Windows device management enabled may also enable BitLocker drive encryption to mitigate unauthorized data access on lost or stolen computers. Adversaries with valid account access may disable BitLocker to access sensitive data on an endpoint added to Google Workspace device management.
Google Workspace Custom Admin Role Created
Detects when a custom administrative role is created in Google Workspace. Unlike prebuilt admin roles, custom roles allow granular selection of privileges across Google services and can be assigned to users or groups. Adversaries may create a custom admin role to craft elevated permissions tailored to their objectives, then assign that role to a compromised or attacker-controlled account to establish persistence and enable follow-on actions such as modifying security controls, granting OAuth access, or changing mail routing.