detection.wiki

RoleBindings

OperationDescriptionSampleRule
get-rolebindingsYY
list-rolebindingsYY
watch-rolebindingsYY
create-rolebindingsRoleBinding created (RBAC privilege escalation or persistence).YY
update-rolebindingsChanges an existing namespace-scoped RoleBinding's subjects (roleRef is immutable), quietly adding a principal to an already-approved grant within that namespace.YY
patch-rolebindingsSame subject-widening mechanism as update, via patch. Sigma's rolebinding-modification rule and Elastic's service-account RBAC-write rule both cover this verb.YY
delete-rolebindingsRemoves a namespace-scoped RoleBinding, revoking whatever access it granted. Sigma and Elastic track deletion the same as create/update/patch.YY
deletecollection-rolebindingsYN
any-rolebindingsSynthetic aggregation for rules that filter the rolebindings resource with no specific verb. Not a distinct audit record; hosts rule listings that key on objectRef.resource alone.NY

get rolebindings

#
Resource
rolebindings

Example Audit Event #

{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1",
  "level": "Metadata",
  "auditID": "00000000-0000-0000-0000-000000000000",
  "stage": "ResponseComplete",
  "requestURI": "/apis/rbac.authorization.k8s.io/v1/namespaces/dw-harn/rolebindings/dw-harn-rolebindings",
  "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": "rolebindings",
    "namespace": "dw-harn",
    "name": "dw-harn-rolebindings",
    "apiGroup": "rbac.authorization.k8s.io",
    "apiVersion": "v1"
  },
  "responseStatus": {
    "metadata": {},
    "code": 200
  },
  "requestReceivedTimestamp": "2026-07-02T04:47:18.339389Z",
  "stageTimestamp": "2026-07-02T04:47:18.340927Z",
  "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-rolebindings: list rolebindings, watch-rolebindings: watch rolebindings, create-rolebindings: create rolebindings, update-rolebindings: update rolebindings, patch-rolebindings: patch rolebindings
    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-rolebindings: list rolebindings
    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 rolebindings

#
Resource
rolebindings

Example Audit Event #

{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1",
  "level": "Metadata",
  "auditID": "00000000-0000-0000-0000-000000000000",
  "stage": "ResponseComplete",
  "requestURI": "/apis/rbac.authorization.k8s.io/v1/namespaces/dw-harn/rolebindings?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": "rolebindings",
    "namespace": "dw-harn",
    "apiGroup": "rbac.authorization.k8s.io",
    "apiVersion": "v1"
  },
  "responseStatus": {
    "metadata": {},
    "code": 200
  },
  "requestReceivedTimestamp": "2026-07-02T04:47:18.463651Z",
  "stageTimestamp": "2026-07-02T04:47:18.465241Z",
  "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-rolebindings: get rolebindings, watch-rolebindings: watch rolebindings, create-rolebindings: create rolebindings, update-rolebindings: update rolebindings, patch-rolebindings: patch rolebindings
    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-rolebindings: get rolebindings
    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 rolebindings

#
Resource
rolebindings

Example Audit Event #

{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1",
  "level": "Metadata",
  "auditID": "00000000-0000-0000-0000-000000000000",
  "stage": "ResponseComplete",
  "requestURI": "/apis/rbac.authorization.k8s.io/v1/namespaces/dw-harn/rolebindings?resourceVersion=1447&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": "rolebindings",
    "namespace": "dw-harn",
    "apiGroup": "rbac.authorization.k8s.io",
    "apiVersion": "v1"
  },
  "responseStatus": {
    "metadata": {},
    "code": 200
  },
  "requestReceivedTimestamp": "2026-07-02T04:47:18.466323Z",
  "stageTimestamp": "2026-07-02T04:47:21.469639Z",
  "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-rolebindings: get rolebindings, list-rolebindings: list rolebindings, create-rolebindings: create rolebindings, update-rolebindings: update rolebindings, patch-rolebindings: patch rolebindings
    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 rolebindings

#
Resource
rolebindings

Description

