detection.wiki

ServiceAccounts

OperationDescriptionSampleRule
get-serviceaccountsYY
list-serviceaccountsYY
watch-serviceaccountsYY
create-serviceaccountsServiceAccount created (persistence: new identity that can be bound to roles).YY
update-serviceaccountsYY
patch-serviceaccountsYY
delete-serviceaccountsYY
deletecollection-serviceaccountsYN
create-serviceaccounts-tokenService account token created via TokenRequest API (credential access).YY
any-serviceaccountsSynthetic aggregation for rules that filter the serviceaccounts resource with no specific verb. Not a distinct audit record; hosts rule listings that key on objectRef.resource alone.NY

get serviceaccounts

#
Resource
serviceaccounts

Example Audit Event #

{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1",
  "level": "Metadata",
  "auditID": "00000000-0000-0000-0000-000000000000",
  "stage": "ResponseComplete",
  "requestURI": "/api/v1/namespaces/dw-harn/serviceaccounts/dw-harn-serviceaccounts",
  "verb": "get",
  "user": {
    "username": "kubernetes-admin",
    "groups": [
      "kubeadm:cluster-admins",
      "system:authenticated"
    ],
    "extra": {
      "authentication.kubernetes.io/credential-id": [
        "X509SHA256=9bb0383c49b319fbf6b5ed61ab944378956d4292c784d32244ce2fa4dd846a3c"
      ]
    }
  },
  "sourceIPs": [
    "203.0.113.10"
  ],
  "userAgent": "kubectl/v1.36.2 (linux/amd64) kubernetes/24e2b02",
  "objectRef": {
    "resource": "serviceaccounts",
    "namespace": "dw-harn",
    "name": "dw-harn-serviceaccounts",
    "apiVersion": "v1"
  },
  "responseStatus": {
    "metadata": {},
    "code": 200
  },
  "requestReceivedTimestamp": "2026-07-02T04:46:50.231726Z",
  "stageTimestamp": "2026-07-02T04:46:50.233567Z",
  "annotations": {
    "authorization.k8s.io/decision": "allow",
    "authorization.k8s.io/reason": "RBAC: allowed by ClusterRoleBinding \"kubeadm:cluster-admins\" of ClusterRole \"cluster-admin\" to Group \"kubeadm:cluster-admins\""
  }
}

Detection Rules #

Full rule details for this event, including ATT&CK technique mappings and native queries →

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 list-serviceaccounts: list serviceaccounts, watch-serviceaccounts: watch serviceaccounts, create-serviceaccounts: create serviceaccounts, update-serviceaccounts: update serviceaccounts, patch-serviceaccounts: patch serviceaccounts
    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.
  • GKE Multi-Resource Discovery source medium: 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.T1613↳ also matches list-serviceaccounts: list serviceaccounts
    Investigation guide

    Triage and analysis#

    Investigating GKE Multi-Resource Discovery#

    The rule groups GKE audit get/list events on namespaces, nodes, pods, configmaps, serviceaccounts, roles, rolebindings, clusterroles, and clusterrolebindings into one-minute windows per client.user.email, source.ip, and user_agent.original. It alerts when five or more distinct resource kinds appear and the burst includes both cluster-layout kinds (namespaces, pods, or nodes) and RBAC kinds. Allowed and denied authorizations are both included: failures still signal probing.

    Possible investigation steps#

    • Review Esql.enumerated_resources, Esql.enumerated_namespaces, and Esql.enumerated_resource_names for ordering and targeted APIs.
    • Confirm whether source.ip and user_agent.original match expected admin or automation clients.
    • Correlate with follow-on secret reads, RoleBinding changes, pod exec, or unusual user agents from the same actor.

    False positive analysis#

    • Documented platform sync jobs that read layout and RBAC together; exclude known service accounts after validation.
    • Upgrade or install windows that briefly query many resource kinds; correlate with change records.

    Response and remediation#

    • If malicious, revoke or rotate the implicated credentials, tighten RBAC, and inspect for data access or persistence established after the burst.

References #

list serviceaccounts

#
Resource
serviceaccounts

Example Audit Event #

