Protecting Containers Against ‘Doki’ Malware
Security researchers at Intezer recently alerted the enterprise security community about Doki, a new and substantial malware targeting public Docker environments.
Downloaded and installed via a Linux backdoor, Doki uses Dyn’s DynDNS service and a unique Domain Generation Algorithm (DGA) based on the Dogecoin cryptocurrency blockchain to locate its controller in real-time. By querying the Dogecoin API and leveraging the SHA265 encryption technology behind the canine-branded cryptocurrency, Doki dynamically produces a full URL address at runtime to sidestep traditional network security checks that are based on URL/IP blacklists. In fact, of the 60 malware detection engines included in VirusTotal, none were able to detect Doki before the release of Intezer’s finding.
To any of us in the container security space, Doki’s success comes as no surprise. Containers and their infrastructures still represent a particularly new and fast-evolving kind of attack surface—and, unfortunately, one for which traditional signature-based anti-malware solutions offer little protection.
That said, good security hygiene and protections designed specifically for container environments can defeat Doki. Let’s take a look at the anatomy of a Doki attack and its prevention.
Step 1: Doki kicks off its attack by scanning a network for a misconfigured Docker API port.
Network operators can eliminate this risk when Doki is still harmless by regularly utilizing the CIS Benchmark for Docker to discover and fix misconfigured Docker Daemons. Additionally, public cloud provider security rules (AWS Security Groups is an example) ought to be configured to allow trusted connections only, blocking all unauthorized ingresses.
Step 2: After finding a Docker port to exploit, the attacker calls the Docker API to trigger a download and launch a clean container. Vulnerability scanning engines will find no issues with this. It’s a stepping stone before escalating the attack.
However, a container security firewall will capably block any network and process activity in unauthorized containers that start running. Any attempted activities by this rogue container will also trigger alerts.
Step 3: Attackers will use the container they control to quickly create more containers and trigger whatever malicious behavior they have in mind.
The right runtime container security policy will be able to actively (and immediately) detect and block any unauthorized processes, file access or network connections. These policies can be automatically deployed through security-as-code.
Step 4: Doki sets up a command-and-control link, using the ngrok service for secure tunneling. Very short-lived unique URLs enable attackers to quickly download payloads into the container’s filesystem. By running and quitting, the container avoids timely detection by traditional firewalls or SIEM systems. By the time logs are collected and alerts arrive, the container is gone without a trace, leaving no clues to investigate.
A container firewall capable of layer 7 inspection can detect ngrok botnet connections. Deep packet inspection and in-line blocking can overcome the threat of brief malicious connections, with no interruptions to normal containers and network traffic.
Step 5: The attack container accesses the host system by binding the host root file system. It then modifies the cron utility and gains host execution capabilities. Typical to container threats, once a privileged container is controlled the malicious application will attempt to escape to the host.
A container security strategy must enable the detection of any privilege escalations and container escapes, blocking all suspicious and unauthorized processes.
Step 6: The attack creates a host cron job that downloads a malicious payload each minute, containing a network scanner and a downloader script. Dropping in those files gives the attacker control over a worker node (and the container environment).
Container security must monitor process and file system behavior in real-time to detect and block these malicious behaviors. Container security should also provide real-time alerting to DevOps/DevSecOps teams.
Step 7: The network scanner searches for another victim using a list of public cloud IP ranges. Using scanning tools such as zmap, zgrap, jq.e and others, it also scans the local network for ports associated with Redis, Docker, SSH and HTTP. When it finds an available target, Doki uploads to a new ngrok URL to continue its spread.
Container security should immediately aim to detect port scanners and other unauthorized processes at their source container, or on the host. A good security implementation will be able to lock down the host to block all malicious processes.
Step 8: The downloader script downloads and installs binaries. This Doki malware can run as a container or on the host and scales up quickly.
A layer 7 container firewall can inspect egress network communications and safeguard container creation. Production container environments must be locked down to prevent both unauthorized containers and unauthorized behaviors by running containers.
Step 9: Doki queries the Dogecoin API, uses SHA265 encryption and dynamically creates a URL address at runtime. This bypasses traditional network security checks such as blacklist URL/IP lists.
While typical layer 3 and layer 4 firewalls cannot inspect encrypted traffic, container security solutions can solve this issue by blocking malicious URLs and network connections.
Stopping Doki
Modern container and cloud infrastructures require equally modern security strategies to detect and block dynamic connections, unauthorized process/file activity and privilege escalations. The Doki malware is decentralized and immutable, needing as little as a few minutes to infect and begin scaling an attack. In production environments, runtime container and host security enforcement is the most essential defense for stopping Doki (and similar attacks that have and will come) before they can wreak havoc.