RoleBinding created (RBAC privilege escalation or persistence).

Example Audit Event #

{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1",
  "level": "RequestResponse",
  "auditID": "00000000-0000-0000-0000-000000000000",
  "stage": "ResponseComplete",
  "requestURI": "/apis/rbac.authorization.k8s.io/v1/namespaces/dw-harn/rolebindings?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": "rolebindings",
    "namespace": "dw-harn",
    "name": "dw-harn-rolebindings",
    "apiGroup": "rbac.authorization.k8s.io",
    "apiVersion": "v1"
  },
  "responseStatus": {
    "metadata": {},
    "code": 201
  },
  "requestObject": {
    "kind": "RoleBinding",
    "apiVersion": "rbac.authorization.k8s.io/v1",
    "metadata": {
      "name": "dw-harn-rolebindings",
      "namespace": "dw-harn"
    },
    "subjects": [
      {
        "kind": "ServiceAccount",
        "name": "default",
        "namespace": "dw-harn"
      }
    ],
    "roleRef": {
      "apiGroup": "rbac.authorization.k8s.io",
      "kind": "Role",
      "name": "dw-harn-role"
    }
  },
  "responseObject": {
    "kind": "RoleBinding",
    "apiVersion": "rbac.authorization.k8s.io/v1",
    "metadata": {
      "name": "dw-harn-rolebindings",
      "namespace": "dw-harn",
      "uid": "00000000-0000-0000-0000-000000000000",
      "resourceVersion": "1447",
      "creationTimestamp": "2026-07-02T04:47:18Z"
    },
    "subjects": [
      {
        "kind": "ServiceAccount",
        "name": "default",
        "namespace": "dw-harn"
      }
    ],
    "roleRef": {
      "apiGroup": "rbac.authorization.k8s.io",
      "kind": "Role",
      "name": "dw-harn-role"
    }
  },
  "requestReceivedTimestamp": "2026-07-02T04:47:18.278708Z",
  "stageTimestamp": "2026-07-02T04:47:18.281599Z",
  "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
kubernetes.audit.objectRef.resource (elastic rule field)inclusterrolebindings4 ruleselastic
kubernetes.audit.objectRef.resource (elastic rule field)inrolebindings4 ruleselastic
EventType (elastic rule field)inio.k8s.authorization.rbac.v1.clusterrolebindings.create2 ruleselastic
EventType (elastic rule field)inio.k8s.authorization.rbac.v1.rolebindings.create2 ruleselastic
kubernetes.audit.verb (elastic rule field)eqcreate2 ruleselastic
objectRef.resourceeqrolebindings2 rulesfalco, sigma
objectRef.resource (sigma rule field)eqclusterrolebindings1 rulesigma
kubernetes.audit.level (elastic rule field)eqrequestresponse1 ruleelastic

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-rolebindings: get rolebindings, list-rolebindings: list rolebindings, watch-rolebindings: watch rolebindings, update-rolebindings: update rolebindings, patch-rolebindings: patch rolebindings
    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 Creation of a RoleBinding Referencing a ServiceAccount source medium: Detects creation of a GKE RoleBinding or ClusterRoleBinding that grants permissions to a ServiceAccount, which may indicate privilege delegation or RBAC misconfiguration leading to elevated access.T1098, T1098.006
    Investigation guide

    Triage and analysis#

    Investigating GKE Creation of a RoleBinding Referencing a ServiceAccount#

    This rule detects creation of a RoleBinding or ClusterRoleBinding whose subject is a ServiceAccount. Attackers often bind over-privileged roles to an existing workload service account to operate with elevated rights.

    Possible investigation steps#

    • Review client.user.email, source.ip, gcp.audit.request.roleRef, and gcp.audit.request.subjects.
    • Determine which workloads run under the bound service account and whether the referenced role is cluster-scoped.
    • Correlate with secret access, exec, or additional RBAC changes from the same actor.

    False positive analysis#

    • Legitimate deployments and operators create service account bindings during routine releases.

    Response and remediation#

    • Remove unauthorized bindings, rotate the service account credentials, and tighten who can create RoleBindings.
  • GKE Service Account Modified RBAC Objects source medium: Detects write operations performed by GKE service accounts against RBAC resources (Roles, ClusterRoles, RoleBindings, ClusterRoleBindings). Service accounts typically do not manage RBAC directly; this activity may indicate token abuse or unauthorized privilege escalation.T1098, T1098.006↳ also matches update-rolebindings: update rolebindings, patch-rolebindings: patch rolebindings, delete-rolebindings: delete rolebindings
    Investigation guide

    Triage and analysis#

    Investigating GKE Service Account Modified RBAC Objects#

    This rule detects service accounts performing allowed write actions on RBAC resources. Stolen or over-privileged service account tokens can silently alter authorization to gain or retain elevated access.

    Possible investigation steps#

    • Review client.user.email, event.action, and gcp.audit.resource_name.
    • Trace the acting service account to its owning workload and inspect recent image changes or exec activity.
    • Correlate with change tickets or GitOps commits for the same RBAC object.

    False positive analysis#

    • Platform operators and GitOps controllers running in-cluster commonly create or patch RBAC objects.

    Response and remediation#

    • Revert unauthorized RBAC changes, rotate the service account credentials, and tighten RBAC for the workload.