{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1",
  "level": "Metadata",
  "auditID": "00000000-0000-0000-0000-000000000000",
  "stage": "ResponseComplete",
  "requestURI": "/api/v1/namespaces/dw-harn/serviceaccounts?limit=500&timeout=3s",
  "verb": "list",
  "user": {
    "username": "kubernetes-admin",
    "groups": [
      "kubeadm:cluster-admins",
      "system:authenticated"
    ],
    "extra": {
      "authentication.kubernetes.io/credential-id": [
        "X509SHA256=9bb0383c49b319fbf6b5ed61ab944378956d4292c784d32244ce2fa4dd846a3c"
      ]
    }
  },
  "sourceIPs": [
    "203.0.113.10"
  ],
  "userAgent": "kubectl/v1.36.2 (linux/amd64) kubernetes/24e2b02",
  "objectRef": {
    "resource": "serviceaccounts",
    "namespace": "dw-harn",
    "apiVersion": "v1"
  },
  "responseStatus": {
    "metadata": {},
    "code": 200
  },
  "requestReceivedTimestamp": "2026-07-02T04:46:50.358300Z",
  "stageTimestamp": "2026-07-02T04:46:50.359722Z",
  "annotations": {
    "authorization.k8s.io/decision": "allow",
    "authorization.k8s.io/reason": "RBAC: allowed by ClusterRoleBinding \"kubeadm:cluster-admins\" of ClusterRole \"cluster-admin\" to Group \"kubeadm:cluster-admins\""
  }
}

Detection Rules #

Full rule details for this event, including ATT&CK technique mappings and native queries →

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-serviceaccounts: get serviceaccounts, watch-serviceaccounts: watch serviceaccounts, create-serviceaccounts: create serviceaccounts, update-serviceaccounts: update serviceaccounts, patch-serviceaccounts: patch serviceaccounts
    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.
  • GKE Multi-Resource Discovery source medium: 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.T1613↳ also matches get-serviceaccounts: get serviceaccounts
    Investigation guide

    Triage and analysis#

    Investigating GKE Multi-Resource Discovery#

    The rule groups GKE audit get/list events on namespaces, nodes, pods, configmaps, serviceaccounts, roles, rolebindings, clusterroles, and clusterrolebindings into one-minute windows per client.user.email, source.ip, and user_agent.original. It alerts when five or more distinct resource kinds appear and the burst includes both cluster-layout kinds (namespaces, pods, or nodes) and RBAC kinds. Allowed and denied authorizations are both included: failures still signal probing.

    Possible investigation steps#

    • Review Esql.enumerated_resources, Esql.enumerated_namespaces, and Esql.enumerated_resource_names for ordering and targeted APIs.
    • Confirm whether source.ip and user_agent.original match expected admin or automation clients.
    • Correlate with follow-on secret reads, RoleBinding changes, pod exec, or unusual user agents from the same actor.

    False positive analysis#

    • Documented platform sync jobs that read layout and RBAC together; exclude known service accounts after validation.
    • Upgrade or install windows that briefly query many resource kinds; correlate with change records.

    Response and remediation#

    • If malicious, revoke or rotate the implicated credentials, tighten RBAC, and inspect for data access or persistence established after the burst.

References #

watch serviceaccounts

#
Resource
serviceaccounts

Example Audit Event #

{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1",
  "level": "Metadata",
  "auditID": "00000000-0000-0000-0000-000000000000",
  "stage": "ResponseComplete",
  "requestURI": "/api/v1/namespaces/dw-harn/serviceaccounts?resourceVersion=1368&timeout=3s&watch=true",
  "verb": "watch",
  "user": {
    "username": "kubernetes-admin",
    "groups": [
      "kubeadm:cluster-admins",
      "system:authenticated"
    ],
    "extra": {
      "authentication.kubernetes.io/credential-id": [
        "X509SHA256=9bb0383c49b319fbf6b5ed61ab944378956d4292c784d32244ce2fa4dd846a3c"
      ]
    }
  },
  "sourceIPs": [
    "203.0.113.10"
  ],
  "userAgent": "kubectl/v1.36.2 (linux/amd64) kubernetes/24e2b02",
  "objectRef": {
    "resource": "serviceaccounts",
    "namespace": "dw-harn",
    "apiVersion": "v1"
  },
  "responseStatus": {
    "metadata": {},
    "code": 200
  },
  "requestReceivedTimestamp": "2026-07-02T04:46:50.360921Z",
  "stageTimestamp": "2026-07-02T04:46:53.361713Z",
  "annotations": {
    "authorization.k8s.io/decision": "allow",
    "authorization.k8s.io/reason": "RBAC: allowed by ClusterRoleBinding \"kubeadm:cluster-admins\" of ClusterRole \"cluster-admin\" to Group \"kubeadm:cluster-admins\""
  }
}

