Privilege Escalation: Changes to sensitive Kubernetes RBAC objects

This document describes a threat finding type in Security Command Center. Threat findings are generated by threat detectors when they detect a potential threat in your cloud resources. For a full list of available threat findings, see Threat findings index.

Overview

To escalate privilege, a potentially malicious actor attempted to modify a ClusterRole, RoleBinding, or ClusterRoleBinding role-based access control (RBAC) object of the sensitive cluster-admin role by using a PUT or PATCH request.

How to respond

To respond to this finding, do the following:

Step 1: Review finding details

  1. Open the Privilege Escalation: Changes to sensitive Kubernetes RBAC objects finding as directed in Reviewing findings. The details panel for the finding opens to the Summary tab.

  2. On the Summary tab, review the information in the following sections:

    • What was detected, especially the following fields:
      • Principal email: the account that made the call.
      • Method name: the method that was called.
      • Kubernetes bindings: the sensitive Kubernetes binding or ClusterRoleBinding that was modified.
    • Affected resource, especially the following fields:
      • Resource display name: the Kubernetes cluster where the action occurred.
    • Related links, especially the following fields:
      • Cloud Logging URI: link to Logging entries.
      • MITRE ATT&CK method: link to the MITRE ATT&CK documentation.
      • Related findings: links to any related findings.

  3. In the What was detected section, click on the name of the binding on the Kubernetes bindings row. The binding details are displayed.

  4. In the displayed binding, note the binding details.

Step 2: Check logs

  1. On the Summary tab of the finding details in the Google Cloud console, go to Logs Explorer by clicking the link in the Cloud Logging URI field.

  2. If the value in Method name was a PATCH method, check the request body to see what properties were modified.

    In update (PUT) calls, the whole object is sent in the request, so the changes aren't as clear.

  3. Check for other actions taken by the principal by using the following filters:

    • resource.labels.cluster_name="CLUSTER_NAME"

    • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

      Replace the following:

    • CLUSTER_NAME: the value that you noted in the Resource display name field in the finding details.

    • PRINCIPAL_EMAIL: the value that you noted in the Principal email field in the finding details.

Step 3: Research attack and response methods

  1. Review MITRE ATT&CK framework entries for this finding type: Privilege Escalation
  2. Confirm the sensitivity of the object and if the modification is warranted.
  3. For bindings, you can check the subject and investigate whether the subject needs the role it is binded to.
  4. Determine whether there are other signs of malicious activity by the principal in the logs.

  5. If the principal email isn't a service account, contact the owner of the account to confirm whether the legitimate owner conducted the action.

    If the principal email is a service account (IAM or Kubernetes), identify the source of the modification to determine its legitimacy.

  6. To develop a response plan, combine your investigation results with MITRE research.

What's next