Show 3 more (6 total) on the rules page

Falco #

References #

update rolebindings

#
Resource
rolebindings

Description

Changes an existing namespace-scoped RoleBinding's subjects (roleRef is immutable), quietly adding a principal to an already-approved grant within that namespace.

Example Audit Event #

{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1",
  "level": "RequestResponse",
  "auditID": "00000000-0000-0000-0000-000000000000",
  "stage": "ResponseComplete",
  "requestURI": "/apis/rbac.authorization.k8s.io/v1/namespaces/dw-harn/rolebindings/dw-harn-rolebindings?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": "rolebindings",
    "namespace": "dw-harn",
    "name": "dw-harn-rolebindings",
    "uid": "00000000-0000-0000-0000-000000000000",
    "apiGroup": "rbac.authorization.k8s.io",
    "apiVersion": "v1",
    "resourceVersion": "599"
  },
  "responseStatus": {
    "metadata": {},
    "code": 200
  },
  "requestObject": {
    "kind": "RoleBinding",
    "apiVersion": "rbac.authorization.k8s.io/v1",
    "metadata": {
      "name": "dw-harn-rolebindings",
      "namespace": "dw-harn",
      "uid": "00000000-0000-0000-0000-000000000000",
      "resourceVersion": "599",
      "creationTimestamp": "2026-07-02T21:30:43Z",
      "labels": {
        "dw-harn-patched": "1"
      }
    },
    "subjects": [
      {
        "kind": "ServiceAccount",
        "name": "default",
        "namespace": "dw-harn"
      }
    ],
    "roleRef": {
      "apiGroup": "rbac.authorization.k8s.io",
      "kind": "Role",
      "name": "dw-harn-role"
    }
  },
  "responseObject": {
    "kind": "RoleBinding",
    "apiVersion": "rbac.authorization.k8s.io/v1",
    "metadata": {
      "name": "dw-harn-rolebindings",
      "namespace": "dw-harn",
      "uid": "00000000-0000-0000-0000-000000000000",
      "resourceVersion": "599",
      "creationTimestamp": "2026-07-02T21:30:43Z",
      "labels": {
        "dw-harn-patched": "1"
      }
    },
    "subjects": [
      {
        "kind": "ServiceAccount",
        "name": "default",
        "namespace": "dw-harn"
      }
    ],
    "roleRef": {
      "apiGroup": "rbac.authorization.k8s.io",
      "kind": "Role",
      "name": "dw-harn-role"
    }
  },
  "requestReceivedTimestamp": "2026-07-02T21:30:46.598820Z",
  "stageTimestamp": "2026-07-02T21:30:46.601165Z",
  "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
