Microsoft revealed an attack that takes advantage of new critical vulnerabilities in OpenMetadata to access Kubernetes workloads and utilize them for cryptomining activity.

These vulnerabilities (CVE-2024-28255, CVE-2024-28847, CVE-2024-28253, CVE-2024-28848, CVE-2024-28254) are known to affect versions prior to 1.3.1. Attackers could exploit them to outflank authentication and gain remote code execution.

How does the attack happen?

Initially, the attackers detect and target Kubernetes workloads of OpenMetadata that are exposed to the internet for entry.

After identifying the vulnerable version of the app, the hackers exploit the above-mentioned vulnerabilities to execute code on the container running the vulnerable OpenMetadata image.

Once they gain a foothold, these attackers try to validate their successful intrusion and evaluate the level of control over the affected system. This reconnaissance phase usually includes contacting a publicly accessible service.

In this type of attack, the hackers send ping requests to domains ending with oast[.]me and oast[.]pro, linked with Interactsh, an open-source tool used for detecting out-of-band interactions.

OAST domains, publicly resolvable yet distinctive, let attackers determine network connectivity from the infiltrated system to the attacker’s infrastructure discreetly. This allows them to verify successful exploitation without raising any suspicious outbound traffic that could trigger security alerts.

In addition, this method is beneficial for attackers because it allows them to confirm their connection with the infected device before establishing a command-and-control (C2) channel and deploying malicious payloads.

Once they have initial access, hackers execute a series of reconnaissance commands to collect information such as OS version, network and hardware configuration, active users, and more to learn about the infiltrated system’s environment. Moreover, they also read the workload’s environment variables.

In OpenMetadata’s scenario, the variables could possibly involve connection strings and credentials for various services utilized for OpenMetadata’s operation. If these are exploited, this information could be used to execute lateral movement within the network, leading to gaining access to additional resources and escalating attacks.

After confirming their access and ensuring connectivity, the hackers download the payload, a crypto mining-related malware, from a remote server.

This what Microsoft found:

 We observed the attackers using a remote server located in China. The attacker’s server hosts additional cryptomining-related malware that are stored, for both Linux and Windows OS.

The downloaded file’s permissions are then elevated to grant execution privileges. The attacker also added a personal note to the victims:

Once done, hackers run the downloaded malware and remove the initial payloads from the workload. Finally, to engage in hands-on keyboard activity, the attackers establish a reverse shell connection to their remote server with the help of the Netcat tool. This will allow them to remotely access the container and take more control over the system.

Furthermore, these attackers use cronjobs for task scheduling, allowing them to execute malicious code at set intervals.

How do you identify if your cluster is vulnerable?

Admins who use the OpenMetadata workloads in their cluster should make sure that the image they are using is then the latest one.

To avoid OpenMetadata being exposed to the Internet, it is recommended that strong authentication measures be used and that default credentials be avoided.

If you want to get a list of all the images running in the cluster, use this command

kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{.spec.containers[*].image}{"\n"}{end}' | grep 'openmetadata'

If you find any of the pods with a vulnerable image, ensure you update the image to the newest version.

How can Microsoft Defender for Containers help?

To avoid these attacks, Microsoft Defender for Containers is a robust security solution that provides agentless vulnerability assessment for Azure, AWS, and GCP. This allows you to detect vulnerable images in the environment before the attack.

Another good security solution to monitor Kubernetes clusters can be Microsoft Sentinel via Azure Kubernetes Service (AKS) solution for Sentinel, which provides an audit trail to keep an eye on user and system actions to detect suspicious activities.

Here are the indicators of compromise (IoCs) mentioned by security researchers in Microsoft:

Type	IoC
Executable SHA-256	7c6f0bae1e588821bd5d66cd98f52b7005e054279748c2c851647097fa2ae2df
Executable SHA-256	19a63bd5d18f955c0de550f072534aa7a6a6cc6b78a24fea4cc6ce23011ea01d
Executable SHA-256	31cd1651752eae014c7ceaaf107f0bf8323b682ff5b24c683a683fdac7525bad
IP	8[.]222[.]144[.]60
IP	61[.]160[.]194[.]160
IP	8[.]130[.]115[.]208

To avoid being victimized by this attack, Microsoft recommends users check clusters that run OpenMetadata workload and ensure the image is up to date (version 13.1 or later).

What are your thoughts on the matter? Share your opinions with our readers in the comments section below.