이 문서에서는 Security Command Center의 위협 발견 항목 유형에 대해 설명합니다. 위협 발견 항목은 위협 감지기가 클라우드 리소스에서 잠재적인 위협을 감지할 때 생성됩니다. 사용 가능한 위협 발견 항목의 전체 목록은 위협 발견 항목 색인을 참고하세요.
개요
권한을 에스컬레이션하기 위해 잠재적 악의적인 행위자가 PUT 또는 PATCH 요청을 사용하여 민감한 cluster-admin의 ClusterRole, RoleBinding, 또는 ClusterRoleBinding 역할 기반 액세스 제어(RBAC) 객체를 수정하려고 시도했습니다.
대응 방법
이 발견 항목에 대응하려면 다음을 수행하세요.
1단계: 발견 항목 세부정보 검토하기
발견 항목 검토의 지시에 따라 Privilege Escalation: Changes to sensitive Kubernetes RBAC objects 발견 항목을 엽니다.
발견 항목의 세부정보 패널의 요약 탭이 열립니다.
요약 탭에서 다음 섹션의 정보를 검토합니다.
특히 다음 필드를 포함하는 감지된 항목:
주 구성원 이메일: 호출을 수행한 계정입니다.
메서드 이름: 호출된 메서드
Kubernetes 바인딩: 수정된 민감한 Kubernetes 바인딩 또는 ClusterRoleBinding
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-05(UTC)"],[],[],null,["| Premium and Enterprise [service tiers](/security-command-center/docs/service-tiers)\n\nThis document describes a threat finding type in Security Command Center. Threat findings are generated by\n[threat detectors](/security-command-center/docs/concepts-security-sources#threats) when they detect\na potential threat in your cloud resources. For a full list of available threat findings, see [Threat findings index](/security-command-center/docs/threat-findings-index).\n\nOverview\n\nTo escalate privilege, a potentially malicious actor attempted to modify a\n`ClusterRole`, `RoleBinding`, or `ClusterRoleBinding` role-based access\ncontrol (RBAC) object of the sensitive [`cluster-admin`](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles)\nrole by using a `PUT` or `PATCH` request.\n\nHow to respond\n\nTo respond to this finding, do the following:\n\nStep 1: Review finding details\n\n1. Open the `Privilege Escalation: Changes to sensitive Kubernetes RBAC objects`\n finding as directed in [Reviewing findings](/security-command-center/docs/how-to-investigate-threats#reviewing_findings).\n The details panel for the finding opens to the **Summary** tab.\n\n2. On the **Summary** tab, review the information in the following sections:\n\n - **What was detected** , especially the following fields:\n - **Principal email**: the account that made the call.\n - **Method name**: the method that was called.\n - **Kubernetes bindings** : the sensitive Kubernetes binding or `ClusterRoleBinding` that was modified.\n - **Affected resource** , especially the following fields:\n - **Resource display name**: the Kubernetes cluster where the action occurred.\n - **Related links** , especially the following fields:\n - **Cloud Logging URI**: link to Logging entries.\n - **MITRE ATT\\&CK method**: link to the MITRE ATT\\&CK documentation.\n - **Related findings**: links to any related findings.\n3. In the **What was detected** section, click on the name of the binding\n on the **Kubernetes bindings** row. The binding details are displayed.\n\n4. In the displayed binding, note the binding details.\n\nStep 2: Check logs\n\n1. 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.\n2. If the value in **Method name** was a `PATCH` method, check the request\n body to see what properties were modified.\n\n In `update` (`PUT`) calls, the whole object is sent in the\n request, so the changes aren't as clear.\n3. Check for other actions taken by the principal by using the following\n filters:\n\n - `resource.labels.cluster_name=\"`\u003cvar class=\"edit\" translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e`\"`\n - `protoPayload.authenticationInfo.principalEmail=\"`\u003cvar class=\"edit\" translate=\"no\"\u003ePRINCIPAL_EMAIL\u003c/var\u003e`\"`\n\n Replace the following:\n - \u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e: the value that you noted in the\n **Resource display name** field in the finding details.\n\n - \u003cvar translate=\"no\"\u003ePRINCIPAL_EMAIL\u003c/var\u003e: the value that you noted in the\n **Principal email** field in the finding details.\n\nStep 3: Research attack and response methods\n\n1. Review MITRE ATT\\&CK framework entries for this finding type: [Privilege Escalation](https://attack.mitre.org/tactics/TA0004/)\n2. Confirm the sensitivity of the object and if the modification is warranted.\n3. For bindings, you can check the subject and investigate whether the subject needs the role it is binded to.\n4. Determine whether there are other signs of malicious activity by the principal in the logs.\n5. If the [principal email](#privilege_escalation_modify_rbac_finding) isn't a\n service account, contact the owner of the account to confirm whether the\n legitimate owner conducted the action.\n\n If the principal email is a service account (IAM or\n Kubernetes), identify the source of the modification to determine its\n legitimacy.\n6. To develop a response plan, combine your investigation results with\n MITRE research.\n\nWhat's next\n\n- Learn [how to work with threat\n findings in Security Command Center](/security-command-center/docs/how-to-investigate-threats).\n- Refer to the [Threat findings index](/security-command-center/docs/threat-findings-index).\n- Learn how to [review a\n finding](/security-command-center/docs/how-to-investigate-threats#reviewing_findings) through the Google Cloud console.\n- Learn about the [services that\n generate threat findings](/security-command-center/docs/concepts-security-sources#threats)."]]
