Windows Container Malware Targets Kubernetes Clusters

Reading Time: 2 Minutes

Windows containers have been victimized for over a year by the first known malware to target Windows containers. The ongoing campaign pierces Kubernetes clusters so as to plant backdoors, allowing attackers to steal data and user credentials, or even hijack an entire databases hosted in a cluster

The malware was discovered by Unit 42 security researcher Daniel Prizmant. He dubbed it Siloscape, which he pronounces “Silo escape.” The malware pries open known vulnerabilities in web servers and databases so as to compromise Kubernetes nodes and to backdoor clusters.

In a post published on Monday, Prizmant wrote that Siloscape is heavily obfuscated malware targeting Kubernetes clusters through Windows containers, with the main purpose of opening “a backdoor into poorly configured Kubernetes clusters in order to run malicious containers.”

See Also: GitHub’s new policies allow removal of PoC exploits used in attacks

See Also: Offensive Security Tool: Pacu – The Amazon Web Services Exploitation Framework

How Siloscape Escapes

The malware starts by targeting known vulnerabilities – “1-days” – in common cloud applications, such as web servers. This initial access is presumably gained by using exploits found in the wild. Last year, Prizmant documented one such way to break Windows container boundaries. In a report published in 2020, he described what attackers could do if they escaped from a container.

He chose to focus on the current scenario: An escape from a Windows cluster node in Kubernetes that would allow an attacker to gain access outside the node and spread into the cluster.

After it compromises web servers, Siloscape uses container escape tactics to achieve code execution on the Kubernetes node. Prizmant said that Siloscape’s heavy use of obfuscation made it a chore to reverse-engineer. “There are almost no readable strings in the entire binary. While the obfuscation logic itself isn’t complicated, it made reversing this binary frustrating,” he explained.

The malware obfuscates functions and module names – including simple APIs – and only deobfuscates them at runtime. Instead of just calling the functions, Siloscape “made the effort to use the Native API (NTAPI) version of the same function,” he said. “The end result is malware that is very difficult to detect with static analysis tools and frustrating to reverse engineer.”

“Siloscape is being compiled uniquely for each new attack, using a unique pair of keys,” Prizmant continued. “The hardcoded key makes each binary a little bit different than the rest, which explains why I couldn’t find its hash anywhere. It also makes it impossible to detect Siloscape by hash alone.”

See Also: Jeff Moss, aka Dark Tangent, the person who founded DEF CON and Black Hat

What Siloscape Does After Escape

After Siloscape compromises nodes, the malware sniffs around for credentials that enable it to spread to other nodes in the Kubernetes cluster. Then, it reaches out to its C2 server via IRC – an old protocol – over the Tor anonymous communication network and sits idle, waiting for commands.

Prizmant adopted a username that he figured would look legitimate when he connected to the C2 server. Once he successfully connected, he found it was still working and that there were 23 “active victims”, plus a channel operator named admin.

But his presence didn’t go undetected. After about 2 minutes, he was kicked out of the server. Two minutes after that, the server was shut down – at least, it was no longer active at the original onion domain that he used to connect.

But that was just a slice of the entire campaign. He actually saw that in the #WindowsKubernetes channel he accessed there were far more than those 23 users. In fact there were a total of 313 users. He wouldn’t be able to identify, contact or warn any of them, however.

“Sadly, when I connected to the server, the channels list was empty, indicating that the server was configured to not reveal its channels,” Prizmant wrote. “Therefore, I couldn’t get more information from the channel names.”

But the researcher did manage to glean an important detail. Namely, the convention used for the victims’ names. Unit 42 researchers used the name “php_35”, which its sample of Siloscape executed through a vulnerable php instance. Other names that included the string “sqlinj” indicate that the attacker probably managed to achieve code execution via SQL injection.

Danger of Cryptojacking, Supply-Chain Poisoning & More

In his July 2020 post, Prizmant said that his research suggested that “running any code in [Windows Server Containers] should be considered as dangerous as running admin on the host. These containers are not designed for sandboxing, and I found that escaping them is easy.”

