AKS | Attack matrix v2 for Kubernetes


In this article, I would like to show you the new version of the attack matrix for Kubernetes. In this previous article, we reviewed the first version of the attack matrix for Kubernetes.

Deprecated techniques:

  • Kubernetes Dashboard: The Kubernetes dashboard’s usage has been in decline for a while now. Cloud-managed clusters, such as Microsoft’s AKS and Google’s GKE, deprecated this service and moved to a centralized interface in their portals. Moreover, the recent versions of the Kubernetes dashboard require authentication and it’s less likely to find exposed dashboards that do not require authentication.
  • Access tiller endpoint: As of version 3, Helm doesn’t use its server-side component, Tiller. This is a major improvement in the security of Helm. Currently, Helm operates (by default) on behalf of the user’s credentials as they appear in the kubeconfig file. Users of older versions of Helm are still affected by this technique.

New techniques:

  • Exposed sensitive interface: Examples of such interfaces that were seen exploited include Apache NiFi, Kubeflow, Argo Workflows, Weave Scope, and the Kubernetes dashboard.
  • Sidecar injection: A Kubernetes Pod is a group of one or more containers with shared storage and network resources. Sidecar container is a term that is used to describe an additional container that resides alongside the main container. For example, service-mesh proxies are operating as sidecars in the applications’ pods. Attackers can run their code and hide their activity by injecting a sidecar container to a legitimate pod in the cluster instead of running their own separated pod in the cluster.
  • Malicious admission Controller: Admission controller is a Kubernetes component that intercepts, and possibly modifies, requests to the Kubernetes API server. There are two types of admissions controllers: validating and mutating controllers. As the name implies, a mutating admission controller can modify the intercepted request and change its properties. Kubernetes has a built-in generic admission controller named MutatingAdmissionWebhook. The behavior of this admission controller is determined by an admission webhook that the user deploys in the cluster. Attackers can use such webhooks for gaining persistence in the cluster. For example, attackers can intercept and modify the pod creation operations in the cluster and add their malicious container to every created pod. In addition to persistency, a malicious admission controller can be used to access credentials. One of the built-in admission controllers in Kubernetes is ValidatingAdmissionWebhook. Like MutatingAdmissionWebhook, this admission controller is also generic, and its behavior is determined by an admission webhook that is deployed in the cluster. Attackers can use this webhook to intercept the requests to the API server, record secrets, and other sensitive information.
  • Access Managed Identities: Managed identities are identities that are managed by the cloud provider and can be allocated to cloud resources, such as virtual machines. Those identities are used to authenticate with cloud services. The identity’s secret is fully managed by the cloud provider, which eliminates the need to manage the credentials. Applications can obtain the identity’s token by accessing the Instance Metadata Service (IMDS). Attackers who get access to a Kubernetes pod can leverage their access to the IMDS endpoint to get the managed identity’s token. With a token, the attackers can access cloud resources.
  • CoreDNS poisoning: CoreDNS is a modular Domain Name System (DNS) server written in Go, hosted by Cloud Native Computing Foundation (CNCF). CoreDNS is the main DNS service that is being used in Kubernetes. The configuration of CoreDNS can be modified by a file named corefile. In Kubernetes, this file is stored in a ConfigMap object, located at the kube-system namespace. If attackers have permissions to modify the ConfigMap, for example by using the container’s service account, they can change the behavior of the cluster’s DNS, poison it, and take the network identity of other services.
  • ARP cache poisoning and IP spoofing: Kubernetes has numerous network plugins (Container Network Interfaces or CNIs) that can be used in the cluster. Kubenet is the basic, and in many cases the default, network plugin. In this configuration, a bridge is created on each node (cbr0) to which the various pods are connected using veth pairs. The fact that cross-pod traffic is through a bridge, a level-2 component, means that performing ARP poisoning in the cluster is possible. Therefore, if attackers get access to a pod in the cluster, they can perform ARP poisoning, and spoof the traffic of other pods. By using this technique, attackers can perform several attacks at the network-level which can lead to lateral movements, such as DNS spoofing or stealing cloud identities of other pods (CVE-2021-1677).
  • Images from private registry: The images that are running in the cluster can be stored in a private registry. For pulling those images, the container runtime engine (such as Docker or containerd) needs to have valid credentials to those registries. If the registry is hosted by the cloud provider, in services like Azure Container Registry (ACR) or Amazon Elastic Container Registry (ECR), cloud credentials are used to authenticate to the registry. If attackers get access to the cluster, in some cases they can obtain access to the private registry and pull its images. For example, attackers can use the managed identity token as described in the “Access managed identity credential” technique. Similarly, in EKS, attackers can use the AmazonEC2ContainerRegistryReadOnly policy that is bound by default to the node’s IAM role.

More information: https://www.microsoft.com/security/blog/2021/03/23/secure-containerized-environments-with-updated-threat-matrix-for-kubernetes/


Azure Disk | Data Exfiltration


In this article, I will show you how a malicious actor can leverage the Azure Managed Disk Import / Export feature to exfiltrate data outside of your organization. By default, in Azure all the Azure Disks are configured with a public endpoint enabled.

You can generate a time bound Shared Access Signature (SAS) URI for unattached managed disks and snapshots for exporting the data to other region for regional expansion, disaster recovery and to read the data for forensic analysis. When the URI is generated, you need to define an expiration time (maximum expiration time 4294967295 seconds). After that, everyone who knows the SAS URI can download the disk without any IP filtering before the expiration time.

To prevent this security issue, I will recommend you to:

  • Enable a Private endpoint (through disk access), or
  • Configure the connection method with : Deny all

If you want to know which managed disk are configured with the connectivity method « Public endpoint », you can use an Azure Policy in audit mode:

      "policyRule": {
      "if": {
        "allOf": [
            "field": "type",
            "equals": "Microsoft.Compute/disks"
              "field": "Microsoft.Compute/disks/networkAccessPolicy",
              "equals": "AllowAll"
      "then": {
        "effect": "audit"

And if you want to prevent this usage, you can switch the mode of this policy to « Deny ».


Add Custom Policy to Azure Security Center Recommendation


In this article, I will show you how you add a custom policy to Azure Security Center Recommendation.

These recommendations are based on industry best practices, which are incorporated into the generic, default security policy supplied to all customers. They can also come from Security Center’s knowledge of industry and regulatory standards.

With this feature, you can add your own custom initiatives. You’ll then receive recommendations if your environment doesn’t follow the policies you create.

In the Azure Security Center Portal, please select « Regulatory compliance » under « Cloud Security ».

Select, « Manage compliance policies »

Select « Add a custom initiative »

Select, « Creare New »

Please define:

  • Initiative location
  • Demo (Name of your custom initiative, for example XYZ Security Controls)
  • Category > Create new > Demo (Your category name could be storage, network, …)
  • Version 1

Select « Add policy definition(s) »

Select your policies, in this example: « Storage accounts should have infrastructure encryption »

Select « Create Control »

Define a new control, in this example Storage, with the Domain Storage security

Now the custom initiatives is created, please click on « add ».

Please find wait 1 hours before to see our custom initiative in the Azure Security Center Recommendation section.

After 1 hours, we can see our custom initiative in the Azure Security Center Recommendation section:

It’s also possible to Azure Resource Graph to see this custom policies.

| where type == "microsoft.security/assessments"
| extend resourceId = properties.resourceDetails.Id
| extend resourceName = tostring(split(resourceId, "/")[8])
| extend resourceGroup = (split(resourceId, "/")[4])
| extend status = properties.status.code
| extend recommendatioName = properties.displayName 
| project subscriptionId,