Admission-Controller — CraftedSignal Threat Feedhttps://feed.craftedsignal.io/tags/admission-controller/Trending threats, MITRE ATT&CK coverage, and detection metadata — refreshed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioFri, 01 Nov 2024 12:00:00 +0000Kubernetes Admission Controller Modificationhttps://feed.craftedsignal.io/briefs/2024-11-kubernetes-admission-controller-modification/Fri, 01 Nov 2024 12:00:00 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2024-11-kubernetes-admission-controller-modification/An adversary modifies Kubernetes admission controller configurations to achieve persistence, escalate privileges, or gain unauthorized access to credentials within the cluster.The Kubernetes admission controller is a crucial component that governs API requests to a Kubernetes cluster. Attackers can modify mutating or validating webhook configurations to intercept and manipulate these requests. By creating, updating, or replacing these configurations, adversaries can inject malicious code, alter resource definitions, or even exfiltrate sensitive information like access credentials. This activity can lead to privilege escalation, persistence within the cluster, and ultimately, a compromise of the entire Kubernetes environment. The attacks are typically stealthy as they operate within the legitimate Kubernetes API framework, making detection challenging. This behavior is particularly concerning for organizations relying on Kubernetes for critical applications and sensitive data.

Attack Chain

  1. Initial Access: The attacker gains initial access to the Kubernetes cluster, potentially through compromised credentials or a vulnerability in a deployed application.
  2. Discovery: The attacker enumerates existing admission controller configurations (mutatingwebhookconfigurations and validatingwebhookconfigurations) to identify potential targets.
  3. Configuration Modification: The attacker uses kubectl or the Kubernetes API to create, update, or replace a webhook configuration. This involves crafting a malicious webhook that will intercept API requests.
  4. Webhook Deployment: The malicious webhook is deployed as a service within the Kubernetes cluster.
  5. API Interception: When a user or application makes an API request that matches the webhook’s defined rules, the webhook intercepts the request.
  6. Malicious Code Injection: The webhook injects malicious code or alters the API request to achieve the attacker’s objectives (e.g., granting unauthorized permissions, modifying resource configurations).
  7. Persistence/Privilege Escalation/Credential Access: Depending on the injected code, the attacker achieves persistence by ensuring malicious code is always present, escalates privileges by modifying role bindings, or accesses credentials by intercepting secret creation requests.
  8. Lateral Movement/Data Exfiltration: The attacker leverages their gained access to move laterally within the cluster or exfiltrate sensitive data.

Impact

Successful modification of Kubernetes admission controllers can have severe consequences. This can result in unauthorized access to sensitive data, complete cluster compromise, and denial of service. The impact ranges from data breaches and service disruptions to long-term persistence within the environment, allowing attackers to maintain control over the cluster. The stealthy nature of this attack makes it difficult to detect, potentially allowing attackers to operate undetected for extended periods.

Recommendation

  • Deploy the Sigma rule “Kubernetes Admission Controller Modification” to your SIEM and tune it for your environment to detect suspicious modifications to webhook configurations (logsource: kubernetes, service: audit).
  • Monitor Kubernetes audit logs for create, delete, patch, replace, and update verbs on mutatingwebhookconfigurations and validatingwebhookconfigurations resources (logsource: kubernetes, service: audit).
  • Implement strong RBAC policies to limit access to Kubernetes API resources and prevent unauthorized modification of admission controller configurations.
  • Regularly review and audit existing admission controller configurations to identify any unexpected or malicious webhooks.
]]>mediumadvisorykubernetesadmission-controllerprivilege-escalationpersistencecredential-accessMalicious Azure Kubernetes Admission Controller Configurationhttps://feed.craftedsignal.io/briefs/2024-01-azure-kubernetes-admission-controller/Wed, 03 Jan 2024 15:30:00 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2024-01-azure-kubernetes-admission-controller/An adversary can exploit Kubernetes Admission Controllers in Azure to achieve persistence, privilege escalation, or credential access by manipulating webhook configurations.Kubernetes Admission Controllers are critical components that intercept and potentially modify requests to the Kubernetes API server. These controllers rely on admission webhooks (MutatingAdmissionWebhook or ValidatingAdmissionWebhook) deployed within the cluster. A malicious actor can abuse these webhooks to establish persistence by modifying pod creation operations and injecting malicious containers into new pods via MutatingAdmissionWebhook. Alternatively, ValidatingAdmissionWebhook can be used to intercept API server requests, potentially exposing secrets and sensitive information. This activity allows for credential access and privilege escalation, impacting the overall security posture of the Kubernetes cluster.

Attack Chain

  1. The attacker gains initial access to the Azure Kubernetes cluster, possibly through compromised credentials or a vulnerability in a deployed application.
  2. The attacker identifies the existing Admission Controller configuration within the Kubernetes cluster.
  3. The attacker crafts a malicious MutatingAdmissionWebhook configuration to intercept pod creation requests.
  4. The malicious webhook is deployed to the cluster, configured to modify pod specifications.
  5. When new pods are created, the webhook injects a malicious container into the pod specification before deployment.
  6. The malicious container executes within the newly created pod, providing the attacker with persistent access to the cluster.
  7. Alternatively, the attacker crafts a malicious ValidatingAdmissionWebhook to intercept API requests.
  8. The webhook captures sensitive data, such as secrets, and sends it to an attacker-controlled server, resulting in credential access.

Impact

Compromising the Kubernetes Admission Controller can lead to persistent access within the cluster. The attacker can inject malicious containers into numerous pods, potentially affecting all applications deployed in the cluster. Sensitive information, like secrets, can be stolen, enabling lateral movement and privilege escalation within the Azure environment. The impact ranges from data breaches to complete cluster compromise.

Recommendation

  • Deploy the Sigma rule “Azure Kubernetes Admission Controller Configuration Change” to detect unauthorized modifications to Admission Controller configurations in Azure Activity Logs.
  • Regularly review and audit existing Admission Controller configurations for any unexpected or malicious webhooks.
  • Implement strong RBAC policies to restrict access to Admission Controller configuration and prevent unauthorized modifications.
  • Monitor Azure Activity Logs for MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/ADMISSIONREGISTRATION.K8S.IO and MICROSOFT.CONTAINERSERVICE/MANAGEDCLUSTERS/ADMISSIONREGISTRATION.K8S.IO operations to identify potential abuse.
]]>mediumadvisoryazurekubernetesadmission-controllerpersistenceprivilege-escalationcredential-access