kubernetes.audit.objectRef.resource (elastic rule field)inclusterrolebindings2 ruleselastic
kubernetes.audit.objectRef.resource (elastic rule field)inrolebindings2 ruleselastic
objectRef.resource (sigma rule field)eqclusterrolebindings1 rulesigma
objectRef.resource (sigma rule field)eqrolebindings1 rulesigma

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-rolebindings: get rolebindings, list-rolebindings: list rolebindings, watch-rolebindings: watch rolebindings, create-rolebindings: create rolebindings, patch-rolebindings: patch rolebindings
    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 Service Account Modified RBAC Objects source medium: Detects write operations performed by GKE service accounts against RBAC resources (Roles, ClusterRoles, RoleBindings, ClusterRoleBindings). Service accounts typically do not manage RBAC directly; this activity may indicate token abuse or unauthorized privilege escalation.T1098, T1098.006↳ also matches create-rolebindings: create rolebindings, patch-rolebindings: patch rolebindings, delete-rolebindings: delete rolebindings
    Investigation guide

    Triage and analysis#

    Investigating GKE Service Account Modified RBAC Objects#

    This rule detects service accounts performing allowed write actions on RBAC resources. Stolen or over-privileged service account tokens can silently alter authorization to gain or retain elevated access.

    Possible investigation steps#

    • Review client.user.email, event.action, and gcp.audit.resource_name.
    • Trace the acting service account to its owning workload and inspect recent image changes or exec activity.
    • Correlate with change tickets or GitOps commits for the same RBAC object.

    False positive analysis#

    • Platform operators and GitOps controllers running in-cluster commonly create or patch RBAC objects.

    Response and remediation#

    • Revert unauthorized RBAC changes, rotate the service account credentials, and tighten RBAC for the workload.
  • Kubernetes Service Account Modified RBAC Objects source medium: Detects write operations performed by Kubernetes service accounts against RBAC resources (Roles, ClusterRoles, RoleBindings, ClusterRoleBindings). Service accounts typically do not manage RBAC directly; this activity may indicate token abuse, misconfigured permissions, or unauthorized privilege escalation.T1098, T1098.006↳ also matches create-rolebindings: create rolebindings, patch-rolebindings: patch rolebindings, delete-rolebindings: delete rolebindings
    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 Kubernetes Service Account Modified RBAC Objects#

    This rule detects Kubernetes service accounts performing allowed write actions on RBAC resources such as Roles and RoleBindings, which is atypical because service accounts rarely administer permissions. It matters because stolen or over-privileged service account tokens can silently alter authorization to gain or retain elevated access across the cluster. An attacker commonly uses a compromised workload’s token to create or patch a binding that grants cluster-admin privileges to their service account for persistent control.

    Possible investigation steps#

    • Retrieve the full audit event and diff the before/after RBAC object to identify newly granted subjects, verbs, resources, and cluster-admin or wildcard permissions.
    • Trace the acting service account to its owning workload (Deployment/Pod) and node, then review recent image changes, restarts, exec sessions, and container logs around the event time for compromise indicators.
    • Determine whether the change is attributable to an expected controller or GitOps/CI automation by correlating with change tickets, pipeline runs, and repository commits for RBAC manifests.
    • Validate whether the service account token may be abused by checking for unusual API access patterns, source IPs/user agents, and cross-namespace activity compared to its baseline behavior.
    • Contain if suspicious by reverting the RBAC change, rotating the service account token (and any mounted secrets), and tightening the service account’s Role/ClusterRole to least privilege.

    False positive analysis#

    • A platform automation running in-cluster (e.g., a controller or CI job using a service account) legitimately applies RBAC manifests during routine deployment, upgrades, or namespace onboarding, resulting in create/patch/update of Roles or RoleBindings.
    • A Kubernetes operator or housekeeping workflow running under a service account intentionally adjusts RBAC as part of maintenance (e.g., rotating access, reconciling drift, or cleaning up obsolete bindings) and triggers allowed delete or update actions on RBAC resources.

    Response and remediation#

    • Immediately remove or quarantine the offending service account by deleting its RoleBindings/ClusterRoleBindings and restarting or scaling down the owning workload to stop further RBAC writes.
    • Revert the unauthorized RBAC object changes by restoring the last known-good Roles/Bindings from GitOps/manifests (or kubectl rollout undo where applicable) and verify no new subjects gained wildcard or cluster-admin-equivalent access.
    • Rotate credentials by recreating the service account or triggering token re-issuance, deleting any mounted legacy token secrets, and redeploying workloads to ensure old tokens cannot be reused.
    • Hunt and eradicate persistence by searching for additional recently modified RBAC objects and newly created service accounts in the same namespaces, then remove unauthorized accounts/bindings and scan the implicated container images for backdoors.
    • Escalate to incident response and cluster administrators immediately if any change grants cluster-admin, introduces * verbs/resources, or binds a service account to privileged ClusterRoles across namespaces.
    • Harden going forward by enforcing least-privilege RBAC, enabling admission controls to restrict RBAC modifications to approved identities/namespaces, and using short-lived projected service account tokens with workload identity constraints.

