First Known Malware Targeting Windows Containers to Compromise Cloud Environment - Siloscape

From Hildegard malware that compromised Tesla’s clusters to the recent malware from TeamTNT that has compromised nearly 50000 clusters, the most popular container orchestrator, Kubernetes, has recently been a prime target of threat actors. This can be associated with the massive adoption of the technology in recent years.

However, the new malware, Siloscope, is different from the known malware targeted at Kubernetes clusters on Linux containers — being the most common operating system used in cloud environments. Siloscope is designed to aim at Windows containers precisely.

In a report published by a Palo Alto Network, a renowned cybersecurity firm, the Unit 42 researcher explains that he named the malware “Siloscape” because the malware intends to escape a Windows container through a server silo.

The Windows-targeted malware was first uncovered in March this year. It accesses Windows containers through web servers or pages, executes some obscured actions to stay undetected until it escapes into the Kubernetes cluster, and establishes a connection with the attacker to conduct their malicious activities in the Kubernetes cluster.

In the course of his findings, the Unit 42 researcher was able to get into the server and confirms that the malware was still running with up to 23 active victims and a total of 313 victims, stating that the malware may have been active for over a year.

The researcher was, however, noticed by the attacker and kicked out of the server within a few minutes.

Let's dig into the details of how this malware penetrates a Kubernetes cluster.

How Sloscape Attacks Windows Containers and Kubernetes Clusters

The Siloscape malware follows a sequential technique to carry out its designated task — to access Kubernetes clusters in Windows containers.

The image above is a pictorial representation of the malware’s execution flow. Let's look into the flow in detail, as established by the Palo Alto Unit.

Access The Windows Container

The first action the Siloscape malware takes is to initiate initial access into Windows containers using the Windows Server (other than the Hyper-V virtualization). It then launches Siloscape's CloudMalware.exe file and establishes remote code execution (RCE) connection by exploiting known vulnerabilities of servers, web pages, and databases.

Evades Detection

To resist easy detection, Siloscape is designed with some defense evasion techniques. One of these techniques is code obfuscation.

Siloscape uses a highly obscure binary codebase to make the code complicated and less readable.

For every function or API call in the binary code, Siloscape uses a more complicated version of the function, Native_API in this case, or goes the long route by calling the function dynamically. This implies the called function name will be searched in the ntdll.dll and executed at runtime.

This technique makes it difficult to detect the malware using static analysis tools or performing reverse engineering.

As part of Siloscape obfuscation techniques, it also hard-coded one of the key pairs to decrypt its C2 server password. Siloscape uses a pair of two keys to decrypt the C2 server password. One is hard-coded in its binary, and the other is attached as a command-line argument. This suggests that Siloscape is compiled with unique keys for each attack. It also makes it impossible to detect Siloscape with hash alone.

The above image shows the obscure code of Siloscape as it appeared in an Interactive Disassembler (IDA).

Escape The Container

After gaining access into the container by exploiting vulnerabilities and dodging from defense using obfuscation, Siloscape uses a Windows container escape technique to escape the container and gain deployment privilege on the node where it is currently running.

The technique Siloscape uses here is a rare technique termed "thread impersonation.”

It uses an NTAP function called NtImpersonateThread to mimic CExecSvc.exe privileges of the Kubernetes node by impersonating its main thread to obtain SetcbPrivilege privileges, after which the system calls NtSetInformationSymbolicLink that enables the escape.

It then creates a Symbolic link to the host, linking its containerized X drive to the host's C drive.

Spreading In The Cluster

After escaping the container by linking directly to the host, Siloscape calls a FindFile function. This searches for two files, kubectl.exe and the Kubernetes config file, on the Kubernetes nodes — with the search function(FindFile) taking an argument that specifies which files to exclude from the search.

The search excludes the Program files (x86), Windows, and Users folders to search faster because it is unlikely for the Kubernetes config and kubectl files to be located in these folders.

When it finds both files on the Kubernetes node, Siloscape saves the path of the files as a global variable. And if it could not locate the Kubernetes config and kubectl files, it simply exits and stops the attack.

In the case where Siloscape finds both files, it proceeds to check if the host Kubernetes node has enough permission to create new deployments by executing a kubectl command taking the previously saved path as a variable.

Connecting to the C2 Server

Having obtained the file path and checking if the compromised node has enough privileges, Siloscape sends a zipped Tor file and an unzipped binary to the host's C drive for extraction. It then launches the tor.exe file to a new thread while checking the Tor thread output to ensure Tor launches and runs successfully.

Siloscape then uses Tor to connect to its IRC command-and-control (C2) server using a .onion address provided as a command-line argument by the attacker at the initial launch.

Siloscape decrypts the password to the C2 server using a byte-by-byte exclusive OR (XOR). Here is a simplified version of the password decryption;

On successful password decryption and connection to the C2 server, Siloscape runs a JOIN #WindowsKubernetes command to join the Windows IRC channels, awaiting further instructions afterward.

Siloscape compares instructions it receives using the function below and only executes those from a user named admin.

However, it takes two types of instructions from the admin user; one starts with K, which it executes as a kubectl command, and another that begins with C, which runs as a regular Windows cmd command.

After gaining access into the Kubernetes cluster and establishing a connection with the attacker through the C2 server, the Siloscape malware stays idle in the Kubernetes node. It only acts when the attacker sends a command.

How To Protect Your Windows Container Against Siloscape

Any resources running on a Server container are assumed to have the same privilege as admin on the Kubernetes node.

Microsoft recommends that you should use Windows Server containers as standard containers rather than as a security feature. It stressed that only Hyper-V containers should be used for applications or activities that rely on a Windows container as a security boundary.

Another important tip is to ensure that your Kubernetes cluster is configured with security in mind. A securely configured Kubernetes cluster will not give deployment privileges to normal nodes, thereby rendering malware like Siloscape unharmful.