Towards the end of 2017, there was a major shift in the malware scene. As cloud-based technologies became more popular, cybercrime gangs also began targeting Docker and Kubernetes systems.

SECURITY
Cyber security 101: Protect your privacy from hackers, spies, and the government
Cyber security 101: Protect your privacy from hackers, spies, and the government

Simple steps can make the difference between losing your online accounts or maintaining what is now a precious commodity: Your privacy.

Read More

Most of these attacks followed a very simple pattern where threat actors scanned for misconfigured systems that had admin interfaces exposed online in order to take over servers and deploy cryptocurrency-mining malware.

Over the past three years, these attacks have intensified, and new malware strains and threat actors targeting Docker (and Kubernetes) are now being discovered on a regular basis.

But despite the fact that malware attacks on Docker servers are now commonplace, many web developers and infrastructure engineers have not yet learned their lesson and are still misconfiguring Docker servers, leaving them exposed to attacks.

The most common of these mistakes is leaving Docker remote administration API endpoints exposed online without authentication.

Over the past years, malware like Doki, Ngrok, Kinsing (H2miner), XORDDOS, AESDDOS, Team TNT, Xanthe, and others, have scanned for Docker servers that left the Docker management API exposed online and then abused it to deploy malicious OS images to plant backdoors or install cryptocurrency miners.

The latest of these malware strains was discovered last week by Chinese security firm Qihoo 360. Named Blackrota, this is a backdoor trojan that is basically a simplified version of the CarbonStrike beacon implemented in the Go programming language.

Only a Linux version was discovered until now, and it is unclear how this malware is being used. Researchers don’t know if a Windows version also exists, if Blackrota is being used for cryptocurrency mining, or if it’s used for running a DDoS botnet on top of powerful cloud servers.

What is known is that Blackrota relies on developers who have made a mistake and accidentally misconfigured their Docker servers.

The lesson from Blackrota and past attacks is that Docker is not a fringe technology anymore. Threat actors are now targeting it on purpose with at-scale attacks on a near daily basis.

Companies, web developers, and engineers running Docker systems are advised to review the official Docker documentation to make sure they have secured Docker’s remote management capabilities with proper authentication mechanisms, such as certificate-based authentication systems.

Currently, there are plenty of tutorials around to guide even the most inexperienced developers with step-by-step guides.

With Docker gaining a more prominent place in modern-day infrastructure setup, with attacks on the rise, and with the number of malware strains that target Docker systems growing by the month, it’s time that developers took Docker security seriously.

Overview

Cybersecurity researchers at Intezer disclosed a Linux backdoor, dubbed Doki, that was completely undetected by major antivirus engines at the time of publication. The malware specifically targets Docker servers whose API endpoints are left publicly accessible — a misconfiguration common enough that attackers have built an ongoing automated campaign around it. Affected infrastructure includes cloud-hosted instances on AWS, Azure, and Alibaba Cloud.

What Is the Ngrok Mining Botnet Campaign?

The Doki malware is distributed as part of a broader campaign operated by the Ngrok mining botnet, which had already been active for approximately two years at the time of the Intezer disclosure. The campaign continuously scans the public internet for misconfigured Docker API endpoints. Once a vulnerable host is identified, attackers deploy malicious containers running cryptocurrency miners on the victim’s infrastructure — effectively stealing compute resources for profit.

What Makes Doki Unusual?

Doki stands out for several technical reasons beyond simply being a cryptominer dropper.

Blockchain-Based C2 Domain Generation

Rather than hardcoding command-and-control (C2) server addresses — which defenders can easily block — Doki uses a Domain Generation Algorithm (DGA) tied to the Dogecoin blockchain. It queries the Dogecoin block explorer in real time to derive the current C2 domain dynamically. Combined with the DynDNS service, this makes the C2 infrastructure extremely resilient: even if one domain is taken down, the algorithm generates a new one based on live blockchain data that only the attacker controls by spending Dogecoin.

Short-Lived Payload URLs

