First malware found escaping Windows containers to attack Kubernetes clusters

Security researcher Daniel Prizmant swings by campaign's C2 server...

First malware found escaping Windows containers to attack Kubernetes clusters

Security researchers at PaloAlto's Unit 42 say they have identified a "heavily obfuscated" Kubernetes malware that targets clusters after escaping Windows containers. Dubbing it Siloscape, they say its main purpose is to "open a backdoor into poorly configured Kubernetes clusters in order to run malicious containers."

Strikingly, security researcher Daniel Prizmant says he managed to gain access to the threat actor's C2 servers to pull detail on its techniques, despite them using the Tor proxy and an .onion domain to connect. He was spotted and kicked out after two minutes, but not before pulling some valuable intelligence on the campaign.

"Caught, dammit." Credit: Unit 42

With Kubernetes now the de facto standard for managing containerised workloads and services, and widely used by a growing number of enterprises to underpin their cloud-native applications, the finding is significant: Unit42's Daniel Prizmant describes it as the "first known malware targeting Windows containers."

Detailing the Kubernetes malware's behaviour on June 5, Prizmant said it initially targets "common cloud applications such as web servers for initial access, using known vulnerabilities", then uses Windows container escape techniques that Prizmant has detailed in an earlier post (e.g. Windows Kernel Elevation of Privilege Vulnerability CVE-2021-24096) to escape the container and gain code execution on the underlying node. It then attempts to abuse the node's credentials to spread in the cluster, connects to its command and control (C2) server using the IRC protocol over the Tor network, and waits for further commands.

See also: Hackers are using the Slack API, printer queue jobs for C2: Blue Teams need to look out for the C3 Framework

(Siloscape uses some novel and little documented techniques to escape the container, including one called "thread impersonation" Prizmant noted: "Siloscape mimics CExecSvc.exe privileges by impersonating its main thread and then calls NtSetInformationSymbolicLink on a newly created symbolic link to break out of the container. More specifically, it links its local containerized X drive to the host’s C drive.")

As Prizmant detailed on June 5: "I managed to gain access to [Siloscape's C2] server. We identified 23 active Siloscape victims and discovered that the server was being used to host 313 users in total... I also discovered that this campaign has been taking place for more than a year." His full  write-up and IOCs are here.

Kubernetes malware "heavily obfuscated"

The Kubernetes malware is heavily obfuscated, with "almost no readable strings in the entire binary." One of the keys to its C2 servers is hardcoded into the binary, while the other is supplied as a command line argument, Prizmand noted, adding: " I searched for its hash in multiple engines, such as AutoFocus and VirusTotal, and couldn’t find any results. This led me to believe that Siloscape is being compiled uniquely for each new attack, using a unique pair of keys. 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."

He concluded: "Users should follow Microsoft’s guidance recommending not to use Windows containers as a security feature. Microsoft recommends using strictly Hyper-V containers for anything that relies on containerization as a security boundary. 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.

"Furthermore, administrators should make sure their Kubernetes cluster is securely configured. In particular, 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."

Connect with The Stack on LinkedIn