References #

patch rolebindings

#
Resource
rolebindings

Description

Same subject-widening mechanism as update, via patch. Sigma's rolebinding-modification rule and Elastic's service-account RBAC-write rule both cover this verb.

Example Audit Event #

{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1",
  "level": "RequestResponse",
  "auditID": "00000000-0000-0000-0000-000000000000",
  "stage": "ResponseComplete",
  "requestURI": "/apis/rbac.authorization.k8s.io/v1/namespaces/dw-harn/rolebindings/dw-harn-rolebindings?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": "rolebindings",
    "namespace": "dw-harn",
    "name": "dw-harn-rolebindings",
    "apiGroup": "rbac.authorization.k8s.io",
    "apiVersion": "v1"
  },
  "responseStatus": {
    "metadata": {},
    "code": 200
  },
  "requestObject": {
    "metadata": {
      "labels": {
        "dw-harn-patched": "1"
      }
    }
  },
  "responseObject": {
    "kind": "RoleBinding",
    "apiVersion": "rbac.authorization.k8s.io/v1",
    "metadata": {
      "name": "dw-harn-rolebindings",
      "namespace": "dw-harn",
      "uid": "00000000-0000-0000-0000-000000000000",
      "resourceVersion": "1452",
      "creationTimestamp": "2026-07-02T04:47:18Z",
      "labels": {
        "dw-harn-patched": "1"
      }
    },
    "subjects": [
      {
        "kind": "ServiceAccount",
        "name": "default",
        "namespace": "dw-harn"
      }
    ],
    "roleRef": {
      "apiGroup": "rbac.authorization.k8s.io",
      "kind": "Role",
      "name": "dw-harn-role"
    }
  },
  "requestReceivedTimestamp": "2026-07-02T04:47:21.543779Z",
  "stageTimestamp": "2026-07-02T04:47:21.547750Z",
  "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 (sigma rule field)eqclusterrolebindings1 rulesigma
