Account Manipulation: Additional Container Cluster Roles
- ID
- T1098.006
- Tactics
- TA0003 Persistence, TA0004 Privilege Escalation
- Sub-technique of
- T1098 Account Manipulation
- Platforms
- Containers
- Data sources
- User Account Modification
- Source
- attack.mitre.org
- MITRE last modified
- 16 Apr 2025
An adversary may add additional roles or permissions to an adversary-controlled user or service account to maintain persistent access to a container orchestration system. For example, an adversary with sufficient permissions may create a RoleBinding or a ClusterRoleBinding to bind a Role or ClusterRole to a Kubernetes account.[1][2] Where attribute-based access control (ABAC) is in use, an adversary with sufficient permissions may modify a Kubernetes ABAC policy to give the target account additional permissions.[3]
This account modification may immediately follow Create Account or other malicious account activity. Adversaries may also modify existing Valid Accounts that they have compromised.
Note that where container orchestration systems are deployed in cloud environments, as with Google Kubernetes Engine, Amazon Elastic Kubernetes Service, and Azure Kubernetes Service, cloud-based role-based access control (RBAC) assignments or ABAC policies can often be used in place of or in addition to local permission assignments.[4][5][6] In these cases, this technique may be used in conjunction with Additional Cloud Roles.
Detection
- DET0572 Suspicious RoleBinding or ClusterRoleBinding Assignment in Kubernetes
Data components: User Account Modification
Mitigations (2)
- M1018 User Account Management
Ensure that low-privileged accounts do not have permissions to add permissions to accounts or to update container cluster roles.
- M1032 Multi-factor Authentication
Require multi-factor authentication for user accounts integrated into container clusters through cloud deployments or via authentication protocols such as LDAP or SAML.