Auteur/autrice : zigmax

Deprecated VM alerts regarding suspicious activity related to a Kubernetes cluster


The following table lists the alerts that were deprecated:

Alert nameDescriptionTacticsSeverity
Docker build operation detected on a Kubernetes node
Machine logs indicate a build operation of a container image on a Kubernetes node. While this behavior might be legitimate, attackers might build their malicious images locally to avoid detection.Defense EvasionLow
Suspicious request to Kubernetes API
Machine logs indicate that a suspicious request was made to the Kubernetes API. The request was sent from a Kubernetes node, possibly from one of the containers running in the node. Although this behavior can be intentional, it might indicate that the node is running a compromised container.LateralMovementMedium
SSH server is running inside a container
Machine logs indicate that an SSH server is running inside a Docker container. While this behavior can be intentional, it frequently indicates that a container is misconfigured or breached.ExecutionMedium

These alerts are used to notify a user about suspicious activity connected to a Kubernetes cluster. The alerts will be replaced with matching alerts that are part of the Microsoft Defender for Cloud Container alerts (K8S.NODE_ImageBuildOnNodeK8S.NODE_ KubernetesAPI and K8S.NODE_ ContainerSSH) which will provide improved fidelity and comprehensive context to investigate and act on the alerts.



Azure Threat Research Matrix


In this article, I will share with you the Azure Threat Research Matrix. The purpose of the Azure Threat Research Matrix (ATRM) is to conceptualize the known tactics, techniques, and procedures (TTP) that adversaries may use against the Azure platform. Inspired from MITRE ATT&CK, ATRM is designed to give quick insight into a potential TTP that an adversary may be using in their attack campaign.

In comparison to MITRE ATT&CK, Azure does not have the same capabilities for some of the tactics, e.g. Initial Access. While some tactics in ATT&CK may pertain to Azure, the ATRM is meant to be specific within Azure AD and Azure Resources.



AKS | Image Cleaner


In this article, I will show you how you can clean unreferenced images stored at the nodes level. When done manually, this process can be time intensive, which ImageCleaner can mitigate via automatic image identification and removal.

ImageCleaner does not support the following:

  • Windows node pools
  • ARM64 node pools

When enabled, an eraser-controller-manager pod is deployed on each agent node, which will use an ImageList CRD to determine unreferenced and vulnerable images. Vulnerability is determined based on a trivy scan, after which images with a LOW, MEDIUM, HIGH, or CRITICAL classification are flagged.

An updated ImageList will be automatically generated by ImageCleaner based on a set time interval, and can also be supplied manually. Once an ImageList is generated, ImageCleaner will remove all the images in the list from node VMs.

To enable Image Cleaner on an existing AKS cluster:

az aks update -g MyResourceGroup -n MyManagedCluster --enable-image-cleaner

To enable Image Cleaner with an interval of hours:

az aks update -g MyResourceGroup -n MyManagedCluster --image-cleaner-interval-hours 48

Based on your configuration, ImageCleaner will generate an ImageList containing non-running and vulnerable images at the desired interval. ImageCleaner will automatically remove these images from cluster nodes.