Detection Rules #

Full rule details for this event, including ATT&CK technique mappings and native queries →

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-serviceaccounts: get serviceaccounts, list-serviceaccounts: list serviceaccounts, create-serviceaccounts: create serviceaccounts, update-serviceaccounts: update serviceaccounts, patch-serviceaccounts: patch serviceaccounts
    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.

References #

create serviceaccounts

#
Resource
serviceaccounts

Description

ServiceAccount created (persistence: new identity that can be bound to roles).

Example Audit Event #

{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1",
  "level": "RequestResponse",
  "auditID": "00000000-0000-0000-0000-000000000000",
  "stage": "ResponseComplete",
  "requestURI": "/api/v1/namespaces/dw-harn/serviceaccounts?fieldManager=kubectl-create&fieldValidation=Strict",
  "verb": "create",
  "user": {
    "username": "kubernetes-admin",
    "groups": [
      "kubeadm:cluster-admins",
      "system:authenticated"
    ],
    "extra": {
      "authentication.kubernetes.io/credential-id": [
        "X509SHA256=9bb0383c49b319fbf6b5ed61ab944378956d4292c784d32244ce2fa4dd846a3c"
      ]
    }
  },
  "sourceIPs": [
    "203.0.113.10"
  ],
  "userAgent": "kubectl/v1.36.2 (linux/amd64) kubernetes/24e2b02",
  "objectRef": {
    "resource": "serviceaccounts",
    "namespace": "dw-harn",
    "name": "dw-harn-serviceaccounts",
    "apiVersion": "v1"
  },
  "responseStatus": {
    "metadata": {},
    "code": 201
  },
  "requestObject": {
    "kind": "ServiceAccount",
    "apiVersion": "v1",
    "metadata": {
      "name": "dw-harn-serviceaccounts",
      "namespace": "dw-harn"
    }
  },
  "responseObject": {
    "kind": "ServiceAccount",
    "apiVersion": "v1",
    "metadata": {
      "name": "dw-harn-serviceaccounts",
      "namespace": "dw-harn",
      "uid": "00000000-0000-0000-0000-000000000000",
      "resourceVersion": "1368",
      "creationTimestamp": "2026-07-02T04:46:50Z"
    }
  },
  "requestReceivedTimestamp": "2026-07-02T04:46:50.164015Z",
  "stageTimestamp": "2026-07-02T04:46:50.167716Z",
  "annotations": {
    "authorization.k8s.io/decision": "allow",
    "authorization.k8s.io/reason": "RBAC: allowed by ClusterRoleBinding \"kubeadm:cluster-admins\" of ClusterRole \"cluster-admin\" to Group \"kubeadm:cluster-admins\""
  }
}

Common Indicators #

Field/value combinations most frequently checked by detection rules targeting this event, derived from cross-vendor predicate analysis.

FieldKindValueRulesVendors
objectRef.resourceeqserviceaccounts3 rulesfalco, sigma
verbeqcreate3 rulesfalco, sigma
responseStatus.code (falco rule field)starts_with22 rulesfalco
objectRef.namespace (falco rule field)inkube-public1 rulefalco
objectRef.namespace (falco rule field)inkube-system1 rulefalco

Detection Rules #

Full rule details for this event, including ATT&CK technique mappings and native queries →

Sigma #

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-serviceaccounts: get serviceaccounts, list-serviceaccounts: list serviceaccounts, watch-serviceaccounts: watch serviceaccounts, update-serviceaccounts: update serviceaccounts, patch-serviceaccounts: patch serviceaccounts
    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.

Falco #

References #

update serviceaccounts

#
Resource
serviceaccounts

Example Audit Event #

