{
	"id": "22f1969e-2e2e-4399-9bcc-88f0c23af742",
	"created_at": "2026-04-06T00:22:19.883151Z",
	"updated_at": "2026-04-10T03:23:52.008692Z",
	"deleted_at": null,
	"sha1_hash": "0e86d45069a56d03da300800a2df64942fd9d039",
	"title": "Siloscape: First Known Malware Targeting Windows Containers to Compromise Cloud Environments",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 965240,
	"plain_text": "Siloscape: First Known Malware Targeting Windows Containers to\r\nCompromise Cloud Environments\r\nBy Daniel Prizmant\r\nPublished: 2021-06-07 · Archived: 2026-04-05 14:21:01 UTC\r\nExecutive Summary\r\nIn March 2021, I uncovered the first known malware targeting Windows containers, a development that is not\r\nsurprising given the massive surge in cloud adoption over the past few years. I named the malware Siloscape\r\n(sounds like silo escape) because its primary goal is to escape the container, and in Windows this is implemented\r\nmainly by a server silo.\r\nSiloscape is heavily obfuscated malware targeting Kubernetes clusters through Windows containers. Its main\r\npurpose is to open a backdoor into poorly configured Kubernetes clusters in order to run malicious containers.\r\nCompromising an entire cluster is much more severe than compromising an individual container, as a cluster\r\ncould run multiple cloud applications whereas an individual container usually runs a single cloud application. For\r\nexample, the attacker might be able to steal critical information such as usernames and passwords, an\r\norganization’s confidential and internal files or even entire databases hosted in the cluster. Such an attack could\r\neven be leveraged as a ransomware attack by taking the organization's files hostage. Even worse, with\r\norganizations moving to the cloud, many use Kubernetes clusters as their development and testing environments,\r\nand a breach of such an environment can lead to devastating software supply chain attacks.\r\nSiloscape uses the Tor proxy and an .onion domain to anonymously connect to its command and control (C2)\r\nserver. I managed to gain access to this server. We identified 23 active Siloscape victims and discovered that the\r\nserver was being used to host 313 users in total, implying that Siloscape was a small part of a broader campaign. I\r\nalso discovered that this campaign has been taking place for more than a year.\r\nThis report provides background on Windows container vulnerabilities, gives a technical overview of Siloscape\r\nand offers recommendations on best practices for securing Windows containers.\r\nPalo Alto Networks customers are protected from this threat with Prisma Cloud’s Runtime Protection features.\r\nWindows Server Container Vulnerabilities Overview\r\nOn July 15, 2020, I released an article about Windows container boundaries and how to break them. In that article,\r\nI presented a technique for escaping from a container and discussed some potential applications that such an\r\nescape can have in the hands of an attacker. The most significant application, and the one I chose to focus on, was\r\nan escape from a Windows container node in Kubernetes in order to spread in the cluster.\r\nhttps://unit42.paloaltonetworks.com/siloscape/\r\nPage 1 of 12\n\nMicrosoft originally didn’t consider this issue a vulnerability, based on the reasoning that Windows Server\r\ncontainers are not a security boundary, and therefore each application that is being run inside a container should be\r\ntreated as if it is executed directly on the host.\r\nA few weeks after that discussion, I reported the issue to Google because Kubernetes is vulnerable to those issues.\r\nGoogle contacted Microsoft, and after some back and forth, it was determined by Microsoft that an escape from a\r\nWindows container to the host, when executed without administrator permissions inside the container, will in fact\r\nbe considered a vulnerability.\r\nFollowing this, I discovered Siloscape, which is malware that actively attempts to exploit Windows Server\r\ncontainers in the wild. Siloscape is heavily obfuscated malware targeting Kubernetes through Windows containers\r\n(using Server Containers and not Hyper-V). Its main purpose is to open a backdoor into poorly configured\r\nKubernetes clusters in order to run malicious containers such as, but not limited to, cryptojackers.\r\nThe malware is characterized by several behaviors and techniques:\r\nTargets common cloud applications such as web servers for initial access, using known vulnerabilities (“1-\r\ndays”) – presumably those with a working exploit in the wild.\r\nUses Windows container escape techniques to escape the container and gain code execution on the\r\nunderlying node.\r\nAttempts to abuse the node's credentials to spread in the cluster.\r\nConnects to its C2 server using the IRC protocol over the Tor network.\r\nWaits for further commands.\r\nThis malware can leverage the computing resources in a Kubernetes cluster for cryptojacking and potentially\r\nexfiltrate sensitive data from hundreds of applications running in the compromised clusters.\r\nInvestigating the C2 server showed that this malware is just a small part of a larger network and that this campaign\r\nhas been taking place for over a year. Furthermore, I confirmed that this specific part of the campaign was online\r\nwith active victims at the time of writing.\r\nTechnical Overview\r\nBefore diving into the technical details of Siloscape, it is important to get a better understanding of its overall\r\nbehavior and flow.\r\nhttps://unit42.paloaltonetworks.com/siloscape/\r\nPage 2 of 12\n\nFigure 1. Execution flow of Siloscape.\r\n1. The attacker achieves remote code execution (RCE) inside a Windows container using a known\r\nvulnerability or a vulnerable web page or database.\r\n2. The attacker executes Siloscape (CloudMalware.exe) with the necessary C2 connection information\r\nprovided as command line arguments (and not hardcoded inside the binary).\r\n3. Siloscape impersonates CExecSvc.exe to obtain SeTcbPrivilege privileges (this technique is described in\r\ndetail in my previous article).\r\n4. Siloscape creates a global symbolic link to the host, practically linking its containerized X drive to the\r\nhost’s C drive.\r\n5. Siloscape searches for the kubectl.exe binary by name and the Kubernetes config file by regular expression\r\non the host, using the global link.\r\n6. Siloscape checks if the compromised node has enough privilege to create new Kubernetes deployments.\r\n7. Siloscape extracts the Tor client to the disk from an archived file using an unzip binary. Both files are\r\npacked into the main Siloscape binary.\r\n8. Siloscape connects to the Tor network.\r\n9. Using the provided command line argument, Siloscape decrypts the C2 server’s password.\r\n10. Siloscape connects to the C2 server using an .onion domain (a domain accessible through the Tor network)\r\nprovided as a command line argument.\r\n11. Siloscape waits for commands from the C2 and executes them.\r\nUnlike other malware targeting containers, which are mostly cryptojacking-focused, Siloscape doesn’t actually do\r\nanything that will harm the cluster on its own. Instead, it focuses on being undetected and untraceable and opens a\r\nbackdoor to the cluster.\r\nDefense Evasion and Obfuscation\r\nhttps://unit42.paloaltonetworks.com/siloscape/\r\nPage 3 of 12\n\nSiloscape is heavily obfuscated. There are almost no readable strings in the entire binary. While the obfuscation\r\nlogic itself isn’t complicated, it made reversing this binary frustrating.\r\nFigure 2. Strings obfuscation as it looks in Interactive Disassembler (IDA).\r\nEven simple API calls were obfuscated, and instead of just calling the functions, Siloscape made the effort to use\r\nthe Native API (NTAPI) version of the same function.\r\nhttps://unit42.paloaltonetworks.com/siloscape/\r\nPage 4 of 12\n\nFigure 3. Dynamic search of functions in ntdll.dll.\r\nFor example, instead of calling CreateFile, Siloscape calls NtCreateFile. Instead of calling NtCreateFile directly,\r\nSiloscape calls it dynamically, meaning it searches for the function name in ntdll.dll at runtime and jumps to its\r\naddress. Not only that, but it also obfuscates the function and module names and deobfuscates them only at\r\nhttps://unit42.paloaltonetworks.com/siloscape/\r\nPage 5 of 12\n\nruntime. The end result is malware that is very difficult to detect with static analysis tools and frustrating to\r\nreverse engineer.\r\nSiloscape uses a pair of keys to decrypt the C2 server’s password. One of the most important features of its\r\nobfuscation is that one key is hardcoded into the binary, while the other is supplied as a command line argument. I\r\nsearched for its hash in multiple engines, such as AutoFocus and VirusTotal, and couldn’t find any results. This led\r\nme to believe that Siloscape is being compiled uniquely for each new attack, using a unique pair of keys. The\r\nhardcoded key makes each binary a little bit different than the rest, which explains why I couldn’t find its hash\r\nanywhere. It also makes it impossible to detect Siloscape by hash alone.\r\nFigure 4. Siloscape using Visual Studio Resource Manager.\r\nAnother interesting technique this malware uses is Visual Studio’s Resource Manager. This is a feature built into\r\nVisual Studio that allows one to attach basically any file to the original binary and get a pointer to its data with a\r\nfew simple API calls. Siloscape uses this method to write the Tor archive to the disk, as well as the unzip binary\r\nused to open the archive. It also uses Tor to securely connect to its C2.\r\nThe Container Escape\r\nOne of the more interesting things about Siloscape is the way it escapes the container. To execute the system call\r\nNtSetInformationSymbolicLink that enables the escape, one must gain SeTcbPrivilege first. There are a few ways\r\nhttps://unit42.paloaltonetworks.com/siloscape/\r\nPage 6 of 12\n\nto do this. For example, in my tests, I injected a DLL into CExecSvc.exe, which has the relevant privileges, and\r\nexecuted NtSetInformationSymbolicLink from the CExecSvc.exe context. Siloscape, however, uses a technique\r\ncalled Thread Impersonation. This method has little documentation online and even fewer working examples. The\r\nmost critical function for this technique is the undocumented system call NtImpersonateThread.\r\nSiloscape mimics CExecSvc.exe privileges by impersonating its main thread and then calls\r\nNtSetInformationSymbolicLink on a newly created symbolic link to break out of the container. More specifically,\r\nit links its local containerized X drive to the host’s C drive.\r\nChoosing the Cluster\r\nAfter Siloscape creates a link to the host, it will search for two specific files: kubectl.exe and the Kubernetes\r\nconfig file, which normally exists on Kubernetes nodes.\r\nFigure 5. Siloscape searches for the kubectl.exe binary.\r\nSiloscape searches for kubectl.exe by name and the config file using a regular expression. The search function\r\ntakes an extra argument: a pointer to a vector that holds folder names to exclude from the search.\r\nFigure 6. Siloscape searches for the config file by regular expression.\r\nWhen it calls FindFile to search for the above files, it excludes the folders Program Files, Program Files (x86),\r\nWindows and Users. It does this to make the search faster and because it is unlikely the previously mentioned files\r\nare in those folders. If both files are found, their paths are saved to a global variable. If the files are not located,\r\nSiloscape exits, abandoning the attack.\r\nAfter Siloscape finds everything it needs to execute kubectl commands, it continues to check if the compromised\r\nnode actually has enough permissions to use for the attacker’s malicious activities. It does this by executing the\r\nkubectl command %ls auth can-i create deployments --kubeconfig=%ls where the strings in the format are\r\nreplaced by the paths it saved earlier as global variables.\r\nConnecting to the C2 and Supported Commands\r\nAfter getting everything it needs and checking that the compromised node is indeed capable of creating new\r\ndeployments, Siloscape writes the Tor archive (ZIP) and an unzip binary to the host’s C drive. After extracting Tor,\r\nit launches tor.exe to a new thread and waits for it to finish by checking the Tor thread output.\r\nAfter Tor is up and running, Siloscape uses it to connect to its C2 – an IRC server, using an onion address that was\r\nprovided as a command line argument.\r\nhttps://unit42.paloaltonetworks.com/siloscape/\r\nPage 7 of 12\n\nThe server is password-protected. Siloscape uses its first command line argument to decrypt the password by a\r\nsimple byte by byte XOR. The following is a simplified version of the C2 server’s password decryption:\r\nchar hardCodedXor[32] = \"HARD_CODED_32_LONG_STRING\";\r\nchar ircPass[32] = { 0 };\r\nfor (int i = 0; i \u003c 32; i++)\r\n     ircPass[i] = hardCodedXor[i] ^ argv[1][i];\r\nOnce successfully connected to the IRC server, it issues a JOIN #WindowsKubernetes command to join the\r\nWindowsKubernetes IRC channel and then idles there.\r\nSiloscape allows two types of instructions, one for kubectl supported commands and one for regular Windows\r\ncmd commands.\r\nFigure 7. Siloscape comparing the sender’s username to admin.\r\nIt waits for a private message. If one from a user named admin is received, Siloscape follows the following logic:\r\nIf the message starts with a K, it executes a kubectl command to the cluster using the paths it found earlier\r\nby running the command %ls %s --kubeconfig=%ls where:\r\nThe first parameter is the global variable of the kubectl’s path.\r\nThe second parameter is the message from the admin minus the first character.\r\nThe third parameter is the global variable of the config’s path.\r\nIf the message starts with a C, it simply runs the command minus the first character as a regular Windows\r\ncmd command.\r\nCommand and Control\r\nhttps://unit42.paloaltonetworks.com/siloscape/\r\nPage 8 of 12\n\nAfter I reversed the malware, especially the part that handles the C2, I wanted to discover whether this campaign\r\nwas still up and running.\r\nI set up a brand new virtual machine, downloaded Tor and started looking for an IRC client that supports\r\nSOCKS5, the proxy protocol that is needed in order to connect through Tor. IRC is a very old protocol and is less\r\npopular today than it was 20 years ago. Furthermore, IRC came out almost a decade before SOCKS5. I found\r\nHexChat, a simple, lightweight IRC client that supports both SOCKS5 and connecting to onion domains.\r\nWhen our Silospace sample was originally executed, its command line argument for the IRC username was\r\nphp_35, so I decided to use this username when connecting to the C2 server from HexChat, thinking it would\r\nappear legitimate to the attacker.\r\nFigure 8. #WindowsKubernetes channel active victims.\r\nI connected to the server and discovered it was still working. I joined #WindowsKubernetes just like Siloscape\r\ndoes. There were 23 active victims there and a channel operator named admin.\r\nhttps://unit42.paloaltonetworks.com/siloscape/\r\nPage 9 of 12\n\nFigure 9. C2 server shutting down.\r\nUnfortunately, after about two minutes, I was noticed and kicked out of the server. Two minutes after that, the\r\nserver was no longer active – at least not at the original onion domain I used.\r\nWhat Can We Learn?\r\nWhen I went over my findings, the first thing that came to mind is that there were many more active users on the\r\nC2 server than I actually saw in the #WindowsKubernetes channel – 313 users in total, to be exact. This implies\r\nthat the Siloscape malware was just a small part of a bigger campaign.\r\nSadly, when I connected to the server, the channels list was empty, indicating that the server was configured to not\r\nreveal its channels. Therefore, I couldn’t get more information from the channel names.\r\nThe second and more important detail that stood out was the convention used for the victims’ names. Our name\r\nwas php_35, and when our sample of Siloscape first executed, it indeed was executed through a vulnerable php\r\ninstance. The other names clearly suggest the way the attacker managed to achieve code execution (sqlinj\r\nprobably means SQL injection):\r\n@admin sqlinj_64 sqlinj_51 php_34 weblogic_12 sqlinj_138 weblogic_19 php_66 sqlinj_87 sqlinj_8 sqlinj_33\r\nsqlinj_114 activemq_5 sqlinj_44 tomcat_9 sqlinj_52 sqlinj_107 redis_10 php_76 sqlinj_28 activemq_25 sqlinj_35\r\nphp_8 weblogic_31 php_35\r\nThe last piece of information I was able to obtain from the C2 is the creation date of the server: Jan. 12, 2020.\r\nNote that this doesn’t necessarily mean that Siloscape was created on that date. Instead, it’s likely the campaign\r\nstarted at that time.\r\nConclusion\r\nUnlike most cloud malware, which mostly focuses on resource hijacking and denial of service (DoS), Siloscape\r\ndoesn’t limit itself to any specific goal. Instead, it opens a backdoor to all kinds of malicious activities.\r\nAs discussed in my last article, users should follow Microsoft’s guidance recommending not to use Windows\r\ncontainers as a security feature. Microsoft recommends using strictly Hyper-V containers for anything that relies\r\non containerization as a security boundary. Any process running in Windows Server containers should be assumed\r\nto have the same privileges as admin on the host, which in this case is the Kubernetes node. If you are running\r\napplications in Windows Server containers that need to be secured, we recommend moving these applications to\r\nHyper-V containers.\r\nFurthermore, administrators should make sure their Kubernetes cluster is securely configured. In particular, a\r\nsecured Kubernetes cluster won’t be as vulnerable to this specific malware as the nodes’ privileges won’t suffice\r\nto create new deployments. In this case, Siloscape will exit.\r\nSiloscape shows us the importance of container security, as the malware wouldn’t be able to cause any significant\r\ndamage if not for the container escape. It is critical that organizations keep a well-configured and secured cloud\r\nenvironment to protect against such threats.\r\nhttps://unit42.paloaltonetworks.com/siloscape/\r\nPage 10 of 12\n\nExisting Prisma Cloud capabilities will successfully detect and mitigate the Siloscape malware.\r\nFigure 10. Choosing action for unexpected processes on Prisma Cloud.\r\nPrisma Cloud’s Runtime Protection feature learns the machine’s behavior and creates a set of rules for processes.\r\nOnce the learning is complete, the user can choose the action for new, unexpected processes attempting to execute.\r\nThe user can choose to alert, prevent or completely block the execution.\r\nhttps://unit42.paloaltonetworks.com/siloscape/\r\nPage 11 of 12\n\nFigure 11. Siloscape blocked by Prisma Cloud\r\nIndicators of Compromise\r\nDescription SHA256\r\nOur Siloscape\r\nvariant\r\n5B7A23676EE1953247A0364AC431B193E32C952CF17B205D36F800C270753FCB\r\nunzip.exe, the\r\nunzip binary\r\nSiloscape writes\r\nto the disk\r\n81046F943D26501561612A629D8BE95AF254BC161011BA8A62D25C34C16D6D2A\r\ntor.zip, the tor\r\narchive\r\nSilsocape writes\r\nto the disk\r\n010859BA20684AEABA986928A28E1AF219BAEBBF51B273FF47CB382987373DB7\r\nSource: https://unit42.paloaltonetworks.com/siloscape/\r\nhttps://unit42.paloaltonetworks.com/siloscape/\r\nPage 12 of 12",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://unit42.paloaltonetworks.com/siloscape/"
	],
	"report_names": [
		"siloscape"
	],
	"threat_actors": [
		{
			"id": "d90307b6-14a9-4d0b-9156-89e453d6eb13",
			"created_at": "2022-10-25T16:07:23.773944Z",
			"updated_at": "2026-04-10T02:00:04.746188Z",
			"deleted_at": null,
			"main_name": "Lead",
			"aliases": [
				"Casper",
				"TG-3279"
			],
			"source_name": "ETDA:Lead",
			"tools": [
				"Agentemis",
				"BleDoor",
				"Cobalt Strike",
				"CobaltStrike",
				"RbDoor",
				"RibDoor",
				"Winnti",
				"cobeacon"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434939,
	"ts_updated_at": 1775791432,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/0e86d45069a56d03da300800a2df64942fd9d039.pdf",
		"text": "https://archive.orkl.eu/0e86d45069a56d03da300800a2df64942fd9d039.txt",
		"img": "https://archive.orkl.eu/0e86d45069a56d03da300800a2df64942fd9d039.jpg"
	}
}