Additional Container Cluster Roles

Additional Container Cluster Roles [T1098.006]

Information

• Name: Additional Container Cluster Roles

• ID: T1098.006

• Tactics: TA0003, TA0004

• Technique: T1098

Introduction

The MITRE ATT&CK sub-technique Additional Container Cluster Roles (T1098.006) refers to adversaries exploiting or creating additional roles within container orchestration environments, primarily Kubernetes, to gain elevated privileges or maintain persistence. By manipulating cluster role definitions and bindings, attackers can escalate privileges, access sensitive resources, or create persistent backdoors within containerized infrastructures.

Deep Dive Into Technique

In Kubernetes and similar container orchestration platforms, roles define permissions for resources within namespaces, while cluster roles grant permissions across the entire cluster. Attackers targeting this sub-technique typically perform the following actions:

• Enumeration of Existing Roles and Bindings: Adversaries initially enumerate existing cluster roles and role bindings to understand their permissions and identify potential weaknesses or overly permissive roles.

  kubectl get clusterroles
  kubectl get clusterrolebindings

• Creation of Malicious Cluster Roles: Attackers create new cluster roles or modify existing ones to include excessive privileges, such as administrative-level access to secrets, pods, services, nodes, or the ability to execute arbitrary commands.

  apiVersion: rbac.authorization.k8s.io/v1
  kind: ClusterRole
  metadata:
    name: malicious-clusterrole
  rules:
    - apiGroups: [""]
      resources: ["pods", "secrets", "services"]
      verbs: ["get", "list", "watch", "create", "delete", "update"]

• Binding Malicious Roles to Service Accounts or Users: After creating or modifying roles, adversaries bind them to compromised or attacker-controlled service accounts or user accounts, enabling persistent and stealthy access.

  apiVersion: rbac.authorization.k8s.io/v1
  kind: ClusterRoleBinding
  metadata:
    name: malicious-binding
  subjects:
    - kind: ServiceAccount
      name: compromised-account
      namespace: default
  roleRef:
    kind: ClusterRole
    name: malicious-clusterrole
    apiGroup: rbac.authorization.k8s.io

• Privilege Escalation and Persistence: With these additional roles and bindings, attackers can escalate privileges, access sensitive data, deploy malicious workloads, and maintain persistence within the Kubernetes cluster.

• Stealth and Obfuscation Techniques: Attackers may use generic or misleading names for the created roles and bindings to blend in with legitimate administrative tasks, complicating detection efforts.

When this Technique is Usually Used

Adversaries commonly use this technique in various stages of the attack lifecycle:

• Privilege Escalation: Attackers who have gained initial footholds with limited privileges may create or modify cluster roles to escalate permissions and gain administrative control.

• Persistence: Attackers establish persistent access by binding malicious roles to compromised or attacker-controlled accounts, ensuring long-term access to the cluster.

• Lateral Movement: Additional roles can grant attackers permissions to access resources across namespaces, facilitating lateral movement within the containerized environment.

• Data Exfiltration: Attackers leverage elevated permissions to access sensitive data such as secrets, configuration files, or databases for exfiltration purposes.

• Impact and Disruption: Elevated privileges allow attackers to disrupt or manipulate workloads, services, and nodes, potentially leading to denial-of-service or sabotage scenarios.

How this Technique is Usually Detected

Detection of unauthorized or malicious cluster roles and bindings involves multiple approaches:

• Monitoring Kubernetes Audit Logs: Audit logs capture API requests, including creation or modification of cluster roles and bindings. Look for unusual or unexpected role creation events, especially those performed by unfamiliar or unexpected user accounts or service accounts.

• Role and Binding Enumeration and Baseline Comparison: Regularly enumerate existing cluster roles and bindings and compare them against secure baselines to identify unauthorized additions or modifications.

• Behavioral Anomaly Detection: Security tools and platforms designed for Kubernetes (e.g., Falco, Sysdig, Aqua Security, Prisma Cloud) can detect anomalous role creation activities and alert security teams.

• Indicators of Compromise (IoCs):

  • Unexpected cluster role or binding creations.

  • Cluster roles granting overly broad permissions (e.g., "*" verbs on sensitive resources).

  • Role bindings associating unknown or suspicious service accounts or user accounts.

  • Kubernetes audit log entries showing role creation or modification from unknown IP addresses or at unusual times.

• Security Information and Event Management (SIEM) Integration: Integrating Kubernetes audit logs and security events into SIEM solutions (e.g., Splunk, Elastic Stack, QRadar) enables correlation and alerting on suspicious role-related activities.

Why it is Important to Detect This Technique

Detecting unauthorized additional cluster roles is critical to maintaining the security and stability of containerized environments:

• Prevent Privilege Escalation: Early detection prevents attackers from escalating privileges and gaining administrative control over Kubernetes clusters.

• Limit Data Exposure and Exfiltration: Attackers with elevated permissions may access sensitive data, including secrets, credentials, and confidential information, leading to significant data breaches.

• Avoid Persistent Threats: Identifying malicious roles and bindings early prevents attackers from establishing persistent backdoors, reducing long-term risk and remediation complexity.

• Protect Operational Stability: Unauthorized roles could enable attackers to disrupt critical workloads, manipulate configurations, or cause denial-of-service, jeopardizing cluster stability and availability.

• Compliance and Regulatory Requirements: Timely detection and response to unauthorized access and privilege escalation activities are often mandated by security standards and regulations (e.g., PCI DSS, HIPAA, GDPR).

Examples

• TeamTNT Attacks on Kubernetes Clusters:

  • Attack Scenario: TeamTNT, a threat actor group, compromised Kubernetes clusters by exploiting misconfigured APIs and service accounts. They created additional cluster roles granting administrative privileges to deploy crypto-mining workloads.

  • Tools and Techniques: Automated scripts to enumerate roles, create malicious bindings, and deploy crypto-mining containers.

  • Impact: Resource hijacking, increased cloud bills, and potential lateral movement within cloud environments.

• Hildegard Malware Campaign:

  • Attack Scenario: Hildegard malware targeted Kubernetes clusters by exploiting vulnerable APIs and creating malicious cluster roles to escalate privileges and deploy crypto-mining operations.

  • Tools and Techniques: Leveraging Kubernetes API access to create cluster roles with broad permissions, deploying malicious containers, and hiding activities through obfuscated naming conventions.

  • Impact: Unauthorized resource consumption, degraded cluster performance, and potential access to sensitive data.

• Tesla Kubernetes Breach (Cryptojacking Incident):

  • Attack Scenario: Attackers gained access to Tesla's Kubernetes dashboard due to misconfigured access controls. They created additional cluster roles and deployed crypto-mining containers within the cluster.

  • Tools and Techniques: Exploitation of misconfigured Kubernetes dashboard, creation of additional cluster roles, deployment of cryptojacking workloads.

  • Impact: Unauthorized resource usage, increased cloud costs, and reputational damage.

These examples illustrate the real-world implications of attackers exploiting Additional Container Cluster Roles (T1098.006), highlighting the necessity of vigilant monitoring, detection, and prevention measures.