{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1",
  "level": "RequestResponse",
  "auditID": "00000000-0000-0000-0000-000000000000",
  "stage": "ResponseComplete",
  "requestURI": "/api/v1/namespaces/dw-harn/serviceaccounts/dw-harn-serviceaccounts?fieldManager=kubectl-replace&fieldValidation=Strict",
  "verb": "update",
  "user": {
    "username": "kubernetes-admin",
    "groups": [
      "kubeadm:cluster-admins",
      "system:authenticated"
    ],
    "extra": {
      "authentication.kubernetes.io/credential-id": [
        "X509SHA256=4cf95d11cbd90036bab41cdc6b88cc8f91550e9135ed4bb61495b02f647812ff"
      ]
    }
  },
  "sourceIPs": [
    "203.0.113.10"
  ],
  "userAgent": "kubectl/v1.36.2 (linux/amd64) kubernetes/24e2b02",
  "objectRef": {
    "resource": "serviceaccounts",
    "namespace": "dw-harn",
    "name": "dw-harn-serviceaccounts",
    "uid": "00000000-0000-0000-0000-000000000000",
    "apiVersion": "v1",
    "resourceVersion": "518"
  },
  "responseStatus": {
    "metadata": {},
    "code": 200
  },
  "requestObject": {
    "kind": "ServiceAccount",
    "apiVersion": "v1",
    "metadata": {
      "name": "dw-harn-serviceaccounts",
      "namespace": "dw-harn",
      "uid": "00000000-0000-0000-0000-000000000000",
      "resourceVersion": "518",
      "creationTimestamp": "2026-07-02T21:30:12Z",
      "labels": {
        "dw-harn-patched": "1"
      }
    }
  },
  "responseObject": {
    "kind": "ServiceAccount",
    "apiVersion": "v1",
    "metadata": {
      "name": "dw-harn-serviceaccounts",
      "namespace": "dw-harn",
      "uid": "00000000-0000-0000-0000-000000000000",
      "resourceVersion": "518",
      "creationTimestamp": "2026-07-02T21:30:12Z",
      "labels": {
        "dw-harn-patched": "1"
      }
    }
  },
  "requestReceivedTimestamp": "2026-07-02T21:30:15.630701Z",
  "stageTimestamp": "2026-07-02T21:30:15.633225Z",
  "annotations": {
    "authorization.k8s.io/decision": "allow",
    "authorization.k8s.io/reason": "RBAC: allowed by ClusterRoleBinding \"kubeadm:cluster-admins\" of ClusterRole \"cluster-admin\" to Group \"kubeadm:cluster-admins\""
  }
}

Detection Rules #

Full rule details for this event, including ATT&CK technique mappings and native queries →

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-serviceaccounts: get serviceaccounts, list-serviceaccounts: list serviceaccounts, watch-serviceaccounts: watch serviceaccounts, create-serviceaccounts: create serviceaccounts, patch-serviceaccounts: patch serviceaccounts
    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.

References #

patch serviceaccounts

#
Resource
serviceaccounts

Example Audit Event #

{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1",
  "level": "RequestResponse",
  "auditID": "00000000-0000-0000-0000-000000000000",
  "stage": "ResponseComplete",
  "requestURI": "/api/v1/namespaces/dw-harn/serviceaccounts/dw-harn-serviceaccounts?fieldManager=kubectl-patch",
  "verb": "patch",
  "user": {
    "username": "kubernetes-admin",
    "groups": [
      "kubeadm:cluster-admins",
      "system:authenticated"
    ],
    "extra": {
      "authentication.kubernetes.io/credential-id": [
        "X509SHA256=9bb0383c49b319fbf6b5ed61ab944378956d4292c784d32244ce2fa4dd846a3c"
      ]
    }
  },
  "sourceIPs": [
    "203.0.113.10"
  ],
  "userAgent": "kubectl/v1.36.2 (linux/amd64) kubernetes/24e2b02",
  "objectRef": {
    "resource": "serviceaccounts",
    "namespace": "dw-harn",
    "name": "dw-harn-serviceaccounts",
    "apiVersion": "v1"
  },
  "responseStatus": {
    "metadata": {},
    "code": 200
  },
  "requestObject": {
    "metadata": {
      "labels": {
        "dw-harn-patched": "1"
      }
    }
  },
  "responseObject": {
    "kind": "ServiceAccount",
    "apiVersion": "v1",
    "metadata": {
      "name": "dw-harn-serviceaccounts",
      "namespace": "dw-harn",
      "uid": "00000000-0000-0000-0000-000000000000",
      "resourceVersion": "1373",
      "creationTimestamp": "2026-07-02T04:46:50Z",
      "labels": {
        "dw-harn-patched": "1"
      }
    }
  },
  "requestReceivedTimestamp": "2026-07-02T04:46:53.430450Z",
  "stageTimestamp": "2026-07-02T04:46:53.434241Z",
  "annotations": {
    "authorization.k8s.io/decision": "allow",
    "authorization.k8s.io/reason": "RBAC: allowed by ClusterRoleBinding \"kubeadm:cluster-admins\" of ClusterRole \"cluster-admin\" to Group \"kubeadm:cluster-admins\""
  }
}