Doki crafts unique URLs with very short lifetimes to download payloads during an attack. This limits the window during which defenders or automated systems can retrieve and analyze the payload, complicating incident response and threat intelligence collection.

Cryptographic Network Communication

The malware uses the embedTLS library for encrypted network communication and cryptographic functions, helping it blend in with legitimate TLS traffic and resist inspection.

Evasion Track Record

According to Intezer’s findings, Doki was first uploaded to VirusTotal on January 14, 2020, and had been scanned multiple times since. Despite this, at the time of the July 2020 report it remained undetected by all 61 antivirus engines indexed on VirusTotal — a period of over six months of effective evasion.

Attack Chain: How Docker Hosts Are Compromised

The attack follows a clear progression once a misconfigured Docker API is found:

1. Discovery: The botnet scans the internet for Docker API endpoints that are publicly accessible without authentication.
2. Container deployment: Attackers use the exposed API to create a new malicious container, binding it to the host’s root filesystem (/) using Docker’s volume bind-mount feature.
3. Host escape: Because the container has access to the host’s root directory, the attacker can read and modify any file on the underlying machine — effectively escaping the container isolation boundary.
4. Persistence via cron: The attacker modifies the host machine’s cron configuration (accessible via the bind mount) to execute a downloaded payload every minute, ensuring persistence across container restarts.
5. Lateral scanning: Doki then uses network scanning tools — including zmap, zgrab, and jq — to scan for additional services on the network, specifically targeting ports associated with Redis, Docker, SSH, and HTTP, enabling further spread.

Why This Attack Is Particularly Dangerous

The combination of techniques makes this campaign more severe than a typical cryptojacking incident:

• Full host compromise: By binding containers to the host root, attackers gain capabilities far beyond what a contained environment should allow — including reading secrets, SSH keys, and modifying system binaries.
• Resilient C2: The blockchain-based DGA means that traditional domain blocklists and DNS sinkholes are ineffective against Doki.
• Multi-stage lateral movement: Active network scanning for Redis and SSH means a single compromised Docker host can become a pivot point into the broader internal network.
• Long undetected dwell time: Over six months of antivirus evasion means compromised systems may have been exfiltrating resources or data long before discovery.

Mitigation and Hardening Recommendations

The root cause of this attack is a misconfigured Docker daemon with its API exposed to the public internet. The following steps significantly reduce exposure:

1. Do Not Expose the Docker API to the Internet

By default, the Docker daemon listens on a Unix socket (/var/run/docker.sock), which is local-only. If you have configured Docker to listen on a TCP port (e.g., 2375 or 2376), restrict access using firewall rules so it is reachable only from known internal IP ranges or a VPN.

# Example: block public access to Docker API port with ufw
ufw deny 2375
ufw deny 2376

2. Use TLS Authentication for Remote API Access

If remote Docker API access is genuinely required, configure mutual TLS so that only clients with a valid certificate can connect. Docker’s documentation covers generating CA, server, and client certificates for this purpose.

3. Audit Bind Mounts

Avoid mounting the host root filesystem (/) or sensitive directories (e.g., /etc, /var/spool/cron) into containers. Review all docker run -v or Compose volumes: configurations for overly permissive mounts.

4. Implement Runtime Security Controls

Use runtime security tools (such as Falco, Sysdig, or similar) to detect anomalous behavior inside containers, such as cron modification, unexpected outbound connections, or cryptocurrency miner process signatures.

5. Validate API Parameters Carefully

If your application programmatically calls the Docker API to provision containers, rigorously validate all user-supplied parameters. An attacker who can influence API calls may be able to specify arbitrary bind mounts or privileged flags.

6. Apply Least-Privilege Principles

Run containers as non-root users where possible, use read-only root filesystems (--read-only), drop unnecessary Linux capabilities, and consider enabling user namespaces to limit the blast radius of a container escape.

Broader Context: Docker as a Recurring Attack Surface

The Doki disclosure was not an isolated event. In the same month (July 2020), separate malicious actors were reported targeting exposed Docker API endpoints to deploy images designed to conduct DDoS attacks and mine cryptocurrency. Exposed container APIs have been a consistent target for threat actors since at least 2018, making API access control one of the most critical security concerns for any team running Docker in a cloud environment.