objectRef.resource (sigma rule field)eqrolebindings1 rulesigma

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-rolebindings: get rolebindings, list-rolebindings: list rolebindings, watch-rolebindings: watch rolebindings, create-rolebindings: create rolebindings, update-rolebindings: update rolebindings
    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 Service Account Modified RBAC Objects source medium: Detects write operations performed by GKE service accounts against RBAC resources (Roles, ClusterRoles, RoleBindings, ClusterRoleBindings). Service accounts typically do not manage RBAC directly; this activity may indicate token abuse or unauthorized privilege escalation.T1098, T1098.006↳ also matches create-rolebindings: create rolebindings, update-rolebindings: update rolebindings, delete-rolebindings: delete rolebindings
    Investigation guide

    Triage and analysis#

    Investigating GKE Service Account Modified RBAC Objects#

    This rule detects service accounts performing allowed write actions on RBAC resources. Stolen or over-privileged service account tokens can silently alter authorization to gain or retain elevated access.

    Possible investigation steps#

    • Review client.user.email, event.action, and gcp.audit.resource_name.
    • Trace the acting service account to its owning workload and inspect recent image changes or exec activity.
    • Correlate with change tickets or GitOps commits for the same RBAC object.

    False positive analysis#

    • Platform operators and GitOps controllers running in-cluster commonly create or patch RBAC objects.

    Response and remediation#

    • Revert unauthorized RBAC changes, rotate the service account credentials, and tighten RBAC for the workload.
  • Kubernetes Service Account Modified RBAC Objects source medium: Detects write operations performed by Kubernetes service accounts against RBAC resources (Roles, ClusterRoles, RoleBindings, ClusterRoleBindings). Service accounts typically do not manage RBAC directly; this activity may indicate token abuse, misconfigured permissions, or unauthorized privilege escalation.T1098, T1098.006↳ also matches create-rolebindings: create rolebindings, update-rolebindings: update rolebindings, delete-rolebindings: delete rolebindings
    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 Kubernetes Service Account Modified RBAC Objects#

    This rule detects Kubernetes service accounts performing allowed write actions on RBAC resources such as Roles and RoleBindings, which is atypical because service accounts rarely administer permissions. It matters because stolen or over-privileged service account tokens can silently alter authorization to gain or retain elevated access across the cluster. An attacker commonly uses a compromised workload’s token to create or patch a binding that grants cluster-admin privileges to their service account for persistent control.

    Possible investigation steps#

    • Retrieve the full audit event and diff the before/after RBAC object to identify newly granted subjects, verbs, resources, and cluster-admin or wildcard permissions.
    • Trace the acting service account to its owning workload (Deployment/Pod) and node, then review recent image changes, restarts, exec sessions, and container logs around the event time for compromise indicators.
    • Determine whether the change is attributable to an expected controller or GitOps/CI automation by correlating with change tickets, pipeline runs, and repository commits for RBAC manifests.
    • Validate whether the service account token may be abused by checking for unusual API access patterns, source IPs/user agents, and cross-namespace activity compared to its baseline behavior.
    • Contain if suspicious by reverting the RBAC change, rotating the service account token (and any mounted secrets), and tightening the service account’s Role/ClusterRole to least privilege.

    False positive analysis#

    • A platform automation running in-cluster (e.g., a controller or CI job using a service account) legitimately applies RBAC manifests during routine deployment, upgrades, or namespace onboarding, resulting in create/patch/update of Roles or RoleBindings.
    • A Kubernetes operator or housekeeping workflow running under a service account intentionally adjusts RBAC as part of maintenance (e.g., rotating access, reconciling drift, or cleaning up obsolete bindings) and triggers allowed delete or update actions on RBAC resources.

    Response and remediation#

    • Immediately remove or quarantine the offending service account by deleting its RoleBindings/ClusterRoleBindings and restarting or scaling down the owning workload to stop further RBAC writes.
    • Revert the unauthorized RBAC object changes by restoring the last known-good Roles/Bindings from GitOps/manifests (or kubectl rollout undo where applicable) and verify no new subjects gained wildcard or cluster-admin-equivalent access.
    • Rotate credentials by recreating the service account or triggering token re-issuance, deleting any mounted legacy token secrets, and redeploying workloads to ensure old tokens cannot be reused.
    • Hunt and eradicate persistence by searching for additional recently modified RBAC objects and newly created service accounts in the same namespaces, then remove unauthorized accounts/bindings and scan the implicated container images for backdoors.
    • Escalate to incident response and cluster administrators immediately if any change grants cluster-admin, introduces * verbs/resources, or binds a service account to privileged ClusterRoles across namespaces.
    • Harden going forward by enforcing least-privilege RBAC, enabling admission controls to restrict RBAC modifications to approved identities/namespaces, and using short-lived projected service account tokens with workload identity constraints.

References #

delete rolebindings

#
Resource
rolebindings

Description

Removes a namespace-scoped RoleBinding, revoking whatever access it granted. Sigma and Elastic track deletion the same as create/update/patch.

Example Audit Event #