Detection Rules #

Full rule details for this event, including ATT&CK technique mappings and native queries →

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-serviceaccounts: get serviceaccounts, list-serviceaccounts: list serviceaccounts, watch-serviceaccounts: watch serviceaccounts, create-serviceaccounts: create serviceaccounts, update-serviceaccounts: update serviceaccounts
    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.

References #

delete serviceaccounts

#
Resource
serviceaccounts

Example Audit Event #

{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1",
  "level": "RequestResponse",
  "auditID": "00000000-0000-0000-0000-000000000000",
  "stage": "ResponseComplete",
  "requestURI": "/api/v1/namespaces/dw-harn/serviceaccounts/dw-harn-serviceaccounts",
  "verb": "delete",
  "user": {
    "username": "kubernetes-admin",
    "groups": [
      "kubeadm:cluster-admins",
      "system:authenticated"
    ],
    "extra": {
      "authentication.kubernetes.io/credential-id": [
        "X509SHA256=9bb0383c49b319fbf6b5ed61ab944378956d4292c784d32244ce2fa4dd846a3c"
      ]
    }
  },
  "sourceIPs": [
    "203.0.113.10"
  ],
  "userAgent": "kubectl/v1.36.2 (linux/amd64) kubernetes/24e2b02",
  "objectRef": {
    "resource": "serviceaccounts",
    "namespace": "dw-harn",
    "name": "dw-harn-serviceaccounts",
    "apiVersion": "v1"
  },
  "responseStatus": {
    "metadata": {},
    "code": 200
  },
  "requestObject": {
    "kind": "DeleteOptions",
    "apiVersion": "meta.k8s.io/__internal",
    "propagationPolicy": "Background"
  },
  "responseObject": {
    "kind": "ServiceAccount",
    "apiVersion": "v1",
    "metadata": {
      "name": "dw-harn-serviceaccounts",
      "namespace": "dw-harn",
      "uid": "00000000-0000-0000-0000-000000000000",
      "resourceVersion": "1374",
      "creationTimestamp": "2026-07-02T04:46:50Z",
      "labels": {
        "dw-harn-patched": "1"
      }
    }
  },
  "requestReceivedTimestamp": "2026-07-02T04:46:53.497986Z",
  "stageTimestamp": "2026-07-02T04:46:53.502193Z",
  "annotations": {
    "authorization.k8s.io/decision": "allow",
    "authorization.k8s.io/reason": "RBAC: allowed by ClusterRoleBinding \"kubeadm:cluster-admins\" of ClusterRole \"cluster-admin\" to Group \"kubeadm:cluster-admins\""
  }
}

Common Indicators #

Field/value combinations most frequently checked by detection rules targeting this event, derived from cross-vendor predicate analysis.

FieldKindValueRulesVendors
objectRef.resource (falco rule field)eqserviceaccounts1 rulefalco

Detection Rules #

Full rule details for this event, including ATT&CK technique mappings and native queries →

Falco #

References #

deletecollection serviceaccounts

#
Resource
serviceaccounts

Example Audit Event #

{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1",
  "level": "RequestResponse",
  "auditID": "00000000-0000-0000-0000-000000000000",
  "stage": "ResponseComplete",
  "requestURI": "/api/v1/namespaces/dw-harn/serviceaccounts?labelSelector=dw-harn-patched",
  "verb": "deletecollection",
  "user": {
    "username": "kubernetes-admin",
    "groups": [
      "kubeadm:cluster-admins",
      "system:authenticated"
    ],
    "extra": {
      "authentication.kubernetes.io/credential-id": [
        "X509SHA256=3ffde68ef687218e01296d94b0aa59c81cc98de2bd73ab70e21510c8cd4b9cec"
      ]
    }
  },
  "sourceIPs": [
    "203.0.113.10"
  ],
  "userAgent": "kubectl/v1.36.2 (linux/amd64) kubernetes/24e2b02",
  "objectRef": {
    "resource": "serviceaccounts",
    "namespace": "dw-harn",
    "apiVersion": "v1"
  },
  "responseStatus": {
    "metadata": {},
    "code": 200
  },
  "responseObject": {
    "kind": "ServiceAccountList",
    "apiVersion": "v1",
    "metadata": {
      "resourceVersion": "584"
    },
    "items": [
      {
        "metadata": {
          "name": "dw-harn-serviceaccounts",
          "namespace": "dw-harn",
          "uid": "00000000-0000-0000-0000-000000000000",
          "resourceVersion": "582",
          "creationTimestamp": "2026-07-02T23:12:12Z",
          "labels": {
            "dw-harn-patched": "1"
          }
        }
      }
    ]
  },
  "requestReceivedTimestamp": "2026-07-02T23:12:16.284699Z",
  "stageTimestamp": "2026-07-02T23:12:16.290321Z",
  "annotations": {
    "authorization.k8s.io/decision": "allow",
    "authorization.k8s.io/reason": "RBAC: allowed by ClusterRoleBinding \"kubeadm:cluster-admins\" of ClusterRole \"cluster-admin\" to Group \"kubeadm:cluster-admins\""
  }
}