Summary

The Doki malware represents a sophisticated evolution in cloud-targeting threats. Its use of a blockchain-based DGA for C2 resilience, combined with container escape via bind mounts and long antivirus evasion, makes it a serious risk for any organization with misconfigured Docker infrastructure. The defensive posture is straightforward: never expose the Docker daemon to the public internet, restrict access aggressively, audit container configurations for overly permissive mounts, and deploy runtime anomaly detection.

This article examines the primary attack surfaces in cloud-based coding platforms, with particular reference to AWS Cloud9 and Visual Studio Online (now Visual Studio Code for the Web / GitHub Codespaces), and provides actionable recommendations for each risk area.

How Online IDEs Work

In a cloud IDE, the editor interface is rendered inside your browser. Under the hood, the browser’s JavaScript engine opens a WebSocket connection that tunnels an SSH session to a linked backend device — typically a cloud-hosted virtual machine (VM) or virtual private server (VPS). That backend environment holds everything a developer needs:

• A copy of the source code repository
• Compilers, runtimes, and build tools
• Cloud provider configuration files (e.g., ~/.aws/credentials)
• Access tokens and secrets used by CI/CD pipelines or SDKs

The key architectural difference between a local IDE and a cloud IDE is where the environment lives. Locally, everything runs on hardware you control. In a cloud IDE, the environment lives in a VM managed — at least in part — by a third-party cloud provider. That delegation of trust is the starting point for any security discussion.

Attack Surface 1: The Linked VM or Device

Whether you use AWS Cloud9 or Visual Studio Online, a backend server process must run on the linked machine to handle communication with your browser. In the case of Visual Studio Online, this is a Node.js-based VS Code server. In AWS Cloud9, the backend agent runs alongside a separate cloud-hosted frontend.

In both platforms, users can escalate to root on the linked VM. While this is necessary for installing tools and configuring the environment, it also means a misconfiguration — or a compromised session — gives an attacker full control over the machine and every secret it holds.

Common VM-Level Risks

• Exposed IDE ports: Some platforms allow you to make the IDE publicly accessible — for pair programming or demos. If left open unintentionally, this creates a direct entry point for attackers.
• Plaintext secrets: Access tokens are frequently stored in plaintext configuration files rather than encrypted vaults. Anyone who gains access to the VM’s filesystem can read them directly.
• Supply chain risk: Compromised credentials or source code on a developer VM can be used to inject malicious code into software updates or package releases — a classic supply chain attack vector.
• Third-party plugin misconfigurations: AWS Cloud9 does not support third-party plugins, reducing some risk; however, other platforms that do support plugins inherit any misconfiguration those plugins introduce.

Recommendations

• Only install software from verified, trustworthy sources on the linked VM.
• Keep the OS, runtime environments, and all installed tools patched and up to date.
• Never expose IDE ports to the public internet unless required, and always restrict access using IP allowlisting or VPN.
• Store secrets in a dedicated secrets manager (e.g., AWS Secrets Manager, HashiCorp Vault) rather than in plaintext files on disk.

Attack Surface 2: The Web Browser

Because cloud IDEs are web applications, the security of the browser and the machine running it directly affects the security of your coding environment.

Accessing a cloud IDE from a shared, public, or unmanaged computer is a significant risk. Keyloggers, session-hijacking malware, or a compromised browser profile could expose your session credentials or allow an attacker to observe or modify code in real time.

Malicious browser extensions are a well-documented threat. An extension with broad permissions — access to all page content, clipboard, or network requests — installed in the browser used to access your IDE could silently exfiltrate source code or inject modifications without any visible indication.

Recommendations

• Only access cloud IDEs from company-managed, domain-joined devices with endpoint protection enabled.
• Avoid shared or public computers entirely for development work.
• Audit installed browser extensions regularly; remove any that are unused or from unverified publishers.
• Use a dedicated browser profile for development work to isolate extensions and session cookies.