{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1",
  "level": "RequestResponse",
  "auditID": "00000000-0000-0000-0000-000000000000",
  "stage": "ResponseComplete",
  "requestURI": "/apis/rbac.authorization.k8s.io/v1/namespaces/dw-harn/rolebindings/dw-harn-rolebindings",
  "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": "rolebindings",
    "namespace": "dw-harn",
    "name": "dw-harn-rolebindings",
    "apiGroup": "rbac.authorization.k8s.io",
    "apiVersion": "v1"
  },
  "responseStatus": {
    "metadata": {},
    "status": "Success",
    "details": {
      "name": "dw-harn-rolebindings",
      "group": "rbac.authorization.k8s.io",
      "kind": "rolebindings",
      "uid": "00000000-0000-0000-0000-000000000000"
    },
    "code": 200
  },
  "requestObject": {
    "kind": "DeleteOptions",
    "apiVersion": "meta.k8s.io/__internal",
    "propagationPolicy": "Background"
  },
  "responseObject": {
    "kind": "Status",
    "apiVersion": "v1",
    "metadata": {},
    "status": "Success",
    "details": {
      "name": "dw-harn-rolebindings",
      "group": "rbac.authorization.k8s.io",
      "kind": "rolebindings",
      "uid": "00000000-0000-0000-0000-000000000000"
    }
  },
  "requestReceivedTimestamp": "2026-07-02T04:47:21.610455Z",
  "stageTimestamp": "2026-07-02T04:47:21.613634Z",
  "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.resourceeqrolebindings2 rulesfalco, sigma
objectRef.resource (sigma rule field)eqclusterrolebindings1 rulesigma
verbeqdelete2 rulesfalco, sigma

Detection Rules #

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

Sigma #

Elastic #

  • GKE Service Account Modified RBAC Objects source medium: Detects write operations performed by GKE service accounts against RBAC resources (Roles, ClusterRoles, RoleBindings, ClusterRoleBindings). Service accounts typically do not manage RBAC directly; this activity may indicate token abuse or unauthorized privilege escalation.T1098, T1098.006↳ also matches create-rolebindings: create rolebindings, update-rolebindings: update rolebindings, patch-rolebindings: patch rolebindings
    Investigation guide

    Triage and analysis#

    Investigating GKE Service Account Modified RBAC Objects#

    This rule detects service accounts performing allowed write actions on RBAC resources. Stolen or over-privileged service account tokens can silently alter authorization to gain or retain elevated access.

    Possible investigation steps#

    • Review client.user.email, event.action, and gcp.audit.resource_name.
    • Trace the acting service account to its owning workload and inspect recent image changes or exec activity.
    • Correlate with change tickets or GitOps commits for the same RBAC object.

    False positive analysis#

    • Platform operators and GitOps controllers running in-cluster commonly create or patch RBAC objects.

    Response and remediation#

    • Revert unauthorized RBAC changes, rotate the service account credentials, and tighten RBAC for the workload.
  • Kubernetes Service Account Modified RBAC Objects source medium: Detects write operations performed by Kubernetes service accounts against RBAC resources (Roles, ClusterRoles, RoleBindings, ClusterRoleBindings). Service accounts typically do not manage RBAC directly; this activity may indicate token abuse, misconfigured permissions, or unauthorized privilege escalation.T1098, T1098.006↳ also matches create-rolebindings: create rolebindings, update-rolebindings: update rolebindings, patch-rolebindings: patch rolebindings
    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 Kubernetes Service Account Modified RBAC Objects#

    This rule detects Kubernetes service accounts performing allowed write actions on RBAC resources such as Roles and RoleBindings, which is atypical because service accounts rarely administer permissions. It matters because stolen or over-privileged service account tokens can silently alter authorization to gain or retain elevated access across the cluster. An attacker commonly uses a compromised workload’s token to create or patch a binding that grants cluster-admin privileges to their service account for persistent control.

    Possible investigation steps#

    • Retrieve the full audit event and diff the before/after RBAC object to identify newly granted subjects, verbs, resources, and cluster-admin or wildcard permissions.
    • Trace the acting service account to its owning workload (Deployment/Pod) and node, then review recent image changes, restarts, exec sessions, and container logs around the event time for compromise indicators.
    • Determine whether the change is attributable to an expected controller or GitOps/CI automation by correlating with change tickets, pipeline runs, and repository commits for RBAC manifests.
    • Validate whether the service account token may be abused by checking for unusual API access patterns, source IPs/user agents, and cross-namespace activity compared to its baseline behavior.
    • Contain if suspicious by reverting the RBAC change, rotating the service account token (and any mounted secrets), and tightening the service account’s Role/ClusterRole to least privilege.

    False positive analysis#

    • A platform automation running in-cluster (e.g., a controller or CI job using a service account) legitimately applies RBAC manifests during routine deployment, upgrades, or namespace onboarding, resulting in create/patch/update of Roles or RoleBindings.
    • A Kubernetes operator or housekeeping workflow running under a service account intentionally adjusts RBAC as part of maintenance (e.g., rotating access, reconciling drift, or cleaning up obsolete bindings) and triggers allowed delete or update actions on RBAC resources.

    Response and remediation#

    • Immediately remove or quarantine the offending service account by deleting its RoleBindings/ClusterRoleBindings and restarting or scaling down the owning workload to stop further RBAC writes.
    • Revert the unauthorized RBAC object changes by restoring the last known-good Roles/Bindings from GitOps/manifests (or kubectl rollout undo where applicable) and verify no new subjects gained wildcard or cluster-admin-equivalent access.
    • Rotate credentials by recreating the service account or triggering token re-issuance, deleting any mounted legacy token secrets, and redeploying workloads to ensure old tokens cannot be reused.
    • Hunt and eradicate persistence by searching for additional recently modified RBAC objects and newly created service accounts in the same namespaces, then remove unauthorized accounts/bindings and scan the implicated container images for backdoors.
    • Escalate to incident response and cluster administrators immediately if any change grants cluster-admin, introduces * verbs/resources, or binds a service account to privileged ClusterRoles across namespaces.
    • Harden going forward by enforcing least-privilege RBAC, enabling admission controls to restrict RBAC modifications to approved identities/namespaces, and using short-lived projected service account tokens with workload identity constraints.

