Siloscape Malware Reportedly Targeting Windows ContainersMalware Capable of Compromising Kubernetes Clusters, Researchers Say
Researchers believe that a malware variant that specifically targets poorly protected or misconfigured Windows containers has been uncovered for the first time, according to a report published Monday by Palo Alto Networks' Unit 42.
See Also: The Essential Guide to Security
Dubbed Siloscape, the malware is capable of compromising a single container, escaping and then moving laterally, with the goal of accessing an entire Kubernetes cluster, says Daniel Prizmant, a senior security researcher with Unit 42.
"Compromising an entire cluster is much more severe than compromising an individual container, as a cluster could run multiple cloud applications whereas an individual container usually runs a single cloud application," Prizmant says.
The malware is not designed to deliver a specific type of attack but instead maintains persistence, which then allows the attacker to use the access as needed, he says.
"The attacker might be able to steal critical information such as usernames and passwords, an organization's confidential and internal files, or even entire databases hosted in the cluster. Malicious actors could even leverage a Siloscape attack to launch a ransomware attack by taking the organization's files hostage," Prizmant says.
So far, Siloscape has been used in 313 attacks, with 23 still active in an ongoing yearlong campaign, according to Prizmant, who first uncovered the malware in March.
That an attacker developed malware targeting Windows containers is not a surprise due to the massive surge in cloud adoption over the last few years, he notes.
The attacker's first step is to obtain remote code execution capability inside a Windows container. The attacker uses a known vulnerability or a vulnerable web page or database to gain initial access, Prizmant says.
Next, the attacker executes Siloscape. It impersonates CExecSvc.exe to obtain SeTcbPrivilege, which will enable it to escape the initial container, he says. Microsoft describes SeTcbPrivilege as the operating system that identifies its holder as a trusted user. This user right allows a process to impersonate any user without authentication, according to the research report.
Siloscape then creates a global symbolic link to the host, linking its containerized X drive to the host's C drive, and uses the global link to search for the kubectl.exe binary by name and the Kubernetes config file by regular expression on the host, the report notes
The malware then checks to see if the compromised node has enough privilege to create new Kubernetes deployments, which will enable it to escape. If so, Siloscape extracts the Tor client to the disk from an archived file using an unzip binary, Prizmant says.
Siloscape connects to the Tor network and uses the provided command-line argument to decrypt the command and control server's password. It then connects to that server using an onion domain, the report notes.
At this stage, Siloscape is ready to use, and it waits for its operator to issue a command, according to Unit 42.
Hard to Spot
Prizmant says Siloscape's developers went to great lengths to evade a target's defenses and to hide from researchers. Siloscape is heavily obfuscated with almost no readable strings in the entire binary, and Prizmant says even simple API calls are obfuscated.
"Instead of calling CreateFile, Siloscape calls NtCreateFile. Instead of calling NtCreateFile directly, Siloscape calls it dynamically, meaning it searches for the function name in ntdll.dll at runtime and jumps to its address," Prizmant says. "Not only that, but it also obfuscates the function and module names and deobfuscates them only at runtime. The end result is malware that is very difficult to detect with static analysis tools and frustrating to reverse engineer."
At this time, no patch or update exists. Prizmant says the best defense is to follow Microsoft's recommendation and not use Windows containers as a security feature.
"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 says.