Attack Surface 3: IDE Extensions and Plugins

One of the strengths of the VS Code ecosystem — and by extension Visual Studio Online — is its large library of community extensions. That same openness is an attack surface.

VS Code extensions run with significant privileges. They can access the disk, the network, and running processes. At the time of publishing the research this article is based on, extension marketplace checks were limited to verifying a valid publisher ID and some image-related restrictions — not a deep security review of extension code. This means developers must exercise their own judgment about which extensions to trust.

A malicious extension disguised as a useful utility could embed a backdoor that exfiltrates source code, injects malicious commits, or opens a reverse shell to an attacker-controlled server — all from within the trusted context of the IDE itself.

Recommendations

• Only install extensions from well-known publishers with a verifiable track record and public source repositories.
• Review extension permissions and source code where possible before installation.
• Maintain an approved extension list at the team or organization level to reduce the risk of individual developers installing unsafe extensions.
• Remove extensions that are no longer actively maintained.

Attack Surface 4: Vulnerabilities in the Platform Itself

No software is free of vulnerabilities. Because cloud IDEs are web applications, they are potentially subject to web-class vulnerabilities such as Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), and authentication bypass flaws.

A vulnerability that allows an attacker to execute arbitrary JavaScript within the IDE context could give them control over the editor interface, the terminal, and by extension the linked backend VM. The original research notes a historical vulnerability affecting the Visual Studio Live Share extension as one example of how vulnerabilities in IDE tooling can have serious downstream consequences.

Recommendations

• Keep the IDE platform, its backend agent, and all extensions updated to the latest available versions.
• Subscribe to security advisories from your cloud IDE vendor so you can respond quickly to disclosed vulnerabilities.
• Apply the principle of least privilege: restrict what the IDE’s backend VM can access on your internal network.

Applying Threat Modeling to Cloud IDEs

Threat modeling is the structured process of identifying what could go wrong in a system, who might cause it, and what the impact would be. Cloud IDEs should be included in your organization’s threat model just like any other production-facing system — arguably more so, because a compromised development environment can become a vector for supply chain attacks against your customers.

When threat modeling a cloud IDE deployment, consider the following questions:

• What secrets does the backend VM hold, and how are they protected at rest?
• Who has access to the linked VM, and how is that access logged and audited?
• What would happen if a developer’s browser session were hijacked?
• How would you detect a malicious extension that was silently exfiltrating code?
• Is the IDE VM network-isolated from production infrastructure?

Quick Reference: Security Recommendations by Risk Area

Original research credit: Trend Micro / devops.com (2020).

High-Profile Incidents That Put DevOps Security in the Spotlight

In late September 2019, Avast disclosed that it had detected an intrusion into its internal network via a temporary VPN profile that lacked two-factor authentication. Security researchers believed the attackers’ goal was to plant malware inside CCleaner—a widely used system-cleanup utility—repeating a technique that had succeeded in 2017, when cybercriminals successfully trojanized CCleaner and distributed it to millions of users. The 2019 attempt was detected and disrupted before any official build was compromised.

Earlier in April 2019, Docker disclosed a breach of a single Docker Hub database that exposed sensitive information from approximately 190,000 accounts. Investigators suspected the attackers may have attempted to implant malware in official Docker images used to instantiate containers. Docker confirmed that no official images were ultimately compromised, but the incident underscored how a single point of failure in a container registry can threaten countless downstream environments.

These are examples of software supply chain attacks—a category in which adversaries compromise widely used software or infrastructure upstream so that the malware propagates automatically to every organization that installs or pulls from that source. The technique is attractive precisely because a single successful intrusion can reach millions of targets simultaneously.

Why DevOps Environments Are Prime Targets

1. Rapid Cloud Adoption Creates Sprawl

DevOps pipelines are increasingly running on public cloud platforms. Keeping pace with the dynamic nature of cloud environments—constantly changing components, configurations, permissions, and services—places an enormous operational burden on teams that are already moving fast. The resulting configuration drift can leave critical gaps, including:

• Accounts without multi-factor authentication (MFA/2FA) enabled
• Object storage buckets misconfigured with public read or write access
• Container API endpoints exposed without access controls
• Serverless function invocation URLs left unprotected
• Over-permissioned IAM roles and service accounts

2. Modern Software Is a Web of Third-Party Components

Software development today rarely means writing every line from scratch. Production applications routinely depend on dozens or hundreds of open-source packages, commercial SDKs, base container images, and CI/CD plugins. Each dependency is a potential entry point. Compromising any single component in this ecosystem—a popular npm package, a PyPI library, a Docker base image—can give an attacker an immediate foothold across every project that consumes it.

What DevOps Teams Can Do to Defend Against These Attacks

Preventive controls such as MFA, firewalls, web application firewalls (WAF), anti-malware tools, and secure email gateways are necessary but no longer sufficient on their own. Sophisticated supply chain attackers routinely bypass these layers. A robust strategy must combine prevention with continuous monitoring and rapid incident response.

Monitor DevOps Pipelines and Cloud Infrastructure

Early detection is the single most important factor in limiting blast radius. Every meaningful activity in the DevOps workflow—code pushes, build triggers, artifact publishes, and deployments—should be logged and profiled against a baseline of normal behavior. Anomalies to investigate include:

• Access from unexpected geographic regions or IP ranges
• Logins outside normal working hours
• Unusual changes to build configurations or pipeline definitions
• Artifact publishes that do not correspond to a recognized commit or build job

Platform-level event streams—for example, Azure DevOps audit logs, GitHub audit logs, or GitLab’s audit events—can feed a SIEM or monitoring platform to provide this visibility without requiring agents on individual build hosts. Underlying cloud infrastructure (virtual machines, storage accounts, management consoles, PaaS services) should be monitored in the same way, since infrastructure-layer compromises are frequently used as a stepping stone to reach the pipeline itself.

Monitor Production Container Environments

Container security requires visibility at multiple layers:

• Intra-container events: Process execution, file-system writes, and outbound network connections from within a running container can reveal compromised processes or malware payloads. Achieving this visibility typically requires embedding lightweight monitoring agents or eBPF-based probes as part of the golden image build.
• Container-to-container communication: Profiling expected network flows between containers—using data from the orchestration layer (Kubernetes network policies, service mesh telemetry)—makes it possible to detect rogue containers establishing unexpected connections.
• Image provenance: Enforce image signing and verify digests at deploy time so that only images from trusted registries and with verified signatures can run in production.

Continuously Assess Cloud Configuration

A point-in-time audit is not enough in a cloud-native environment where configuration changes happen constantly. Automated cloud security posture management (CSPM) tools can continuously benchmark running configurations across virtual machines, storage, databases, management consoles, container clusters, and identity policies. The CIS Benchmarks are a widely adopted, vendor-neutral baseline for this kind of assessment and are available for major cloud providers, operating systems, and Kubernetes.

Scan Every Software Component for Vulnerabilities and Malware

Dependency scanning and software composition analysis (SCA) should be mandatory gates in the CI/CD pipeline, not optional afterthoughts. Effective component security includes:

• Scanning open-source dependencies for known CVEs before they are merged or promoted
• Scanning container images for vulnerable OS packages and application libraries
• Analyzing first-party and third-party code for suspicious patterns or embedded malware
• Generating and maintaining a Software Bill of Materials (SBOM) so you can respond quickly when a new vulnerability is disclosed in a component you use

The Bigger Picture

Cybercrime syndicates and state-sponsored threat actors have recognized that compromising software at its source—inside the DevOps pipeline—delivers a much higher return than attacking individual organizations one by one. A single implant in a widely distributed package or container image can propagate to thousands of organizations before anyone raises an alarm.

Defending against this threat model requires treating security as a first-class concern throughout the software delivery lifecycle: enforcing least-privilege access, enabling MFA everywhere, scanning every artifact, monitoring every pipeline event, and being prepared to respond the moment something anomalous appears. The organizations that invest in this discipline now will be far better positioned to detect and contain the supply chain attacks that are certain to continue.