{
	"id": "b0921701-e7db-4cc5-9c6e-5766c55c019b",
	"created_at": "2026-04-06T00:08:26.807939Z",
	"updated_at": "2026-04-10T13:12:54.343787Z",
	"deleted_at": null,
	"sha1_hash": "5b518975ac60eba5e9c4b18c5a7d076bee0c3595",
	"title": "Threat Alert: Attackers Building Malicious Images Directly on Your Host",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 385679,
	"plain_text": "Threat Alert: Attackers Building Malicious Images Directly on\r\nYour Host\r\nBy Assaf Morag\r\nPublished: 2020-07-15 · Archived: 2026-04-05 19:05:19 UTC\r\nWe at Team Nautilus – Aqua’s cyber security research team – discovered a new type of attack against container\r\ninfrastructure. The attacker exploits a misconfigured Docker API port in order to build and run a malicious\r\ncontainer image on the host. As far as we know, this is the first time that an attack in which the attacker builds an\r\nimage rather than pulling it from a public registry is observed in the wild.\r\nIn previously observed attack scenarios, the attackers usually try to hijack resources from the host by running a\r\ncryptocurrency miner, launch a network denial-of-service attack against other hosts, or worse, escaping from the\r\ncontainer and expanding onto the host’s network. A defender, on the other hand, can scan the images and react\r\nbased on the results, or restrict communication with a suspicious source or registry. In this case, the attacker did\r\nnot pull an image from a remote source but built it directly on the targeted host in order to bypass these defense\r\nmechanisms. Additionally, the attacker can thus increase the persistency of his infrastructure by building it directly\r\non the host. Since the image is not stored anywhere, no one will take it down. In addition, the name of the image\r\nand possibly its ID are randomly generated and probably unique to each host. This makes it hard for defenders to\r\nadd the image to a restricted list. Therefore, in this case, having preliminary intelligence on a malicious image or\r\nsource would be ineffectual. Using a Dynamic Threat Analysis (DTA) scanner that looks for behavior patterns,\r\nhowever, can help the defenders to detect these kinds of attacks. Moreover, this technique emphasizes the\r\nimportance of an ongoing dynamic scanning cadence in cloud-native environments.\r\nThe Observed Attack in Detail\r\nNormally, attacks against misconfigured Docker API are initiated by pulling an image from a public registry (i.e.\r\nDocker Hub) and spinning up the container on the targeted host environment. The image is usually one of 3\r\ncategories:\r\n1. A dedicated image built by a 3rd party – this image is designed for a specific purpose. For example\r\nxmrig/xmrig:latest or douglasslow/slowhttptest:latest , which are designed to mine cryptocurrency\r\nor conduct Denial of Service tests in the application layer. Attackers then nefariously use these images to\r\nhijack resources on the host or to launch a Network Denial of Service against a 3rd party target from the\r\ntargeted host.\r\n2. A dedicated image built by the attacker – usually the attacker hides the main purpose of the image by\r\nusing various techniques to conceal the malicious elements, or alternatively the attacker is doesn’t hide the\r\nmain purpose but designs the attack according to his needs.\r\n3. A vanilla image – the attacker uses a legitimate vanilla image, such as Alpine or Ubuntu and downloads\r\nthe malicious elements during runtime.\r\nhttps://blog.aquasec.com/malicious-container-image-docker-container-host\r\nPage 1 of 4\n\nIn this case, however, the adversary used a Docker SDK for Python package to send commands to a\r\nmisconfigured Docker API. The attack sequence is as described below:\r\n1. Sending a ping GET request to the Docker server in order to check if the API server is indeed exposed.\r\n2. Sending a GET request to receive the list of containers that are running on the host.\r\n3. Sending a POST request with a Docker Build command in order to build an image on the targeted host-Image\": \"zbrtgwlxz:latest . The Dockerfile contains the following commands:\r\nPulling a lightweight alpine image.\r\nA WGET command aimed to download the script main.sh from a remote source\r\n( http[:]//185[.]10[.]68[.]147/dock/main[.]sh ).\r\n4. Sending a GET request to verify that the image was successfully built on the targeted host.\r\n5. Sending a POST request to create a container based on the new image that the attacker just built.\r\n6. Sending a GET request to receive the list of containers that are running on the host.\r\n7. Sending a POST request to run the container.\r\nThe container is initiated with a command aimed to run a shell script, which was downloaded from a remote\r\nsource during the build: /bin/sh -c ash /main.sh\r\nThe Shell script main.sh was designed to download and run an ELF file named XMRIG.\r\nhttps://blog.aquasec.com/malicious-container-image-docker-container-host\r\nPage 2 of 4\n\nThis file is classified as malicious by Virus Total and is designed to hijack resources from the host by mining\r\ncryptocurrency.\r\nSummary\r\nIn this blog we reported about an adversary who used a new technique to attack a misconfigured Docker API. The\r\nimage was built directly on the target host and executed a resource-hijacking attack by using a cryptominer. This is\r\nyet another step in the super-fast evolution of attacks against cloud-native environments in just the past couple of\r\nhttps://blog.aquasec.com/malicious-container-image-docker-container-host\r\nPage 3 of 4\n\nyears. These new and daring attacks emphasize the importance of putting better and stronger solutions in the\r\ndefenders’ toolbox.\r\nIn this case, preliminary threat intel on a malicious container image is useless because the image is not pulled\r\nfrom a remote source. A static scanner will not return the desired results, since the image is built upon a standard\r\nAlpine base image and would most probably be marked as benign. A network-level detection/prevention security\r\nscanning might actually block the communication with the C2 of the attacker ( 185[.]10[.]68[.]147 ) and\r\nprevent downloading the script main.sh and the malicious binary.\r\nWe believe that the best solution for these kinds of threats lies in an on-going Dynamic Threat Analysis scanning\r\ncadence. Dynamically scanning all your images in Docker Hub and on the organization’s servers would shine a\r\nbright light on any hidden threats lurking in the cloud.\r\nAssaf is the Director of Threat Intelligence at Aqua Nautilus. He is responsible of acquiring threat intelligence\r\nrelated to software development life cycle in cloud native environments, supports the team's data needs, and helps\r\nAqua and the ecosystem remain at the forefront of emerging threats and protective methodologies. His research\r\nhas been featured in leading information security publications and journals worldwide, and he has presented at\r\nleading cybersecurity conferences. Notably, Assaf has also contributed to the development of the new MITRE\r\nATT\u0026CK Container Framework.\r\nAssaf is leading an O’Reilly course, focusing on cyber threat intelligence in cloud-native environments. The\r\ncourse covers both theoretical concepts and practical applications, providing valuable insights into the unique\r\nchallenges and strategies associated with securing cloud-native infrastructures.\r\nSource: https://blog.aquasec.com/malicious-container-image-docker-container-host\r\nhttps://blog.aquasec.com/malicious-container-image-docker-container-host\r\nPage 4 of 4",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://blog.aquasec.com/malicious-container-image-docker-container-host"
	],
	"report_names": [
		"malicious-container-image-docker-container-host"
	],
	"threat_actors": [],
	"ts_created_at": 1775434106,
	"ts_updated_at": 1775826774,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/5b518975ac60eba5e9c4b18c5a7d076bee0c3595.pdf",
		"text": "https://archive.orkl.eu/5b518975ac60eba5e9c4b18c5a7d076bee0c3595.txt",
		"img": "https://archive.orkl.eu/5b518975ac60eba5e9c4b18c5a7d076bee0c3595.jpg"
	}
}