{
	"id": "468933b1-2dfb-426e-a94d-7b34afa56807",
	"created_at": "2026-04-06T02:12:14.512138Z",
	"updated_at": "2026-04-10T03:24:17.886386Z",
	"deleted_at": null,
	"sha1_hash": "2c020df4c788292e12938efd880cf53c867055e8",
	"title": "Attacker’s Tactics and Techniques in Unsecured Docker Daemons Revealed",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1031477,
	"plain_text": "Attacker’s Tactics and Techniques in Unsecured Docker Daemons\r\nRevealed\r\nBy Jay Chen\r\nPublished: 2020-01-29 · Archived: 2026-04-06 02:00:47 UTC\r\nExecutive Summary\r\nBetween September and December 2019, Unit 42 researchers periodically scanned and collected metadata from Docker\r\nhosts exposed to the internet (largely due to inadvertent user errors) and this research reveals some of the tactics and\r\ntechniques used by attackers in the compromised Docker engines. In total, 1,400 unsecured Docker hosts, 8,673 active\r\ncontainers, and 17,927 Docker images were discovered in our research. The Docker team worked quickly in tandem with\r\nUnit 42 to remove the malicious images once our team alerted them to this operation.\r\nContainer technology has gained enormous popularity in the past few years and is becoming the de facto way for packaging,\r\ndelivering, and deploying modern applications. While the technology is quickly evolving and being adopted, it also becomes\r\na valuable target for adversaries.\r\nWhile the majority of the malicious activities involved cryptojacking (mostly mining for Monero), some compromised\r\nDocker engines were used for launching other attacks or installing rootkits on the hosts. Sensitive information, such as\r\napplication credentials and infrastructure configuration were also found from the exposed logs. One interesting tactic we\r\nfrequently saw was attackers mounted the entire host file system to a container and accessed the host operating system (OS)\r\nfrom the container to read/write from it.\r\nWe organized the observed malicious activities into the four categories below and provided an overview of each category\r\nwith real samples.\r\n1. Deploy Container Images with Malicious Code.\r\nMalicious images are first pushed to a public registry. The images are then pulled and deployed on the unsecured\r\nDocker hosts.\r\n2. Deploy Benign Container Images and Download Malicious Payloads at Run Time.\r\nBenign images are deployed on the Docker hosts. Malicious payloads are then downloaded and executed inside the\r\nbenign containers.\r\n3. Deploy Malicious Payloads on the Host.\r\nAdversaries mount the entire host file system to a container and access the host file system from the container.\r\n4. Obtain Sensitive Information from the Docker Log.\r\nAdversaries scrape the Docker logs to find sensitive information such as credentials and configurations.\r\nFigure 1. Four categories of the observed malicious activities\r\nDocker Daemon\r\nDocker daemon is a persistent background process that manages the containers on a single host. It is a self-sufficient runtime\r\nthat manages Docker objects such as images, containers, network, and storage. Docker daemon listens for REST API\r\nrequests and performs a series of container operations accordingly. Applications or users typically use Docker clients to\r\nauthenticate and interact with Docker daemons. A Docker daemon can also communicate with other Docker daemons if\r\nmultiple hosts are managed as a service or a cluster.\r\nBy default, Docker daemon creates a non-networked Unix domain socket at /var/run/docker.sock and only processes with\r\nroot permission or Docker group membership can access it. If a client needs to access a Docker daemon remotely, Docker\r\ndaemon can open a TCP socket and listens on port 2375 for REST API requests. The default TCP socket provides\r\nhttps://unit42.paloaltonetworks.com/attackers-tactics-and-techniques-in-unsecured-docker-daemons-revealed/\r\nPage 1 of 6\n\nunencrypted and unauthenticated access to the Docker daemon. Mutual authentication with TLS can also be configured to\r\nsecure the communication between the client and the remote daemon. Docker management tools such as Portainer,\r\nKitematic, and Rancher typically require users to enable the TCP socket so that a cluster of Docker hosts can be managed\r\nremotely. However, as TLS configuration can be complicated, users sometimes made mistakes and inadvertently exposed\r\nunauthenticated daemons to the entire internet.\r\nExplore the Exposed Docker Daemons\r\nDue to the complexity of setting up TLS, we found many misconfigured and unsecured Docker daemons on the internet.\r\nThere are Docker daemons that have no encryption or authentication. There are also Docker daemons with TLS configured,\r\nbut the daemons fail to verify the client certificates. Without verifying the client certificates, anyone can still establish an\r\nencrypted but unauthenticated connection to the daemon. Malicious actors who find these unsecured Docker daemons can\r\ngain full control of the Docker platform and perform actions such as deploying new containers, logging into any active\r\ncontainer, and downloading the container images. Since the Docker daemon runs as a root process on the host, attackers may\r\nalso gain full control of the host.\r\nTo understand the tactics and techniques that the malicious actors exploit on these unsecured Docker hosts, we periodically\r\nscanned for the exposed Docker daemons on the internet and collected their metadata between September and December\r\n2019. We are interested in seeing the malicious images, containers, and processes deployed on the compromised hosts.\r\nUsing the Internet of Things search engines Shodan and Censys, we found around 5,000 Docker daemons exposed to the\r\ninternet and 10-15% of these daemons can be accessed without authentication. Using the standard Docker Daemon APIs, we\r\ncollected metadata from the unsecured hosts by making a few read-only requests, as shown in Table 1.\r\nAPI Description\r\nGET /info Show system-wide information\r\nGET /containers/json List containers\r\nGET /images/json List Docker images\r\nGET /volumes List mounted/bind volumes\r\nGET /swarm Inspect the swarm configuration\r\nGET /events Get container events from Docker\r\nTable 1. Docker Daemon APIs used for collecting metadata.\r\nOverall, we identified more than 1,400 unique unsecured Docker hosts, 8,673 active containers, 17,927 Docker images, and\r\n15,229 volumes. Figure 2 shows the location distribution of the Docker daemons. Figure 3 shows their Docker versions and\r\nOS types. In the next section, we will summarize the malicious activities observed on these compromised Docker hosts.\r\nFigure 2. Location of the unsecured exposed Docker hosts\r\nhttps://unit42.paloaltonetworks.com/attackers-tactics-and-techniques-in-unsecured-docker-daemons-revealed/\r\nPage 2 of 6\n\nFigure 3. The versions (left) and the OS (right) of the unsecured Docker hosts\r\nMalicious Activities in the Exposed Docker Daemons\r\nOnce malicious actors discover an unsecured Docker daemon, they can gain full control of the Docker platform and\r\npotentially compromise the entire host. Our research shows that the majority of the compromised platforms were involved in\r\ncryptojacking (mostly mining for Monero), and some were also used as stepping stones for launching other attacks. We see\r\nadversaries compete for the “free resources” by eliminating each other from the systems, and some more aggressive\r\nadversaries further compromise the host and install malware directly on the host OS. The observed malicious activities are\r\norganized into four categories and are detailed in each subsection.\r\nDeploy Container Images with Malicious Code\r\nEach Docker image packages all the dependencies necessary for running the application. The application can thus run\r\nidentically on any platform, operating system, and infrastructure. Malicious applications can also be delivered the same way\r\nwith high reliability. Adversaries use public container registries such as Docker Hub and Quay to store and deliver malicious\r\ncontainer images. As Docker Hub is the default registry trusted by most Docker hosts, it is frequently used to store and serve\r\nmalicious images. These types of malware are pulled and run as containers directly on the compromised hosts. They\r\ntypically just steal the CPU, memory, or networking resources without harming other containers or processes on the same\r\nhost. Because the malicious code is built into the container images, composition analysis tools such as Prisma Cloud can\r\nusually identify the malicious files before the images get deployed. Our research found numerous images on Docker Hub\r\ncontaining malicious code, as shown in Table 2. Note that Docker Hub has deactivated these images after we reported them.\r\nRepository/Image Malicious content\r\nabailey000/debian\r\nxmrig monero miner.\r\nMining pool: mine.c3pool[.]comMining address:\r\n4453uAxM3ej4p4DWJBV8v1QpdA9vZB7j1cocTXcbjpoSaxXdBC5SxDrgxU6JmV8ePhL95kwHTtZwcP5zENXNSJwUH\r\nchallengerd/challengerd\r\nxmrig monero miner.\r\nMining pool: monerohash[.]comMining address:\r\n89mvBaUVy4r6A2rNBVdatMBaLP27zPYGyivmDbJFqFPvUxEwVB4v4V52wgnpH6BWvjHkyzZLMJso7YUgsNwY15\r\ntanchao2014/mytest\r\nxmrig monero miner.\r\nMining pool: pool.supportxmr[.]comMining address:\r\n45TwKEr1LjoEPuxnbfuPhaXCf138AoQvtSJ3jdqg1gPxNjkSNbQpzZrGDaFHGLrVT7AzM7tU9QY8NVdr4H1C3r2d3XN\r\nfreetouse3/accumulo\r\nxmrig monero miner.\r\nMing pool: xmr.f2pool[.]com\r\nMining address:\r\n43U3d1PBg4Gi2BaeMx7nH2dQsyZhAdMRATkJmbvr3kFuEMvU93f4H5geqjnru7SjLA3q81xCnUWr9PdFJRKDB5131f\r\nshaylsholmes/myubuntu\r\nxmrig monero miner.\r\nIt randomly checks IPs in IPv4 address space for possible exposed Docker hosts.Mining pool: pool.minexmr[.]comMining\r\n46H5FPmG5x8NCXTTLMWcTzezHR5CqkQeg41XnbfK1Ujh1sw4xx29WmM15rEVaXMrUWN8SutBnGe21XvWg3T6\r\npocosow/centos\r\nA cryptojacking malware with worm capability.\r\nThe image itself does not contain the cryotojacking code, but it deploys another two malicious containers with xmrig mone\r\nMining address:\r\n45TwKEr1LjoEPuxnbfuPhaXCf138AoQvtSJ3jdqg1gPxNjkSNbQpzZrGDaFHGLrVT7AzM7tU9QY8NVdr4H1C3r2d3XN\r\nThe detail is published in Unit 42 blog Graboid.\r\nheybb/theimg1\r\nThe container launches Slowloris DoS attack over the Tor network. It periodically pulls new payloads and targets from a co\r\ncontrol server on the tor network.\r\nhttps://unit42.paloaltonetworks.com/attackers-tactics-and-techniques-in-unsecured-docker-daemons-revealed/\r\nPage 3 of 6\n\nTable 2. Docker images with malicious code\r\nDeploy Benign Container Images and Download Malicious Payloads at Run Time\r\nContainers are designed to be self-sufficient, and once a container starts, its file system and active processes generally stay\r\nunchanged. However, if there are no security policies, such as AppArmor or SELinux, to restrict the file system access,\r\nadversaries can still install and execute malicious payloads inside containers at run time. While composition analysis tools\r\nare good at identifying malicious code in container images, they can’t see the malicious payloads installed at run time. An\r\nadversary can deploy a verified official image from Docker Hub and inject malicious processes into the container at a later\r\ntime. More advanced container runtime protection such as Prisma Cloud Compute are necessary to detect this type of attack.\r\nIn Figure 4, a malicious script was downloaded and executed in an official Ubuntu image. In Figure 5, two malicious scripts\r\nwere downloaded and run on the host file system through an official Alpine image. Figure 6 shows that a base64 encoded\r\nscript was added to the host’s crontab through an official Busybox image.\r\nFigure 4. Execute a malicious command in an official Ubuntu image\r\nFigure 5. Execute a malicious command in an official Alpine image\r\nFigure 6. Execute a malicious command in an official Busybox image\r\nDeploy Malicious Payloads on the Host\r\nUnsecured Docker daemons give malicious actors full access to all the containers and images, but the daemon doesn’t\r\ndirectly provide access to the host OS. An interesting trick we frequently saw is attackers mounted the entire host file system\r\nto a container and access the host OS from the container. When the entire host file system is mounted, almost all the files on\r\nthe host can be read/written from the container.\r\nIn Figure 7, an adversary created a container that mounted the entire host file system (/) to the container file system (/mnt).\r\nFigure 8 shows how the adversary executed a malicious payload against the host file system from the container. The chroot\r\ncommand changes the root directory of the calling process to /mnt, which points to the root of the host file system. After\r\nchroot is done, the malicious process virtually runs on the host file system.\r\nFigures 9-11 show other observed techniques used to compromise the host using the mounted file system. In Figure 9, the\r\nadversary created a malicious cron job on the host by sending a malicious payload to the host mount point (/mnt) in the\r\ncontainer. In Figure 10, the adversary added a new public key to the root’s home directory on the host. This key enables\r\ndirect ssh access to the host OS. In Figure 11, malicious code was downloaded and dropped to the host boot procedure\r\ndirectory rc3.d through the mount point.\r\nhttps://unit42.paloaltonetworks.com/attackers-tactics-and-techniques-in-unsecured-docker-daemons-revealed/\r\nPage 4 of 6\n\nFigure 7. Root of the host file system is mounted to a container\r\nFigure 8. Execute commands inside a container\r\nFigure 9. Execute commands inside a container\r\nFigure 10. Execute commands inside a container\r\nFigure 11. Execute commands inside a container\r\nObtain Sensitive Information from the Docker Log\r\nBy default, the Docker daemon maintains the event and log for every container from the time it is created to the time it is\r\nkilled. Logs are crucial for debugging and auditing, but sensitive information such as configurations and credentials may\r\nalso leak from the logs.\r\nIn Figure 12 and Figure 13, application passwords were revealed from the command logs. In Figure 14, the IP of the etcd\r\nserver and locations of key files were leaked from the command logs. These credentials facilitate lateral movements and\r\ncould quickly expand the scale of the compromise.\r\nFigure 12. Leaked redis credential from the container command\r\nFigure 13. Leaked portainer credential from the container command\r\nhttps://unit42.paloaltonetworks.com/attackers-tactics-and-techniques-in-unsecured-docker-daemons-revealed/\r\nPage 5 of 6\n\nFigure 14. Leaked key files from the container command\r\nThroughout the research, we observed a set of websites that were frequently used for delivering malicious payloads or\r\nreceiving exfiltrated data from the compromised hosts. Most of these domains allow users to upload and download files\r\nanonymously. Table 3 lists nine websites that we saw multiple times.\r\nWebsite Website Information\r\nbigbotpein[.]cf Users can upload and download files anonymously\r\nmediafire[.]com Users can upload and download files anonymously\r\ntransfer[.]sh Users can upload and download files anonymously\r\nix[.]io Users can use REST API to paste, view, and delete plain text files\r\ngyazo[.]nl Users can upload images or videos and receive a download link.\r\nonion[.]ly A Tor web proxy that allow users to access Tor services through regular browsers\r\nonion[.]ws A Tor web proxy that allow users to access Tor services through regular browsers\r\ntor2web[.]su A Tor web proxy that allow users to access Tor services through regular browsers\r\nngrok[.]io A service that exposes a local web server to the internet. C2 can be hidden behind the service\r\nTable 3. Websites commonly used as C2\r\nConclusion\r\nThis research provides the first, street-level view into the tactics and techniques attackers use when compromising container\r\nplatforms. We learned not only the malicious activities in the container platform but also the counter measurements\r\nnecessary to detect and prevent these activities. Since most of the vulnerabilities are caused by accidentally exposing an\r\nunsecured Docker daemon to the internet, some defense strategies to mitigate them include:\r\nAlways enforce mutual authentication when configuring TLS on Docker daemon socket\r\nUse Unix socket to communicate with Docker daemon locally or use SSH to connect to a remote Docker daemon\r\nOnly let an \"allow list\" of client IPs to access the Docker server\r\nEnable Content Trust in Docker so that only signed and verified images can be pulled\r\nScan every container image for vulnerabilities and malicious code.\r\nDeploy run time protection tools to monitor the running containers.\r\nPalo Alto Networks customers are protected in the following ways:\r\nPrisma Cloud vulnerability scanner can detect vulnerable/malicious codes and block them at build time.\r\nPrisma Cloud Compute continuously monitors containers and hosts at run time.\r\nSource: https://unit42.paloaltonetworks.com/attackers-tactics-and-techniques-in-unsecured-docker-daemons-revealed/\r\nhttps://unit42.paloaltonetworks.com/attackers-tactics-and-techniques-in-unsecured-docker-daemons-revealed/\r\nPage 6 of 6",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://unit42.paloaltonetworks.com/attackers-tactics-and-techniques-in-unsecured-docker-daemons-revealed/"
	],
	"report_names": [
		"attackers-tactics-and-techniques-in-unsecured-docker-daemons-revealed"
	],
	"threat_actors": [
		{
			"id": "eb3f4e4d-2573-494d-9739-1be5141cf7b2",
			"created_at": "2022-10-25T16:07:24.471018Z",
			"updated_at": "2026-04-10T02:00:05.002374Z",
			"deleted_at": null,
			"main_name": "Cron",
			"aliases": [],
			"source_name": "ETDA:Cron",
			"tools": [
				"Catelites",
				"Catelites Bot",
				"CronBot",
				"TinyZBot"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775441534,
	"ts_updated_at": 1775791457,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/2c020df4c788292e12938efd880cf53c867055e8.pdf",
		"text": "https://archive.orkl.eu/2c020df4c788292e12938efd880cf53c867055e8.txt",
		"img": "https://archive.orkl.eu/2c020df4c788292e12938efd880cf53c867055e8.jpg"
	}
}