{ "id": "a65f8fc6-3e0e-4b62-ac13-973db67a092c", "created_at": "2026-04-06T15:52:11.294325Z", "updated_at": "2026-04-10T13:12:10.041073Z", "deleted_at": null, "sha1_hash": "697855d530f01eeec297054f26861ab4f879f765", "title": "Watch Your Containers: Doki Infecting Docker Servers in the Cloud", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 449982, "plain_text": "Watch Your Containers: Doki Infecting Docker Servers in the\r\nCloud\r\nBy Nicole Fishbein\r\nPublished: 2020-07-28 · Archived: 2026-04-06 15:47:06 UTC\r\nKey Findings\r\nNgrok Mining Botnet is an active campaign targeting exposed Docker servers in AWS, Azure, and\r\nother cloud platforms. It has been active for at least two years.\r\nWe have detected a recent attack which includes a completely undetected Linux malware and a\r\npreviously undocumented technique, using a blockchain wallet for generating C\u0026C domain names.\r\nAnyone with publicly open Docker API access is at high risk to be hacked within the span of just a\r\nfew hours. This is probable due to the hackers’ automated and continuous internet-wide scanning for\r\nvulnerable victims.\r\nThe new malware, dubbed “Doki”, hasn’t been detected by any of the 60 malware detection engines\r\nin VirusTotal since it was first analyzed on January 14, 2020.\r\nThe attacker is using the infected victims to search for additional vulnerable cloud servers.\r\nIntroduction\r\nLinux threats are becoming more common. A contributing factor to this is the increasing shift and reliance on\r\ncloud environments, which are mostly based on Linux infrastructure. Hence, attackers have been adapting\r\naccordingly with new tools and techniques designed specifically for this infrastructure.\r\nA technique that has become popular is the abuse of misconfigured Docker API ports, where attackers scan for\r\npublicly accessible Docker servers and exploit them in order to set up their own containers and execute malware\r\non the victim’s infrastructure.\r\nOne of the longest ongoing attack campaigns exploiting Docker API ports is the Ngrok Botnet, previously\r\nreported on by researchers at Netlab and Trend Micro. As part of the attack, the attackers abuse Docker\r\nconfiguration features in order to elude standard container restrictions and execute various malicious payloads\r\nfrom the host. They also deploy a network scanner and use it to scan the cloud providers’ IP ranges for additional\r\npotentially vulnerable targets. Our evidence shows that it takes only a few hours from when a new misconfigured\r\nDocker server is up online to become infected by this campaign.\r\nRecently, we have detected a new malware payload that is different from the standard cryptominers typically\r\ndeployed in this attack. The malware is a fully undetected backdoor which we have named Doki.\r\nhttps://www.intezer.com/blog/cloud-security/watch-your-containers-doki-infecting-docker-servers-in-the-cloud/\r\nPage 1 of 8\n\nDoki uses a previously undocumented method to contact its operator by abusing the Dogecoin cryptocurrency\r\nblockchain in a unique way in order to dynamically generate its C2 domain address. The malware has managed to\r\nstay under the radar for over six months despite samples being publicly available in VirusTotal.\r\nIn this article we will cover the attack and provide a detailed analysis of the techniques that were implemented by\r\nthe undetected Doki backdoor.\r\nThe Attack\r\nThe threat is targeting misconfigured containerized environments in the cloud. The attackers scan for publicly\r\naccessible Docker API ports and exploit them in order to set up their own containers and execute malware on the\r\nvictims’ infrastructure. The attackers are spawning and deleting a number of containers during this attack.\r\nEach container that is created during the attack is based on an alpine image with curl installed. The image is\r\navailable on the Docker hub. The image is not malicious but rather it’s being abused to carry out malicious\r\nactivities. By using an image that contains the curl software, curl commands are executed as soon as the container\r\nis up and running.\r\nThe advantage of using a publicly available image is the attacker doesn’t need to hide it on Docker hub or other\r\nhosting solutions. Instead, the attackers can use an existing image and run their own logic and malware on top of\r\nit.\r\nAs mentioned above, attackers can create any container, however, to execute code from the hosting machine they\r\nmust use a container escape method. The technique is based on the creation of a new container, accomplished by\r\nposting a ‘create’ API request. The body of the request contains configuration parameters for the container. One of\r\nthe parameters is bind which lets the user configure which file or directory on the host machine to mount into a\r\ncontainer.\r\nContainers that are created during the attack are configured to bind /tmpXXXXXX directory to the root directory\r\nof the hosting server. This means every file on the server’s filesystem can be accessed and even modified, with the\r\ncorrect user permissions, from within the container.\r\nNgrok is a service which provides secure tunnels to connect between local servers and the public internet. The\r\nattacker abuses Ngrok to craft unique URLs with a short lifetime and uses them to download payloads during the\r\nattack by passing them to the curl based image. The downloaded payload is saved in /tmpXXXXXX directory in\r\nthe container.\r\nThe command that created the container as seen on the syslog of the attacked server\r\nhttps://www.intezer.com/blog/cloud-security/watch-your-containers-doki-infecting-docker-servers-in-the-cloud/\r\nPage 2 of 8\n\nBy using the bind configuration the attacker can control the cron utility of the host.\r\nThe attacker modifies the host’s cron to execute the downloaded payload every minute. We observed two types of\r\npayloads, one is a network scanner script and the other is a downloader script.\r\nThe network scanner uses zmap, zgrap, and jq to scan ports associated with Redis, Docker, SSH, and HTTP.\r\nUsing a list of hardcoded ranges of IP addresses, which belong mostly to cloud servers such as AWS and local\r\ncloud providers in foreign regions (we have seen providers from China, Austria, and the United Kingdom), the\r\nscript gathers the information and uploads it to another Ngrok URL.\r\nThe downloader script is responsible for downloading and installing various malware binaries, often one of\r\nseveral well known cryptominers. We have noticed it can also install a fully undetected malware component. We\r\nnamed this malware Doki and will provide a technical analysis in the next section.\r\nThe attacker has full control over the configuration of the container he creates and the files that are dropped into\r\nthe container. By using legitimate API commands, the attacker is able to escape from the container he created and\r\nexecute any code from within the server itself.\r\nThe Doki Malware\r\nDoki is a backdoor for Linux which function is to execute code received from its operators. The malware utilizes\r\nthe DynDNS service and a unique Domain Generation Algorithm (DGA) based on the Dogecoin cryptocurrency\r\nhttps://www.intezer.com/blog/cloud-security/watch-your-containers-doki-infecting-docker-servers-in-the-cloud/\r\nPage 3 of 8\n\nblockchain in order to find the domain of its C2 in real time.\r\nThe malware is a fully undetected backdoor. It has managed to stay undetected for over six months despite having\r\nbeen uploaded to VirusTotal on January 14, 2020 and scanned multiple times since.\r\nDoki is multi-threaded and uses the embedTLS library for cryptographic functions and network communication.\r\nWhen executed, the malware will create a seperate thread in order to handle all C2 communications.\r\nThe malware starts by generating a C2 domain using its unique DGA. In order to construct the C2 address the\r\nmalware performs the following steps:\r\n1. Query dogechain.info API, a Dogecoin cryptocurrency block explorer, for the value that was sent out\r\n(spent) from a hardcoded wallet address that is controlled by the attacker. The query format is:\r\nhttps://dogechain.info/api/v1/address/sent/{address}\r\n2. Perform SHA256 on the value returned under “sent”\r\n3. Save the first 12 characters from the hex-string representation of the SHA256 value, to be used as the\r\nsubdomain.\r\n4. Construct the full address by appending the subdomain to ddns.net. An example domain would be:\r\n6d77335c4f23[.]ddns[.]net\r\nUsing this technique the attacker controls which address the malware will contact by transferring a specific\r\namount of Dogecoin from his or her wallet. Since only the attacker has control over the wallet, only he can control\r\nwhen and how much dogecoin to transfer, and thus switch the domain accordingly. Additionally, since the\r\nblockchain is both immutable and decentralized, this novel method can prove to be quite resilient to both\r\ninfrastructure takedowns from law enforcement and domain filtering attempts from security products.\r\nhttps://www.intezer.com/blog/cloud-security/watch-your-containers-doki-infecting-docker-servers-in-the-cloud/\r\nPage 4 of 8\n\nIt’s worth noting that once the domain is generated, the malware ensures it’s not “46927e019820”, which is what’s\r\ngenerated for “0.000000”, meaning when no Dogecoin was ever transferred from the wallet. In the case that this\r\ndomain is generated, the malware will exit without continuing any further.\r\nOtherwise, the malware continues to download a shell script by contacting its C2 via HTTPS, using the URL\r\n\u003cc2_address\u003e/update.sh and saving the returned data as /tmp/update.sh. \r\nhttps://www.intezer.com/blog/cloud-security/watch-your-containers-doki-infecting-docker-servers-in-the-cloud/\r\nPage 5 of 8\n\nIt will then resolve the current process’s PID and path to be used as script arguments, and proceeds to execute the\r\nscript by running: /bin/sh -c ./update.sh \u003cprocess_id\u003e \r\n\u003cprocess_path\u003e \r\nMeanwhile, the main thread of the malware reads from STDIN, expecting to receive binary data from that shell\r\nscript. The arguments are passed to the script in order to allow it to communicate with the malware in this way and\r\nreceive code to execute.\r\nIf data is received via STDIN, the malware saves it as a file under /tmp, choosing its name randomly from a\r\npredefined list of Linux kernel modules.\r\nhttps://www.intezer.com/blog/cloud-security/watch-your-containers-doki-infecting-docker-servers-in-the-cloud/\r\nPage 6 of 8\n\nWhile it’s a very basic deception method, it’s not something commonly seen in Linux malware, which often don’t\r\nbother disguising as system files.\r\nFinally, the malware proceeds to fork so the child process executes the file and the main process loops to repeat\r\nthe malware’s logic flow.\r\nBottom Line\r\nThe Ngrok Botnet campaign has been ongoing for over two years and is rather effective, infecting any\r\nmisconfigured Docker API server in a matter of hours. The incorporation of the unique and undetected Doki\r\nmalware indicates the operation is continuing to evolve.\r\nThis attack is very dangerous due to the fact the attacker uses container escape techniques to gain full control of\r\nthe victim’s infrastructure. Our evidence shows that it takes only a few hours from when a new misconfigured\r\nDocker server is up online to become infected by this campaign.\r\nImmediate Action Required by Container Server Owners\r\nBoth companies and individuals who own container servers in the cloud must immediately fix configuration to\r\nprevent exposure. This includes: Checking for any exposed ports, verifying there are no foregin or unknown\r\ncontainers among the existing containers, and monitoring excessive use of resources.\r\nWe recommend you read our article, Best Practices for Securing a Docker Runtime Environment. You can also run\r\nour YARA rule on your cloud servers to check if you have been infected by this campaign.\r\nDetected by Intezer Protect\r\nhttps://www.intezer.com/blog/cloud-security/watch-your-containers-doki-infecting-docker-servers-in-the-cloud/\r\nPage 7 of 8\n\nWe detected this threat using our Cloud Workload Protection Platform (CWPP) Intezer Protect. Installed on a\r\nLinux machine, Intezer Protect recognized unknown code executed in the memory of the server. After performing\r\na genetic analysis, the platform concluded the code has never before been seen in the wild, which means it’s\r\ncompletely new and therefore it’s likely the malware was written entirely from scratch. This is one reason why the\r\nindustry is adopting Zero Trust Execution to secure cloud workloads.\r\nIOCs\r\n4aadb47706f0fe1734ee514e79c93eed65e1a0a9f61b63f3e7b6367bd9a3e63b\r\n6d77335c4f23[.]ddns[.]net\r\n36b397f0da96fa0639a1e60f56af8be1a3060c4d1b98f108b7dc8e3c572b3337\r\n9907eaa1b487306c43b1352369f0409ba59a9aa0f5590fbd60e8825999db1f14\r\nSource: https://www.intezer.com/blog/cloud-security/watch-your-containers-doki-infecting-docker-servers-in-the-cloud/\r\nhttps://www.intezer.com/blog/cloud-security/watch-your-containers-doki-infecting-docker-servers-in-the-cloud/\r\nPage 8 of 8", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "origins": [ "web" ], "references": [ "https://www.intezer.com/blog/cloud-security/watch-your-containers-doki-infecting-docker-servers-in-the-cloud/" ], "report_names": [ "watch-your-containers-doki-infecting-docker-servers-in-the-cloud" ], "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": 1775490731, "ts_updated_at": 1775826730, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/697855d530f01eeec297054f26861ab4f879f765.pdf", "text": "https://archive.orkl.eu/697855d530f01eeec297054f26861ab4f879f765.txt", "img": "https://archive.orkl.eu/697855d530f01eeec297054f26861ab4f879f765.jpg" } }