References #

create serviceaccounts/token

#
Resource
serviceaccounts

Description

Service account token created via TokenRequest API (credential access).

Example Audit Event #

{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1",
  "level": "RequestResponse",
  "auditID": "00000000-0000-0000-0000-000000000000",
  "stage": "ResponseComplete",
  "requestURI": "/api/v1/namespaces/dw-harn/serviceaccounts/dw-harn-token-sa/token",
  "verb": "create",
  "user": {
    "username": "kubernetes-admin",
    "groups": [
      "kubeadm:cluster-admins",
      "system:authenticated"
    ],
    "extra": {
      "authentication.kubernetes.io/credential-id": [
        "X509SHA256=9bb0383c49b319fbf6b5ed61ab944378956d4292c784d32244ce2fa4dd846a3c"
      ]
    }
  },
  "sourceIPs": [
    "203.0.113.10"
  ],
  "userAgent": "kubectl/v1.36.2 (linux/amd64) kubernetes/24e2b02",
  "objectRef": {
    "resource": "serviceaccounts",
    "namespace": "dw-harn",
    "name": "dw-harn-token-sa",
    "apiVersion": "v1",
    "subresource": "token"
  },
  "responseStatus": {
    "metadata": {},
    "code": 201
  },
  "requestObject": {
    "kind": "TokenRequest",
    "apiVersion": "authentication.k8s.io/v1",
    "metadata": {},
    "spec": {
      "audiences": null,
      "expirationSeconds": 3600,
      "boundObjectRef": null
    },
    "status": {
      "token": "",
      "expirationTimestamp": null
    }
  },
  "responseObject": {
    "kind": "TokenRequest",
    "apiVersion": "authentication.k8s.io/v1",
    "metadata": {
      "name": "dw-harn-token-sa",
      "namespace": "dw-harn",
      "uid": "00000000-0000-0000-0000-000000000000",
      "creationTimestamp": "2026-07-02T04:48:59Z"
    },
    "spec": {
      "audiences": [
        "https://kubernetes.default.svc.cluster.local"
      ],
      "expirationSeconds": 3600,
      "boundObjectRef": null
    },
    "status": {
      "token": "eyJhbGciOiJSUzI1NiIsImtpZCI6Ii1pRWZhalpkaDVveXpnQ2RRVmFJMk9IWXZLN3hQOFVOVWJjYTRDSjF5X00ifQ.eyJhdWQiOlsiaHR0cHM6Ly9rdWJlcm5ldGVzLmRlZmF1bHQuc3ZjLmNsdXN0ZXIubG9jYWwiXSwiZXhwIjoxNzgyOTcxMzM5LCJpYXQiOjE3ODI5Njc3MzksImlzcyI6Imh0dHBzOi8va3ViZXJuZXRlcy5kZWZhdWx0LnN2Yy5jbHVzdGVyLmxvY2FsIiwianRpIjoiZmJiMmJiZTQtNzQxNS00MzVhLWI2OWMtZmZiMTI3YzM4OGI3Iiwia3ViZXJuZXRlcy5pbyI6eyJuYW1lc3BhY2UiOiJkdy1oYXJuIiwic2VydmljZWFjY291bnQiOnsibmFtZSI6ImR3LWhhcm4tdG9rZW4tc2EiLCJ1aWQiOiI1MmYzYmEzYy02MGViLTRhMTItOWFiNi1mMDA5MjhiZGI2MWMifX0sIm5iZiI6MTc4Mjk2NzczOSwic3ViIjoic3lzdGVtOnNlcnZpY2VhY2NvdW50OmR3LWhhcm46ZHctaGFybi10b2tlbi1zYSJ9.FRc-SNR2gmUNwy1NbnZWnldBPTBwczIrDrzqwoFulTVkvo3-7tkropqqlPH5i9iqNX20_mxEvSvZPv8bwd7aVjE5KO3PvziR_VaBFHv8_oTxJ0aGQ74VU2K7U_pT-r8CSFLg_y2aLsR_NlxeIpjrM-CWyeYWoOiFCbjRXYOVjJaQHL5oEKccnkFG77WKWw1O3bP2OftoAuC5LpCtZl0jMtJh2JRR4Qze7pult1ih_oiCquJG9BQLi9ZFkzEv3If2-I_2x699OeZ-ykgn-tJa9-Y_Qhq9pEmHuJ6Foonex8qCC8fxD3c3GM8dB6b0ui4NYINXLlj4HSQFtxkT0J4fZg",
      "expirationTimestamp": "2026-07-02T05:48:59Z"
    }
  },
  "requestReceivedTimestamp": "2026-07-02T04:48:59.372452Z",
  "stageTimestamp": "2026-07-02T04:48:59.375641Z",
  "annotations": {
    "authentication.kubernetes.io/issued-credential-id": "JTI=00000000-0000-0000-0000-000000000000",
    "authorization.k8s.io/decision": "allow",
    "authorization.k8s.io/reason": "RBAC: allowed by ClusterRoleBinding \"kubeadm:cluster-admins\" of ClusterRole \"cluster-admin\" to Group \"kubeadm:cluster-admins\""
  }
}