Falco #

References #

deletecollection rolebindings

#
Resource
rolebindings

Example Audit Event #

{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1",
  "level": "RequestResponse",
  "auditID": "00000000-0000-0000-0000-000000000000",
  "stage": "ResponseComplete",
  "requestURI": "/apis/rbac.authorization.k8s.io/v1/namespaces/dw-harn/rolebindings?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": "rolebindings",
    "namespace": "dw-harn",
    "apiGroup": "rbac.authorization.k8s.io",
    "apiVersion": "v1"
  },
  "responseStatus": {
    "metadata": {},
    "code": 200
  },
  "responseObject": {
    "kind": "RoleBindingList",
    "apiVersion": "rbac.authorization.k8s.io/v1",
    "metadata": {
      "resourceVersion": "679"
    },
    "items": [
      {
        "metadata": {
          "name": "dw-harn-rolebindings",
          "namespace": "dw-harn",
          "uid": "00000000-0000-0000-0000-000000000000",
          "resourceVersion": "679",
          "creationTimestamp": "2026-07-02T23:12:43Z",
          "labels": {
            "dw-harn-patched": "1"
          }
        },
        "subjects": [
          {
            "kind": "ServiceAccount",
            "name": "default",
            "namespace": "dw-harn"
          }
        ],
        "roleRef": {
          "apiGroup": "rbac.authorization.k8s.io",
          "kind": "Role",
          "name": "dw-harn-role"
        }
      }
    ]
  },
  "requestReceivedTimestamp": "2026-07-02T23:12:47.135087Z",
  "stageTimestamp": "2026-07-02T23:12:47.140536Z",
  "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 #

any verb on rolebindings (synthetic aggregation)

#
Resource
rolebindings

Description

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

Common Indicators #

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

FieldKindValueRulesVendors
EventType (elastic rule field)inget1 ruleelastic
EventType (elastic rule field)inlist1 ruleelastic

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