This could enable an attacker to steal critical credentials, confidential and internal files, or even entire databases hosted in the cluster, he warned in Monday’s post. It could even lead to a ransomware attack if attackers take an organization’s files hostage. Even worse, he said, is the threat presented by organizations’ mass move to the cloud. Given that many are using Kubernetes clusters to develop and test code, a breach “can lead to devastating software supply chain attacks,” he said.

In Monday’s post, he explained that compromising an entire cluster is much more severe than compromising an individual container, given that “a cluster could run multiple cloud applications whereas an individual container usually runs a single cloud application.”

He noted that Siloscape isn’t like most cloud malware, which typically focuses on resource hijacking for things like cryptomining and DoS. Siloscape, on the other hand, “doesn’t limit itself to any specific goal,” Prizmant said. “Instead, it opens a backdoor to all kinds of malicious activities.”

Recent Supply-Chain & Kubernetes Attacks

Supply-chain attacks similar to what Prizmant warned about have been linked to spyware installation, Operation SignSight, the compromise of Able Desktop, airline breaches, and the supply-chain whopper of them all: the SolarWinds breach of the U.S. government.

As far as other Kubernetes catastrophes go, a few recent headlines include an April 2021 security bug that allowed attackers to brick Kubernetes clusters: A vulnerability in one of the Go libraries that Kubernetes is based on that could lead to denial of service (DoS) for the CRI-O and Podman container engines. Earlier in April, an organized, self-propagating cryptomining campaign was uncovered that targeted misconfigured open Docker Daemon API ports. Thousands of container-compromise attempts were being observed every day related to the campaign.

Also in April, Microsoft’s cloud-container technology, Azure Functions, was found to harbor a weakness that allows attackers to directly write to files, researchers said. A few months earlier, in February 2021, a new malware was hjacking Kubernetes clusters to cryptomine Monero.

Another example of why cloud infrastructure needs strong security, a simple Docker container honeypot was used for four different criminal campaigns in the span of 24 hours, in a recent lab test.

Having Your Cloud Cake & Eating It, Too

Trevor Morgan, product manager with enterprise data security firm comforte AG, thinks that Siloscape is the kind of threat that can make organizations nervous about adopting cloud. “Enterprises adopt cloud native strategies because they want to accelerate their ability to innovate. Unfortunately, most organizations struggle with the right level of data security to avoid compromise with cloud native application architectures,” he told Threatpost via email on Monday.

“Malware like Siloscape complicates this endeavor by striking at the core of containerization and creates real hesitation on the part of cloud native development efforts, threatening to slow down these processes and defeat the very agility these organizations seek,” he pointed out. “Malware threats set up a false choice between being nimble and being cautious and secure with sensitive data.”

Morgan suggested that data-centric security such as tokenization, built specifically for cloud native applications, “can help strike the right balance between these two,” by protecting the data itself rather than “the layered, even amorphous borders surrounding cloud native application environments.

“Organizations can be assured that data security does not impede speed and agility, because tokenized sensitive information even in containers cannot be compromised if it falls into the wrong hands,” he said. “Organizations adopting cloud native strategies can have their data security while achieving agility too.”

What to Do

Prizmant recommended that users follow Microsoft’s advice to not use Windows containers as a security feature. Instead, Microsoft recommends using strictly Hyper-V containers for anything that relies on containerization as a security boundary, he noted.” Any process running in Windows Server containers should be assumed to have the same privileges as admin on the host, which in this case is the Kubernetes node. If you are running applications in Windows Server containers that need to be secured, we recommend moving these applications to Hyper-V containers,” he said.

Secure configuration of Kubernetes clusters is also crucial. “A secured Kubernetes cluster won’t be as vulnerable to this specific malware as the nodes’ privileges won’t suffice to create new deployments. In this case, Siloscape will exit,” Prizmant said.

“Siloscape shows us the importance of container security, as the malware wouldn’t be able to cause any significant damage if not for the container escape,” he wrote. “It is critical that organizations keep a well-configured and secured cloud environment to protect against such threats.”

Source: threatpost.com

(Click Link)