Common Indicators #

Field/value combinations most frequently checked by detection rules targeting this event, derived from cross-vendor predicate analysis.

FieldKindValueRulesVendors
azure.platformlogs.category (elastic rule field)inkube-audit1 ruleelastic
azure.platformlogs.category (elastic rule field)inkube-audit-admin1 ruleelastic
azure.platformlogs.properties.log.responseStatus.code (elastic rule field)in2001 ruleelastic
azure.platformlogs.properties.log.responseStatus.code (elastic rule field)in2011 ruleelastic
azure.platformlogs.properties.log.stage (elastic rule field)eqresponsecomplete1 ruleelastic
azure.platformlogs.properties.log.verb (elastic rule field)eqcreate1 ruleelastic
kubernetes.audit.verb (elastic rule field)eqcreate1 ruleelastic

Detection Rules #

Full rule details for this event, including ATT&CK technique mappings and native queries →

Elastic #

  • Azure AKS Service Account Token Created via TokenRequest API source medium: 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.T1528
    Investigation guide

    Triage and analysis#

    Investigating Azure AKS Service Account Token Created via TokenRequest API#

    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. The TokenRequest API (serviceaccounts/token) mints a bound service account token. The kubelet (system:node:*) and the kube-controller-manager (aksService) mint these tokens continuously for normal pod operation and are excluded; the signal is a non-platform identity minting one. An attacker with rights over a service account can request a token to act as that workload identity, reaching resources the compromised principal cannot.

    Possible investigation steps#

    • Identify the requesting identity in azure.platformlogs.properties.log.user.username (and its groups in azure.platformlogs.properties.log.user.groups) and whether it should mint tokens. A workload service account (system:serviceaccount:<ns>:<sa>) minting a token, or masterclient (the local cluster-admin cert), is the higher-concern case.
    • Inspect azure.platformlogs.properties.log.userAgent to distinguish interactive/expected tooling (kubectl create token) from custom clients (for example curl), which is a stronger indicator of scripted abuse.
    • Identify the target service account in azure.platformlogs.properties.log.objectRef.name / azure.platformlogs.properties.log.objectRef.namespace and what RBAC that account holds; minting a token for a higher-privileged service account is privilege escalation.
    • Evaluate the source in azure.platformlogs.properties.log.sourceIPs and pivot on it for follow-on API calls made with the minted token, and correlate with recent RBAC changes, secret reads, or exec sessions from the same identity.

    False positive analysis#

    • Controllers, CI/CD systems, and platform components legitimately request service account tokens (for example the kube-controller-manager as aksService, which is excluded). Additional automation such as GitOps operators or CI running kubectl create token may surface; baseline those identities and exclude the specific validated account rather than re-broadening to all system:*, which would blind the rule to compromised workload service accounts.

    Response and remediation#

    • If unauthorized, revoke the minted token and the requesting identity's credentials, and review the RBAC that permitted token creation.
    • Audit actions performed with the target service account's identity after the request.
    • Collect kube-audit and identity artifacts per incident response procedures.
  • GKE Service Account Token Created via TokenRequest API source medium: 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.T1552, T1552.007
    Investigation guide

    Triage and analysis#

    Investigating GKE Service Account Token Created via TokenRequest API#

    This alert indicates a successful create against the serviceaccounts/token subresource (TokenRequest API), which issues a new service account token without a filesystem read. On GKE this can be abused to mint tokens for privileged service accounts — including those bound through Workload Identity — and pivot to GCP APIs.

    Possible investigation steps#

    • Review client.user.email, source.ip, and user_agent.original.
    • Identify the targeted service account from gcp.audit.resource_name (typically core/v1/namespaces/<ns>/serviceaccounts/<sa>/token).
    • Determine which Role or ClusterRoleBindings grant the actor create on serviceaccounts/token.
    • Correlate the same actor and source with follow-on secret reads, pod exec, RBAC changes, or GCP API activity via Workload Identity.

    False positive analysis#

    • New platform automation that mints projected tokens outside the excluded controllers may match. Allowlist after confirming expected behavior.

    Response and remediation#

    • If unauthorized, remove or revert RBAC that allows TokenRequest and rotate the affected service account credentials.
    • For Workload Identity-linked service accounts, revoke related GCP role sessions and review Cloud Audit Logs in the same window.
  • Kubernetes Service Account Token Created via TokenRequest API source medium: 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.T1552, T1552.007
    Investigation guide

    Triage and analysis#

    Investigating Kubernetes Service Account Token Created via TokenRequest API#

    This alert indicates a successful create against the serviceaccounts/token subresource (TokenRequest API), which issues a new service account token without a filesystem read. In EKS and other managed clusters, this can be abused to mint tokens for more privileged service accounts (including IRSA-linked ones) and pivot to cloud APIs.

    What to review first#

    • Actor and origin:
      • user.name / kubernetes.audit.user.username
      • source.ip / kubernetes.audit.sourceIPs
      • user_agent.original / kubernetes.audit.userAgent
      • For cloud identity, review kubernetes.audit.user.extra.* (e.g., arn, principalId).
    • Targeted service account:
      • kubernetes.audit.objectRef.namespace and kubernetes.audit.objectRef.name
      • kubernetes.audit.requestURI (should resemble /api/v1/namespaces/<ns>/serviceaccounts/<sa>/token)
    • Token issuance hints:
      • kubernetes.audit.annotations.authentication_kubernetes_io/issued-credential-id (token JTI/issued credential id)

    Scoping#

    • Identify which Role/ClusterRoleBindings grant the actor create on serviceaccounts/token in the affected namespace.
    • Pivot on the same user.name and source.ip for follow-on secret reads, pod exec, RBAC changes, or cloud API calls.

    Response and remediation#

    • If unauthorized, remove/revert the RBAC permission that allows TokenRequest (serviceaccounts/token) and rotate the affected service account credentials where applicable.
    • For IRSA/workload identity cases, rotate/revoke the cloud role session pathways and review cloud audit logs for API activity from the time window of the token mint.

Panther #

  • Kubernetes Long-Lived Service Account Token Created source informational: Detects the creation of long-lived service account tokens via the serviceaccounts/token subresource. Kubernetes 1.24+ deprecated automatic token creation, but users with appropriate permissions can still manually create non-expiring tokens for service accounts. Attackers can abuse this to establish persistent access credentials that don't expire automatically. This technique is documented by Stratus Red Team as a persistence mechanism. Note: GCP GKE does not log TokenRequest API operations in Kubernetes audit logs.T1098, T1552

References #

any verb on serviceaccounts (synthetic aggregation)

#
Resource
serviceaccounts

Description

Synthetic aggregation for rules that filter the serviceaccounts resource with no specific verb. Not a distinct audit record; hosts rule listings that key on objectRef.resource alone.

Detection Rules #

Full rule details for this event, including ATT&CK technique mappings and native queries →

Elastic #

  • Kubernetes Multi-Resource Discovery source medium: 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.T1613