Secrets

Elastic #

• Azure AKS Secret get or list with Suspicious User Agent source high: 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.T1552, T1552.007↳ also matches list-secrets: list secrets
  Investigation guide

  Triage and analysis#

  Investigating Azure AKS Secret get or list with Suspicious User Agent#

  AKS kube-audit events are carried under the flattened azure.platformlogs.properties.log.* subtree and share the ARM operation event.action: Microsoft.ContainerService/managedClusters/diagnosticLogs/Read. This rule fires when a successful get or list against Kubernetes secrets is issued with a user agent that 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. The user agent is trivially spoofable (the telemetry shows offensive tooling masquerading as kubectl), so this is a corroborating indicator, not proof.

  Possible investigation steps#

  • Identify the acting identity in azure.platformlogs.properties.log.user.username and its group memberships in azure.platformlogs.properties.log.user.groups. Control-plane and node identities (system:apiserver, aksService, system:node:*, system:serviceaccount:kube-system:*) are expected; a human or service-principal identity reading secrets with a scripted client is not.
  • Confirm the request was authorized by checking azure.platformlogs.properties.log.annotations.authorization.k8s.io/decision (allow vs forbid) and the azure.platformlogs.properties.log.responseStatus.code.
  • Review the targeted secret via azure.platformlogs.properties.log.objectRef.namespace and azure.platformlogs.properties.log.objectRef.name, and the exact API path in azure.platformlogs.properties.log.requestURI.
  • Evaluate the source in azure.platformlogs.properties.log.sourceIPs. In-cluster control-plane traffic uses loopback (::1) or node subnet addresses; a public or pod-network source for a secret read is more suspicious. Pivot on the source for other API bursts, exec sessions, or RBAC changes.
  • Correlate with recent Entra ID sign-ins or role assignments for the identity to determine whether the token was recently issued or scoped unusually.

  False positive analysis#

  • Approved scripts, CI jobs, or penetration tests may use generic HTTP clients. Validate identity scope before treating as compromise.
  • Internal automation using generic libraries can be excluded by stable service account after review.
  • The kubelet and controllers built on client-go can default to a Go-http-client/2.0 user agent when no custom agent is set (see kubernetes/kubernetes#108726), so an operator or platform component reading secrets may match Go-http*. Exclude the specific benign identity (for example system:serviceaccount:kube-system:* or a validated operator service account) rather than removing the Go-http* pattern, which also catches default-user-agent offensive tooling.

  Response and remediation#

  • If unauthorized, revoke the identity's tokens and kubeconfig, rotate the exposed secrets, and review RBAC that permits secret reads.
  • Hunt for downstream use of the retrieved secrets, such as new sign-ins, workload deployments, or outbound connections.
  • Collect kube-audit and identity artifacts per incident response procedures.
• GKE Rapid Secret GET Activity Against Multiple Objects source high: 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.T1552, T1552.007
  Investigation guide

  Triage and analysis#

  Investigating GKE Rapid Secret GET Activity Against Multiple Objects#

  This rule surfaces clusters of get operations on secrets where the same identity and client path (client.user.email, source.ip, user_agent.original) touch several different secret resource paths within the lookback window. Allowed and denied outcomes are included: successful reads may indicate harvesting; repeated failure responses can still signal reconnaissance or RBAC probing. System service accounts and core controllers are excluded only for successful secret reads, failed attempts from those identities still alert.

  Investigation steps#

  • Inspect Esql.event_outcome_values for a mix of success vs failure and whether failures cluster on sensitive namespaces.
  • Map the identity to RBAC and namespace scope; review Esql.gcp_audit_resource_name_values for high-value targets (tokens, registry credentials, TLS bundles, application secrets).
  • Pivot on the same source.ip and user for follow-on API activity (exec, pod create, role changes, broad list on secrets).
  • Validate against expected automation (CI, GitOps, backup, in-cluster controllers) before treating as malicious.

  False positives#

  • Controllers and Helm may legitimately read many secrets in one window; tune exclusions after baselining known automation.

  Setup#

  The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule.

• GKE Secret Access from Node or Denied Service Account source medium: 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.T1552, T1552.007↳ also matches list-secrets: list secrets
  Investigation guide

  Triage and analysis#

  Investigating GKE Secret Access from Node or Denied Service Account#

  This rule fires on two high-confidence patterns in GKE audit logs:

  • system:node:* successfully or unsuccessfully calling secrets.get or secrets.list
  • system:serviceaccount:* receiving event.outcome:failure on secrets.get

  Treat node-originated Secrets API calls as priority. For denied service-account gets, determine whether the identity is probing secrets outside its Role/ClusterRole or using an unexpected client from a compromised token.

  Possible investigation steps#

  • Resolve client.user.email to the node or workload and review RBAC bindings for secret get/list scope.
  • Inspect gcp.audit.resource_name, source.ip, and user_agent.original for anomalous clients or cross-namespace targets.
  • Correlate with successful secret reads, pod exec, token creation, or RoleBinding changes in the same window.
  • For node events, confirm whether kubelet, CSI, or maintenance tooling on that node should ever call the Secrets API.

  False positive analysis#

  • Node diagnostics or custom CSI helpers may rarely issue Secrets API calls; allowlist only after confirming the path is approved.
  • Broken RBAC on a newly deployed workload can produce repeated denied gets until permissions are fixed.

  Response and remediation#

  • If malicious, revoke the node or service-account credentials, isolate the host or workload, rotate exposed secrets, and tighten RBAC to least privilege for the affected identity.

Show 7 more (10 total) on the rules page

Splunk #

• Kubernetes Abuse of Secret by Unusual Location source: The following analytic detects unauthorized access or misuse of Kubernetes Secrets from unusual locations. It leverages Kubernetes Audit logs to identify anomalies in access patterns by analyzing the source of requests by country. This…T1552, T1552.007
• Kubernetes Abuse of Secret by Unusual User Agent source: The following analytic detects unauthorized access or misuse of Kubernetes Secrets by unusual user agents. It leverages Kubernetes Audit logs to identify anomalies in access patterns by analyzing the source of requests based on user…T1552, T1552.007
• Kubernetes Abuse of Secret by Unusual User Group source: The following analytic detects unauthorized access or misuse of Kubernetes Secrets by unusual user groups. It leverages Kubernetes Audit logs to identify anomalies in access patterns by analyzing the source of requests and user groups.…T1552, T1552.007

Show 1 more (4 total) on the rules page

Panther #

• Kubernetes Secret Access Denied source medium: This detection monitors for failed attempts to read Kubernetes secrets. While occasional failed access attempts may indicate RBAC misconfigurations, repeated failures suggest enumeration or brute-force attempts by compromised accounts. With 15-minute deduplication, 20 or more failed attempts within this window indicates active secret enumeration and should be investigated immediately.T1552.007, T1613
• Kubernetes Secret Enumeration by a User source medium: Detects when a single user accesses 15 or more distinct secrets within 30 minutes using list, get, or watch verbs. This may indicate secret enumeration to enable lateral or vertical movement and unauthorized access to critical resources. The threshold should be tuned to your environment.T1552.007↳ also matches list-secrets: list secrets, watch-secrets: watch secrets
• Secret Enumeration by a User source medium linked query: Secret Enumeration by a User: This detection monitors for a large number of secrets requests by a single user. This could potentially indicate secret enumeration, which can potentially enable lateral or vertical movement and unauthorized access to critical resources.↳ also matches list-secrets: list secrets, watch-secrets: watch secrets

Show 1 more (4 total) on the rules page

Falco #

• K8s Secret Get Successfully source ERROR: Detect any attempt to get a secret. Service account tokens are excluded.
• K8s Secret Get Unsuccessfully Tried source WARNING: Detect an unsuccessful attempt to get the secret. Service account tokens are excluded.

Sigma #

• Kubernetes Secrets Enumeration source low: Detects enumeration of Kubernetes secrets.T1552, T1552.007

Elastic #

• GKE Secrets List from Unusual Source AS Organization source high: 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.T1552, T1552.007, T1613
  Investigation guide

  Triage and analysis#

  Investigating GKE Secrets List from Unusual Source AS Organization#

  New-terms rule on user.email and source.as.number for cluster-wide or sensitive namespace secret list operations.

  Investigation steps#

  • Confirm gcp.audit.resource_name and whether listing was authorized.
  • Review source.ip, source.as.organization.name, and follow-on secret get or exec activity.

  False positives#

  • First-time legitimate admin access from a new office or VPN provider.

  Setup#

  The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule.

• Multiple Cloud Secrets Accessed by Source Address source high: 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.T1555, T1555.006↳ also matches get-secrets: get secrets
  Investigation guide

  Triage and analysis#

  Multiple Cloud Secrets Accessed by Source Address#

  This alert identifies a single source IP address accessing secret-management APIs across multiple cloud providers (e.g., AWS Secrets Manager, Google Secret Manager, Azure Key Vault) within a short timeframe. This behavior is strongly associated with credential theft, session hijacking, or token replay, where an adversary uses stolen authenticated sessions to harvest secrets across cloud environments.

  Unexpected cross-cloud secret retrieval is uncommon and typically indicates automation misuse or malicious activity.

  Possible investigation steps#

  • Validate the principal
    • Identify the user, service account, workload identity, or application making the requests.
    • Confirm whether this identity is expected to operate across more than one cloud provider.
  • Review related activity
    • Look for additional alerts involving the same identity, source IP, or token over the last 24–48 hours.
    • Identify whether the source IP has been observed performing unusual authentication, privilege escalation, or reconnaissance.
  • Check application or service context
    • Determine whether any workload legitimately pulls secrets from multiple cloud providers.
    • Review deployment pipelines or integration layers that might legitimately bridge AWS, Azure, and GCP.
  • Analyze user agent and invocation patterns
    • Compare user_agent.original or equivalent fields against expected SDKs or automation tools.
    • Suspicious indicators include CLI tools, unknown libraries, browser user agents, or custom scripts.
  • Inspect IP reputation and origin
    • Determine whether the source IP corresponds to a managed workload (EC2, GCE, Azure VM) or an unexpected host.
    • Validate that the associated instance or host is under your control and behaving normally.
  • Review IAM permissions and accessed secrets
    • Check the policies attached to the identity.
    • Verify whether the accessed secrets are sensitive, unused, or unrelated to the identity’s purpose.
  • Assess potential compromise scope
    • If compromise is suspected, enumerate other assets accessed by the same identity in the last 24 hours.
    • Look for lateral movement, privilege escalation, or abnormal API usage.
  • Review Kubernetes activity
    • Identify the Kubernetes user, service account, or workload performing the secret access.
    • Determine whether the access originated from a pod, node, or external client.
    • Validate whether the identity is expected to access secrets in the affected namespaces.
    • Investigate whether the activity corresponds to application behavior or manual/API access.

  False positive analysis#

  • Validate whether the source IP is associated with a legitimate multi-cloud orchestration tool, automation pipeline, or shared CI/CD system.
  • Confirm that the identity is authorized to access secrets across multiple cloud services.
  • If activity is expected, consider adding exceptions that pair account identity, source IP, and expected user agent to reduce noise.
  • Determine whether the source IP is associated with Kubernetes nodes, controllers, or internal workloads that legitimately retrieve secrets alongside cloud provider integrations.

  Response and remediation#

  • Initiate incident response** if the activity is unauthorized or suspicious.
  • Restrict or disable** the affected credentials or service accounts.
  • Rotate all accessed secrets** and review other secrets the identity can access.
  • Analyze systems** that may have leaked credentials, such as compromised hosts or exposed tokens.
  • Harden identity security:
    • Enforce MFA for users where applicable.
    • Reduce permissions to least privilege.
    • Review trust relationships, workload identities, and cross-cloud integrations.
  • Search for persistence mechanisms** such as newly created keys, roles, or service accounts.
  • If Kubernetes access is involved:
    • Rotate Kubernetes secrets and service account tokens.
    • Review RBAC permissions and restrict secret access to least privilege.
    • Inspect affected pods or nodes for compromise.
  • Improve monitoring and audit visibility** by ensuring logging is enabled across all cloud environments.
  • Determine root cause** (phishing, malware, token replay, exposed credential, etc.) and close the vector to prevent recurrence.
• Direct Interactive Kubernetes API Request by Unusual Utilities source low: 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.T1059, T1059.004, T1069, T1087, T1609, T1610↳ also matches get-secrets: get secrets, watch-secrets: watch secrets, create-secrets: create secrets, update-secrets: update secrets, patch-secrets: patch secrets
  Investigation guide

  Triage and analysis#

  Disclaimer: This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

  Investigating Direct Interactive Kubernetes API Request by Unusual Utilities#

  This rule detects interactive commands executed inside containers that use atypical utilities to hit the Kubernetes API, paired with near-simultaneous API activity on pods, secrets, service accounts, roles/bindings, or pod exec/attach/log/portforward. It surfaces hands-on-keyboard discovery and lateral movement using custom scripts that evade common tool allowlists; for example, an intruder opens a shell in a pod, uses Python to query the in-cluster API to list secrets, then triggers pods/exec to pivot into another workload.

  Possible investigation steps#

  • Identify the implicated pod, container image, and executing service account, then quickly review its RBAC bindings and effective permissions to determine blast radius.
  • Inspect the container’s interactive session context by pulling recent command lines, shell history, environment variables, and mounted service account tokens, and look for custom scripts or binaries issuing HTTP requests.
  • Correlate nearby Kubernetes audit entries tied to the same principal and pod to map accessed resources and verbs, noting any exec/attach/portforward or sensitive object interactions across namespaces.
  • Review network activity from the pod to the API server and any in-pod proxies, including DNS lookups and outbound connections, to spot nonstandard clients or tunneling behavior.
  • If suspicious, isolate the pod or node, capture runtime artifacts (e.g., process memory or HTTP client traffic), revoke and rotate the service account credentials, and verify image provenance and integrity.

  False positive analysis#

  • An operator interactively attaches to a pod and uses a Python REPL or bash with /dev/tcp to call the in-cluster API for routine troubleshooting (e.g., list pods, read ConfigMaps, or run selfsubjectaccessreviews), producing normal audit entries that match the rule signature.
  • A correlation artifact arises when two namespaces have pods with the same name: one pod starts an interactive shell while another independently performs get/list/watch calls, and the 1-second sequence keyed only on pod-name links the unrelated events.

  Response and remediation#

  • Immediately isolate the implicated pod that issued direct API calls using a nonstandard utility by applying a deny-all egress NetworkPolicy in its namespace (including to kubernetes.default.svc:443), terminating the interactive session, and scaling its owning Deployment/Job/StatefulSet to zero replicas.
  • Before teardown, capture a runtime snapshot of the container and node including the binary or script used to query the API (e.g., files under /tmp or /dev/tcp usage), shell history, environment, and the mounted service account token and CA bundle at /var/run/secrets/kubernetes.io/serviceaccount/.
  • Revoke access by removing the service account’s RoleBindings/ClusterRoleBindings, deleting all pods that mount that service account to force token rotation, rotating any Secrets and ConfigMaps that were read or created during the window, and deleting any unauthorized Jobs, CronJobs, or Deployments created by the same principal.
  • Restore workloads from a known-good image digest, re-enable the Deployment only after image scan and integrity checks pass, and monitor subsequent Kubernetes audit logs for pods/exec, portforward, and access to secrets across the affected namespaces.
  • Escalate to incident response leadership and consider cluster-wide containment if audit logs show create/patch of ClusterRoleBindings, access to secrets outside the workload’s namespace, or use of pods/exec to pivot into other nodes or system namespaces such as kube-system.
  • Harden access by enforcing least-privilege RBAC that denies pods/exec and attach for application service accounts, setting automountServiceAccountToken: false on workloads that do not need it, restricting egress to the API server with NetworkPolicies, and requiring just-in-time break-glass roles for interactive access.

Show 6 more (9 total) on the rules page

Panther #

• Kubernetes All Secrets Dumped Across Namespaces source critical: This detection monitors for cluster-wide secret list operations that dump all secrets across all namespaces in a single API call. Attackers with list secrets permissions at the cluster level can trivially access every secret in the cluster using the LIST /api/v1/secrets API, exposing all credentials, tokens, and sensitive configuration data. This is a known attack technique documented by Stratus Red Team and represents mass credential theft.T1530, T1552.007
• Kubernetes Secret Enumeration by a User source medium: Detects when a single user accesses 15 or more distinct secrets within 30 minutes using list, get, or watch verbs. This may indicate secret enumeration to enable lateral or vertical movement and unauthorized access to critical resources. The threshold should be tuned to your environment.T1552.007↳ also matches get-secrets: get secrets, watch-secrets: watch secrets
• Secret Enumeration by a User source medium linked query: Secret Enumeration by a User: This detection monitors for a large number of secrets requests by a single user. This could potentially indicate secret enumeration, which can potentially enable lateral or vertical movement and unauthorized access to critical resources.↳ also matches get-secrets: get secrets, watch-secrets: watch secrets

Show 1 more (4 total) on the rules page

Elastic #

• Direct Interactive Kubernetes API Request by Unusual Utilities source low: 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.T1059, T1059.004, T1069, T1087, T1609, T1610↳ also matches get-secrets: get secrets, list-secrets: list secrets, create-secrets: create secrets, update-secrets: update secrets, patch-secrets: patch secrets
  Investigation guide

  Triage and analysis#

  Disclaimer: This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

  Investigating Direct Interactive Kubernetes API Request by Unusual Utilities#

  This rule detects interactive commands executed inside containers that use atypical utilities to hit the Kubernetes API, paired with near-simultaneous API activity on pods, secrets, service accounts, roles/bindings, or pod exec/attach/log/portforward. It surfaces hands-on-keyboard discovery and lateral movement using custom scripts that evade common tool allowlists; for example, an intruder opens a shell in a pod, uses Python to query the in-cluster API to list secrets, then triggers pods/exec to pivot into another workload.

  Possible investigation steps#

  • Identify the implicated pod, container image, and executing service account, then quickly review its RBAC bindings and effective permissions to determine blast radius.
  • Inspect the container’s interactive session context by pulling recent command lines, shell history, environment variables, and mounted service account tokens, and look for custom scripts or binaries issuing HTTP requests.
  • Correlate nearby Kubernetes audit entries tied to the same principal and pod to map accessed resources and verbs, noting any exec/attach/portforward or sensitive object interactions across namespaces.
  • Review network activity from the pod to the API server and any in-pod proxies, including DNS lookups and outbound connections, to spot nonstandard clients or tunneling behavior.
  • If suspicious, isolate the pod or node, capture runtime artifacts (e.g., process memory or HTTP client traffic), revoke and rotate the service account credentials, and verify image provenance and integrity.

  False positive analysis#

  • An operator interactively attaches to a pod and uses a Python REPL or bash with /dev/tcp to call the in-cluster API for routine troubleshooting (e.g., list pods, read ConfigMaps, or run selfsubjectaccessreviews), producing normal audit entries that match the rule signature.
  • A correlation artifact arises when two namespaces have pods with the same name: one pod starts an interactive shell while another independently performs get/list/watch calls, and the 1-second sequence keyed only on pod-name links the unrelated events.

  Response and remediation#

  • Immediately isolate the implicated pod that issued direct API calls using a nonstandard utility by applying a deny-all egress NetworkPolicy in its namespace (including to kubernetes.default.svc:443), terminating the interactive session, and scaling its owning Deployment/Job/StatefulSet to zero replicas.
  • Before teardown, capture a runtime snapshot of the container and node including the binary or script used to query the API (e.g., files under /tmp or /dev/tcp usage), shell history, environment, and the mounted service account token and CA bundle at /var/run/secrets/kubernetes.io/serviceaccount/.
  • Revoke access by removing the service account’s RoleBindings/ClusterRoleBindings, deleting all pods that mount that service account to force token rotation, rotating any Secrets and ConfigMaps that were read or created during the window, and deleting any unauthorized Jobs, CronJobs, or Deployments created by the same principal.
  • Restore workloads from a known-good image digest, re-enable the Deployment only after image scan and integrity checks pass, and monitor subsequent Kubernetes audit logs for pods/exec, portforward, and access to secrets across the affected namespaces.
  • Escalate to incident response leadership and consider cluster-wide containment if audit logs show create/patch of ClusterRoleBindings, access to secrets outside the workload’s namespace, or use of pods/exec to pivot into other nodes or system namespaces such as kube-system.
  • Harden access by enforcing least-privilege RBAC that denies pods/exec and attach for application service accounts, setting automountServiceAccountToken: false on workloads that do not need it, restricting egress to the API server with NetworkPolicies, and requiring just-in-time break-glass roles for interactive access.

Panther #

• Kubernetes Secret Enumeration by a User source medium: Detects when a single user accesses 15 or more distinct secrets within 30 minutes using list, get, or watch verbs. This may indicate secret enumeration to enable lateral or vertical movement and unauthorized access to critical resources. The threshold should be tuned to your environment.T1552.007↳ also matches get-secrets: get secrets, list-secrets: list secrets
• Secret Enumeration by a User source medium linked query: Secret Enumeration by a User: This detection monitors for a large number of secrets requests by a single user. This could potentially indicate secret enumeration, which can potentially enable lateral or vertical movement and unauthorized access to critical resources.↳ also matches get-secrets: get secrets, list-secrets: list secrets
• Secret Enumeration by a User source: This detection monitors for a large number of secrets requests by a single user. This could potentially indicate secret enumeration, which can potentially enable lateral or vertical movement and unauthorized access to critical resources.↳ also matches get-secrets: get secrets, list-secrets: list secrets

Sigma #

• Kubernetes Secrets Modified or Deleted source medium: Detects when Kubernetes Secrets are Modified or Deleted.↳ also matches update-secrets: update secrets, patch-secrets: patch secrets, delete-secrets: delete secrets
• Google Cloud Kubernetes Secrets Modified or Deleted source medium: Identifies when the Secrets are Modified or Deleted.↳ also matches update-secrets: update secrets, patch-secrets: patch secrets, delete-secrets: delete secrets

Elastic #

• Direct Interactive Kubernetes API Request by Unusual Utilities source low: 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.T1059, T1059.004, T1069, T1087, T1609, T1610↳ also matches get-secrets: get secrets, list-secrets: list secrets, watch-secrets: watch secrets, update-secrets: update secrets, patch-secrets: patch secrets
  Investigation guide

  Triage and analysis#

  Disclaimer: This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

  Investigating Direct Interactive Kubernetes API Request by Unusual Utilities#

  This rule detects interactive commands executed inside containers that use atypical utilities to hit the Kubernetes API, paired with near-simultaneous API activity on pods, secrets, service accounts, roles/bindings, or pod exec/attach/log/portforward. It surfaces hands-on-keyboard discovery and lateral movement using custom scripts that evade common tool allowlists; for example, an intruder opens a shell in a pod, uses Python to query the in-cluster API to list secrets, then triggers pods/exec to pivot into another workload.

  Possible investigation steps#

  • Identify the implicated pod, container image, and executing service account, then quickly review its RBAC bindings and effective permissions to determine blast radius.
  • Inspect the container’s interactive session context by pulling recent command lines, shell history, environment variables, and mounted service account tokens, and look for custom scripts or binaries issuing HTTP requests.
  • Correlate nearby Kubernetes audit entries tied to the same principal and pod to map accessed resources and verbs, noting any exec/attach/portforward or sensitive object interactions across namespaces.
  • Review network activity from the pod to the API server and any in-pod proxies, including DNS lookups and outbound connections, to spot nonstandard clients or tunneling behavior.
  • If suspicious, isolate the pod or node, capture runtime artifacts (e.g., process memory or HTTP client traffic), revoke and rotate the service account credentials, and verify image provenance and integrity.

  False positive analysis#

  • An operator interactively attaches to a pod and uses a Python REPL or bash with /dev/tcp to call the in-cluster API for routine troubleshooting (e.g., list pods, read ConfigMaps, or run selfsubjectaccessreviews), producing normal audit entries that match the rule signature.
  • A correlation artifact arises when two namespaces have pods with the same name: one pod starts an interactive shell while another independently performs get/list/watch calls, and the 1-second sequence keyed only on pod-name links the unrelated events.

  Response and remediation#

  • Immediately isolate the implicated pod that issued direct API calls using a nonstandard utility by applying a deny-all egress NetworkPolicy in its namespace (including to kubernetes.default.svc:443), terminating the interactive session, and scaling its owning Deployment/Job/StatefulSet to zero replicas.
  • Before teardown, capture a runtime snapshot of the container and node including the binary or script used to query the API (e.g., files under /tmp or /dev/tcp usage), shell history, environment, and the mounted service account token and CA bundle at /var/run/secrets/kubernetes.io/serviceaccount/.
  • Revoke access by removing the service account’s RoleBindings/ClusterRoleBindings, deleting all pods that mount that service account to force token rotation, rotating any Secrets and ConfigMaps that were read or created during the window, and deleting any unauthorized Jobs, CronJobs, or Deployments created by the same principal.
  • Restore workloads from a known-good image digest, re-enable the Deployment only after image scan and integrity checks pass, and monitor subsequent Kubernetes audit logs for pods/exec, portforward, and access to secrets across the affected namespaces.
  • Escalate to incident response leadership and consider cluster-wide containment if audit logs show create/patch of ClusterRoleBindings, access to secrets outside the workload’s namespace, or use of pods/exec to pivot into other nodes or system namespaces such as kube-system.
  • Harden access by enforcing least-privilege RBAC that denies pods/exec and attach for application service accounts, setting automountServiceAccountToken: false on workloads that do not need it, restricting egress to the API server with NetworkPolicies, and requiring just-in-time break-glass roles for interactive access.
• Kubernetes Secret or ConfigMap Access via Azure Arc Proxy source medium: 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.T1213, T1530, T1552, T1552.007, T1565, T1565.001↳ also matches get-secrets: get secrets, list-secrets: list secrets, update-secrets: update secrets, patch-secrets: patch secrets, delete-secrets: delete secrets
  Investigation guide

  Triage and analysis#

  Investigating Kubernetes Secret or ConfigMap Access via Azure Arc Proxy#

  When Kubernetes operations are performed through Azure Arc Cluster Connect, the K8s audit log shows the Arc AAD proxy service account as the authenticated user, with the actual Azure AD identity in the impersonatedUser field. This rule detects non-system secret and configmap access — including reads, writes, and deletions — routed through this proxy path. Read operations (get, list) are particularly important to detect as they represent the most common adversary action: exfiltrating secrets without leaving obvious modification traces.

  Possible investigation steps#

  • Check the kubernetes.audit.impersonatedUser.username field — this contains the Azure AD object ID of the actual caller. Cross-reference with Azure AD to identify the service principal or user.
  • Review the kubernetes.audit.impersonatedUser.extra.oid field for the Azure AD object ID.
  • Examine the namespace — operations in default or application namespaces are more suspicious than azure-arc or kube-system.
  • Check the kubernetes.audit.objectRef.name — look for suspicious secret/configmap names that don't match known application resources.
  • Correlate with Azure Activity Logs for the same time window to find the LISTCLUSTERUSERCREDENTIAL operation that initiated the Arc proxy session.
  • Review Azure Sign-In Logs for the impersonated identity's authentication source IP and geolocation.

  Response and remediation#

  • If the impersonated identity is not recognized, revoke its Azure AD credentials immediately.
  • Remove the ClusterRoleBinding or RoleBinding that grants the identity access to secrets/configmaps.
  • Rotate any Kubernetes secrets that may have been read or exfiltrated.
  • Review the Arc connection and consider disconnecting it if compromised.

Falco #

• K8s Secret Created source INFO: Detect any attempt to create a secret. Service account tokens are excluded.

Sigma #

• Kubernetes Secrets Modified or Deleted source medium: Detects when Kubernetes Secrets are Modified or Deleted.↳ also matches create-secrets: create secrets, patch-secrets: patch secrets, delete-secrets: delete secrets
• Google Cloud Kubernetes Secrets Modified or Deleted source medium: Identifies when the Secrets are Modified or Deleted.↳ also matches create-secrets: create secrets, patch-secrets: patch secrets, delete-secrets: delete secrets

Elastic #

• Direct Interactive Kubernetes API Request by Unusual Utilities source low: 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.T1059, T1059.004, T1069, T1087, T1609, T1610↳ also matches get-secrets: get secrets, list-secrets: list secrets, watch-secrets: watch secrets, create-secrets: create secrets, patch-secrets: patch secrets
  Investigation guide

  Triage and analysis#

  Disclaimer: This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

  Investigating Direct Interactive Kubernetes API Request by Unusual Utilities#

  This rule detects interactive commands executed inside containers that use atypical utilities to hit the Kubernetes API, paired with near-simultaneous API activity on pods, secrets, service accounts, roles/bindings, or pod exec/attach/log/portforward. It surfaces hands-on-keyboard discovery and lateral movement using custom scripts that evade common tool allowlists; for example, an intruder opens a shell in a pod, uses Python to query the in-cluster API to list secrets, then triggers pods/exec to pivot into another workload.

  Possible investigation steps#

  • Identify the implicated pod, container image, and executing service account, then quickly review its RBAC bindings and effective permissions to determine blast radius.
  • Inspect the container’s interactive session context by pulling recent command lines, shell history, environment variables, and mounted service account tokens, and look for custom scripts or binaries issuing HTTP requests.
  • Correlate nearby Kubernetes audit entries tied to the same principal and pod to map accessed resources and verbs, noting any exec/attach/portforward or sensitive object interactions across namespaces.
  • Review network activity from the pod to the API server and any in-pod proxies, including DNS lookups and outbound connections, to spot nonstandard clients or tunneling behavior.
  • If suspicious, isolate the pod or node, capture runtime artifacts (e.g., process memory or HTTP client traffic), revoke and rotate the service account credentials, and verify image provenance and integrity.

  False positive analysis#

  • An operator interactively attaches to a pod and uses a Python REPL or bash with /dev/tcp to call the in-cluster API for routine troubleshooting (e.g., list pods, read ConfigMaps, or run selfsubjectaccessreviews), producing normal audit entries that match the rule signature.
  • A correlation artifact arises when two namespaces have pods with the same name: one pod starts an interactive shell while another independently performs get/list/watch calls, and the 1-second sequence keyed only on pod-name links the unrelated events.

  Response and remediation#

  • Immediately isolate the implicated pod that issued direct API calls using a nonstandard utility by applying a deny-all egress NetworkPolicy in its namespace (including to kubernetes.default.svc:443), terminating the interactive session, and scaling its owning Deployment/Job/StatefulSet to zero replicas.
  • Before teardown, capture a runtime snapshot of the container and node including the binary or script used to query the API (e.g., files under /tmp or /dev/tcp usage), shell history, environment, and the mounted service account token and CA bundle at /var/run/secrets/kubernetes.io/serviceaccount/.
  • Revoke access by removing the service account’s RoleBindings/ClusterRoleBindings, deleting all pods that mount that service account to force token rotation, rotating any Secrets and ConfigMaps that were read or created during the window, and deleting any unauthorized Jobs, CronJobs, or Deployments created by the same principal.
  • Restore workloads from a known-good image digest, re-enable the Deployment only after image scan and integrity checks pass, and monitor subsequent Kubernetes audit logs for pods/exec, portforward, and access to secrets across the affected namespaces.
  • Escalate to incident response leadership and consider cluster-wide containment if audit logs show create/patch of ClusterRoleBindings, access to secrets outside the workload’s namespace, or use of pods/exec to pivot into other nodes or system namespaces such as kube-system.
  • Harden access by enforcing least-privilege RBAC that denies pods/exec and attach for application service accounts, setting automountServiceAccountToken: false on workloads that do not need it, restricting egress to the API server with NetworkPolicies, and requiring just-in-time break-glass roles for interactive access.
• Kubernetes Secret or ConfigMap Access via Azure Arc Proxy source medium: 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.T1213, T1530, T1552, T1552.007, T1565, T1565.001↳ also matches get-secrets: get secrets, list-secrets: list secrets, create-secrets: create secrets, patch-secrets: patch secrets, delete-secrets: delete secrets
  Investigation guide

  Triage and analysis#

  Investigating Kubernetes Secret or ConfigMap Access via Azure Arc Proxy#

  When Kubernetes operations are performed through Azure Arc Cluster Connect, the K8s audit log shows the Arc AAD proxy service account as the authenticated user, with the actual Azure AD identity in the impersonatedUser field. This rule detects non-system secret and configmap access — including reads, writes, and deletions — routed through this proxy path. Read operations (get, list) are particularly important to detect as they represent the most common adversary action: exfiltrating secrets without leaving obvious modification traces.

  Possible investigation steps#

  • Check the kubernetes.audit.impersonatedUser.username field — this contains the Azure AD object ID of the actual caller. Cross-reference with Azure AD to identify the service principal or user.
  • Review the kubernetes.audit.impersonatedUser.extra.oid field for the Azure AD object ID.
  • Examine the namespace — operations in default or application namespaces are more suspicious than azure-arc or kube-system.
  • Check the kubernetes.audit.objectRef.name — look for suspicious secret/configmap names that don't match known application resources.
  • Correlate with Azure Activity Logs for the same time window to find the LISTCLUSTERUSERCREDENTIAL operation that initiated the Arc proxy session.
  • Review Azure Sign-In Logs for the impersonated identity's authentication source IP and geolocation.

  Response and remediation#

  • If the impersonated identity is not recognized, revoke its Azure AD credentials immediately.
  • Remove the ClusterRoleBinding or RoleBinding that grants the identity access to secrets/configmaps.
  • Rotate any Kubernetes secrets that may have been read or exfiltrated.
  • Review the Arc connection and consider disconnecting it if compromised.

Sigma #

• Kubernetes Secrets Modified or Deleted source medium: Detects when Kubernetes Secrets are Modified or Deleted.↳ also matches create-secrets: create secrets, update-secrets: update secrets, delete-secrets: delete secrets
• Google Cloud Kubernetes Secrets Modified or Deleted source medium: Identifies when the Secrets are Modified or Deleted.↳ also matches create-secrets: create secrets, update-secrets: update secrets, delete-secrets: delete secrets

Elastic #

• Direct Interactive Kubernetes API Request by Unusual Utilities source low: 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.T1059, T1059.004, T1069, T1087, T1609, T1610↳ also matches get-secrets: get secrets, list-secrets: list secrets, watch-secrets: watch secrets, create-secrets: create secrets, update-secrets: update secrets
  Investigation guide

  Triage and analysis#

  Disclaimer: This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

  Investigating Direct Interactive Kubernetes API Request by Unusual Utilities#

  This rule detects interactive commands executed inside containers that use atypical utilities to hit the Kubernetes API, paired with near-simultaneous API activity on pods, secrets, service accounts, roles/bindings, or pod exec/attach/log/portforward. It surfaces hands-on-keyboard discovery and lateral movement using custom scripts that evade common tool allowlists; for example, an intruder opens a shell in a pod, uses Python to query the in-cluster API to list secrets, then triggers pods/exec to pivot into another workload.

  Possible investigation steps#

  • Identify the implicated pod, container image, and executing service account, then quickly review its RBAC bindings and effective permissions to determine blast radius.
  • Inspect the container’s interactive session context by pulling recent command lines, shell history, environment variables, and mounted service account tokens, and look for custom scripts or binaries issuing HTTP requests.
  • Correlate nearby Kubernetes audit entries tied to the same principal and pod to map accessed resources and verbs, noting any exec/attach/portforward or sensitive object interactions across namespaces.
  • Review network activity from the pod to the API server and any in-pod proxies, including DNS lookups and outbound connections, to spot nonstandard clients or tunneling behavior.
  • If suspicious, isolate the pod or node, capture runtime artifacts (e.g., process memory or HTTP client traffic), revoke and rotate the service account credentials, and verify image provenance and integrity.

  False positive analysis#

  • An operator interactively attaches to a pod and uses a Python REPL or bash with /dev/tcp to call the in-cluster API for routine troubleshooting (e.g., list pods, read ConfigMaps, or run selfsubjectaccessreviews), producing normal audit entries that match the rule signature.
  • A correlation artifact arises when two namespaces have pods with the same name: one pod starts an interactive shell while another independently performs get/list/watch calls, and the 1-second sequence keyed only on pod-name links the unrelated events.

  Response and remediation#

  • Immediately isolate the implicated pod that issued direct API calls using a nonstandard utility by applying a deny-all egress NetworkPolicy in its namespace (including to kubernetes.default.svc:443), terminating the interactive session, and scaling its owning Deployment/Job/StatefulSet to zero replicas.
  • Before teardown, capture a runtime snapshot of the container and node including the binary or script used to query the API (e.g., files under /tmp or /dev/tcp usage), shell history, environment, and the mounted service account token and CA bundle at /var/run/secrets/kubernetes.io/serviceaccount/.
  • Revoke access by removing the service account’s RoleBindings/ClusterRoleBindings, deleting all pods that mount that service account to force token rotation, rotating any Secrets and ConfigMaps that were read or created during the window, and deleting any unauthorized Jobs, CronJobs, or Deployments created by the same principal.
  • Restore workloads from a known-good image digest, re-enable the Deployment only after image scan and integrity checks pass, and monitor subsequent Kubernetes audit logs for pods/exec, portforward, and access to secrets across the affected namespaces.
  • Escalate to incident response leadership and consider cluster-wide containment if audit logs show create/patch of ClusterRoleBindings, access to secrets outside the workload’s namespace, or use of pods/exec to pivot into other nodes or system namespaces such as kube-system.
  • Harden access by enforcing least-privilege RBAC that denies pods/exec and attach for application service accounts, setting automountServiceAccountToken: false on workloads that do not need it, restricting egress to the API server with NetworkPolicies, and requiring just-in-time break-glass roles for interactive access.
• Kubernetes Secret or ConfigMap Access via Azure Arc Proxy source medium: 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.T1213, T1530, T1552, T1552.007, T1565, T1565.001↳ also matches get-secrets: get secrets, list-secrets: list secrets, create-secrets: create secrets, update-secrets: update secrets, delete-secrets: delete secrets
  Investigation guide

  Triage and analysis#

  Investigating Kubernetes Secret or ConfigMap Access via Azure Arc Proxy#

  When Kubernetes operations are performed through Azure Arc Cluster Connect, the K8s audit log shows the Arc AAD proxy service account as the authenticated user, with the actual Azure AD identity in the impersonatedUser field. This rule detects non-system secret and configmap access — including reads, writes, and deletions — routed through this proxy path. Read operations (get, list) are particularly important to detect as they represent the most common adversary action: exfiltrating secrets without leaving obvious modification traces.

  Possible investigation steps#

  • Check the kubernetes.audit.impersonatedUser.username field — this contains the Azure AD object ID of the actual caller. Cross-reference with Azure AD to identify the service principal or user.
  • Review the kubernetes.audit.impersonatedUser.extra.oid field for the Azure AD object ID.
  • Examine the namespace — operations in default or application namespaces are more suspicious than azure-arc or kube-system.
  • Check the kubernetes.audit.objectRef.name — look for suspicious secret/configmap names that don't match known application resources.
  • Correlate with Azure Activity Logs for the same time window to find the LISTCLUSTERUSERCREDENTIAL operation that initiated the Arc proxy session.
  • Review Azure Sign-In Logs for the impersonated identity's authentication source IP and geolocation.

  Response and remediation#

  • If the impersonated identity is not recognized, revoke its Azure AD credentials immediately.
  • Remove the ClusterRoleBinding or RoleBinding that grants the identity access to secrets/configmaps.
  • Rotate any Kubernetes secrets that may have been read or exfiltrated.
  • Review the Arc connection and consider disconnecting it if compromised.

Sigma #

• Kubernetes Secrets Modified or Deleted source medium: Detects when Kubernetes Secrets are Modified or Deleted.↳ also matches create-secrets: create secrets, update-secrets: update secrets, patch-secrets: patch secrets
• Google Cloud Kubernetes Secrets Modified or Deleted source medium: Identifies when the Secrets are Modified or Deleted.↳ also matches create-secrets: create secrets, update-secrets: update secrets, patch-secrets: patch secrets

Elastic #

• Kubernetes Secret or ConfigMap Access via Azure Arc Proxy source medium: 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.T1213, T1530, T1552, T1552.007, T1565, T1565.001↳ also matches get-secrets: get secrets, list-secrets: list secrets, create-secrets: create secrets, update-secrets: update secrets, patch-secrets: patch secrets
  Investigation guide

  Triage and analysis#

  Investigating Kubernetes Secret or ConfigMap Access via Azure Arc Proxy#

  When Kubernetes operations are performed through Azure Arc Cluster Connect, the K8s audit log shows the Arc AAD proxy service account as the authenticated user, with the actual Azure AD identity in the impersonatedUser field. This rule detects non-system secret and configmap access — including reads, writes, and deletions — routed through this proxy path. Read operations (get, list) are particularly important to detect as they represent the most common adversary action: exfiltrating secrets without leaving obvious modification traces.

  Possible investigation steps#

  • Check the kubernetes.audit.impersonatedUser.username field — this contains the Azure AD object ID of the actual caller. Cross-reference with Azure AD to identify the service principal or user.
  • Review the kubernetes.audit.impersonatedUser.extra.oid field for the Azure AD object ID.
  • Examine the namespace — operations in default or application namespaces are more suspicious than azure-arc or kube-system.
  • Check the kubernetes.audit.objectRef.name — look for suspicious secret/configmap names that don't match known application resources.
  • Correlate with Azure Activity Logs for the same time window to find the LISTCLUSTERUSERCREDENTIAL operation that initiated the Arc proxy session.
  • Review Azure Sign-In Logs for the impersonated identity's authentication source IP and geolocation.

  Response and remediation#

  • If the impersonated identity is not recognized, revoke its Azure AD credentials immediately.
  • Remove the ClusterRoleBinding or RoleBinding that grants the identity access to secrets/configmaps.
  • Rotate any Kubernetes secrets that may have been read or exfiltrated.
  • Review the Arc connection and consider disconnecting it if compromised.

Falco #

• K8s Secret Deleted source INFO: Detect any attempt to delete a secret. Service account tokens are excluded.

Elastic #

• Kubernetes Rapid Secret GET Activity Against Multiple Objects source high: 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.T1552, T1552.007
• Kubernetes Secret get or list with Suspicious User Agent source high: 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).T1552, T1552.007
• Kubernetes Secret get or list from Node or Pod Service Account source medium: 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).T1552, T1552.007

Show 2 more (5 total) on the rules page