Containing the Threat: Analyzing cryptomining campaigns

Containing the Threat: Analyzing cryptomining campaigns

Speakers: Bogdan Trufanda (Threat Hunter, CrowdStrike), Mihai Vasilescu (Threat Hunter, CrowdStrike)

Conference: DefCamp

YouTube: https://www.youtube.com/watch?v=s2V2LQ6Y1HM

Overview

In an insightful presentation at DefCamp, CrowdStrike threat hunters Bogdan Trufanda and Mihai Vasilescu delved into the pervasive and rapidly evolving landscape of cryptomining campaigns targeting container environments. Their talk, "Containing the Threat: Analyzing cryptomining campaigns," illuminated the tactics, techniques, and procedures (TTPs) employed by notorious cybercrime groups to exploit container vulnerabilities, primarily focusing on Docker. The speakers provided a critical overview of how these opportunistic adversaries leverage misconfigurations, particularly exposed Docker APIs, to gain root access to host systems, deploy cryptominers, and often exfiltrate sensitive credentials.

The presentation underscored the urgent need for robust container security, offering actionable recommendations for security professionals. With cryptomining attempts numbering around 30,000 internally observed attacks, the scale of this threat is significant. This article synthesizes their findings, examining the technical underpinnings of these attacks, the distinct methodologies of prominent threat actors like Kinsing, Team TNT, and Outlaw, and crucial defensive strategies to mitigate these fast-moving threats.

The core message of the talk resonated with the stark reality that many organizations inadvertently leave their digital doors open, allowing attackers to quickly compromise infrastructure for financial gain. By dissecting the common attack vectors and the specific tools used by these groups, Trufanda and Vasilescu provided a comprehensive guide for understanding, detecting, and ultimately containing the threat of cryptomining in containerized environments.

Background

▶ Watch: Introduction to container threats and agenda (0:00)

To comprehend the nature of these attacks, it’s essential to grasp fundamental container concepts. The speakers clarified that, from a host Linux environments perspective, a container is not a VM (Virtual Machine) but merely an isolated PID (Process ID) or process sharing the same kernel as the host. This isolation is achieved through two primary Linux kernel mechanisms: namespaces and cgroups. Namespaces limit what a process can "see" (e.g., other processes, network interfaces), while cgroups limit "how much" a process can use (e.g., CPU, memory). The PID namespace is particularly critical, as sharing the host's PID namespace (--pid=host) allows a container to view all processes running on the host, a common technique in container escapes. By default, Docker containers often have no memory resource constraints, allowing an attacker to launch a resource-intensive fork bomb if unchecked.

The typical Docker architecture involves three main components: the Docker client (for issuing commands), the Docker daemon (a background process managing images and containers), and the Docker registry (for storing images). The fundamental vulnerability exploited by cryptominers stems from how the Docker daemon and client communicate. While they typically use a secure Unix socket on the local machine, administrators can configure the Docker daemon to expose its Docker API over a TCP socket to allow remote management. This exposure is the root cause of nearly all cryptomining attacks discussed, as it grants an attacker unrestricted access to run containers with the security privileges of the Docker service – which, by default, is root. Essentially, an exposed Docker API is akin to providing unauthenticated root access to the host system.

The motivation behind these campaigns is purely financial. Attackers leverage the computational resources of compromised infrastructure to cryptomine various digital currencies, primarily Monero. This allows them to generate income without incurring any operational costs. The prevalence of these attacks is alarming, with CrowdStrike's internal database recording approximately 30,000 miner-related attack attempts, highlighting the widespread nature of this opportunistic threat vector.

Key Findings

▶ Watch: Kinsing's attack flow and DSH initial payload (7:45)

The talk identified three prominent cybercrime groups actively engaged in cryptomining campaigns against container environments: Kinsing, Team TNT, and Outlaw (aka Haiduk). While all share the common goal of exploiting exposed Docker APIs for cryptomining, each group exhibits distinct TTPs and an evolving arsenal.

Kinsing, active since 2019, is characterized by its opportunistic attacks, primarily gaining initial access via exposed Docker and Redis instances, along with other easy-to-exploit vulnerabilities. A key finding is their use of a custom malware, also named Kinsing, for persistence. Their attack flow is straightforward: they scan for exposed Docker APIs using Masscan, deploy basic Ubuntu containers, and then execute a script named D.sh. This script downloads the Kinsing malware and cryptominer, followed by spre.sh for lateral movement via SSH. Interestingly, Kinsing campaigns still utilize older Docker API versions (specifically v1.24) in their POST requests, suggesting a focus on less-maintained, older Docker engine installations. Their C2 communication uses simple RC4 encryption over HTTP, which is basic but notoriously difficult to detect without specific Suricata rules.

Team TNT stands out for its unique "public persona," maintaining GitHub and Twitter accounts where they sometimes engaged with security analysts, even "shaming" them for perceived inaccuracies in their blog posts. This group has a long history, with evidence dating back almost seven years, initially targeting Redis in early 2020 before shifting to exposed Docker APIs and later Kubernetes Kubelet APIs. A significant evolution observed from 2024 is their transition from using legitimate base images (like Alpine or Ubuntu) to creating custom Docker images with miners pre-baked in. Beyond cryptomining, Team TNT is notable for actively exfiltrating tokens and credentials, including cloud credentials (e.g., AWS, GCP keys), using tools like Sliver as their C2 framework. Their tdg.sh init script also incorporates Masscan and ZGRAB for worm-like lateral movement.

Outlaw (aka Haiduk), an older group, maintains a simpler initial access vector, relying heavily on SSH brute force and stolen credentials. Once inside, they deploy a dota33.rgz archive containing three distinct components: KswapD00 (a modified XMrig miner), stealth shellbot (a Perl-based IRC C2 for persistence), and kreadd3264 (a tool for internal brute-forcing). A peculiar finding related to Outlaw is their use of profanities within the SSH authorized_keys file for persistence, which can serve as a distinct identifier. They also employ a less common "command splitting" obfuscation technique in some scripts, alongside standard Base64 encoding. The speakers noted Outlaw's use of newer UPX versions for packing their binaries, indicating some effort to evade detection and unpacking.

Across all groups, the common thread is the speed and opportunism of their attacks. Once an exposed Docker API is identified, compromise and miner deployment can occur in mere seconds, highlighting the critical importance of preventing such exposures.

Technical Deep Dive

▶ Watch: Team TNT's advanced tactics: privileged containers, custom images (17:00)

The fundamental vulnerability exploited by all three threat actors is the exposure of the Docker API over a TCP socket without proper authentication. When Docker is installed, its daemon (which runs as root by default) communicates with the client via a Unix socket. However, if an administrator configures the daemon to listen on a TCP port (e.g., tcp://0.0.0.0:2375), it effectively provides an unauthenticated remote root shell to anyone who can connect to that port. An attacker can then issue docker run commands, creating containers with full host privileges.

A critical technique for container escape and gaining full host control is the use of specific Docker flags. The --privileged flag effectively drops most security boundaries, giving the container nearly all capabilities of the host. More subtly, sharing the host's PID namespace with --pid=host allows the container to see all processes on the host. Combined with tools like ncenter (as shown in the demo), this enables an attacker to break out of the container and execute commands directly on the host with root privileges.

Kinsing's D.sh script exemplifies a multi-stage payload. The D.sh, O.sh, F.sh, and PG.sh variants are nearly identical in content, primarily designed to kill other cryptominers (to ensure their miner gets maximum resources) and download the Kinsing malware. The naming convention serves as an indicator of the initial access vector (e.g., D.sh for Docker, O.sh for Oracle WebLogic, PG.sh for PostgreSQL). Their C2 communication, using RC4 encryption over HTTP, is rudimentary but effective. The GET /kinsing request, while simple, required specific Suricata rules (to be released by the speakers) for network detection, as it's not commonly flagged by generic rules. Lateral movement is achieved via spre.sh, which parses SSH configuration files and bash_history for existing connections to other machines, then replicates these connections to deploy further instances.

Team TNT's evolution highlights a shift towards greater sophistication in some areas. Their tdg.sh init script is responsible for launching the miner, establishing persistence, and initiating lateral movement. Their use of Masscan to find new targets and ZGRAB to identify Docker API headers is a worm-like capability. A notable change in their attack execution is the transition to --privileged containers and the use of their custom Docker images hosted on DockerHub, which already contain the XMrig miner as an entry point. For persistence and C2, Team TNT has moved from older rootkits like Tsunami to the more modern Sliver C2 framework. They often download the Sliver implant to /tmp with wget, making it relatively easy to detect by monitoring for this specific file path and name. Critically, Team TNT goes beyond mere cryptomining; they actively exfiltrate cloud credentials and other tokens by searching for metaip and credentials strings, encoding them in Base64, and sending them via curl or wget to their C2 infrastructure. Their expansion to Kubernetes involves scanning for exposed Kubelet APIs and using curl to install miners directly.

Outlaw's toolset, while sometimes using less sophisticated initial access (SSH brute force), demonstrates a structured approach. The dota33.rgz archive contains KswapD00, a widely known modified XMrig binary packed with UPX. Their stealth shellbot is a Perl-based IRC C2 bot, a classic but still effective persistence mechanism. The kreadd3264 binary is used for internal network brute-forcing. Outlaw's use of "command splitting into variables" for obfuscation (e.g., VAR1="com"; VAR2="mand"; $VAR1$VAR2) is an interesting technique, though they also revert to Base64 encoding in other scripts. The presence of profanities in their SSH authorized_keys entries serves as a unique "branding" for detection. Their use of newer UPX versions (which are not unpackable by default with older ucl versions) indicates a conscious effort to make analysis slightly more difficult.

Across all these groups, the common thread is the rapid execution of the attack chain. From initial access to full host compromise and miner deployment, the entire process can take less than 15 seconds, emphasizing the need for real-time detection and prevention.

Demo / Proof of Concept

▶ Watch: Hardening Docker and future security outlook (35:00)

The speakers conducted a compelling live demonstration to illustrate the alarming speed and simplicity of these cryptomining attacks. The setup involved a C2 (Command and Control) machine and a victim machine with an intentionally exposed Docker API listening on a TCP port.

Initially, the victim machine showed no running Docker containers and its public IP address was displayed. From the C2, simulating the discovery of the exposed Docker API via Masscan, the attacker executed a single docker run command:

docker -H tcp://VICTIM_IP:2375 run --privileged --pid=host -it alpine ncenter --mount --target 1 --all /bin/bash

This command is highly impactful:

• -H tcp://VICTIM_IP:2375: Specifies the remote Docker daemon to target.
• --privileged: Grants the container almost all host capabilities, effectively removing security boundaries.
• --pid=host: Shares the host's PID namespace, allowing the container to see and interact with host processes.
• alpine: Uses a lightweight Alpine Linux image.
• ncenter --mount --target 1 --all /bin/bash: This is the container escape mechanism. ncenter allows entering the namespaces of an existing process. By targeting PID 1 (the init process of the host) and mounting all namespaces, the attacker immediately gains a root shell on the victim host, outside the container's isolation.

The demonstration showed that within milliseconds of executing this command, a container was created on the victim, and the C2 machine had a functional root shell on the host. The speakers emphasized that while this was done "hands-on keyboard," an automated script would achieve this with even greater speed, potentially within milliseconds from finding the exposed API to full compromise and miner installation.

To further illustrate the post-exploitation phase, the demo continued with lateral movement and credential exfiltration.

1. From the newly acquired root shell on the victim, the attacker used the history command to discover internal IP addresses and past connections.
2. Employing Hydra, an SSH brute-forcing tool, the attacker targeted a private IP address (representing a second victim machine, Victim 2) found in the history, successfully cracking a weak password for the ubuntu user.
3. An SSH connection was established to Victim 2, which was not directly accessible from the internet but was reachable from the initially compromised victim.
4. Once on Victim 2, the attacker demonstrated finding dummy GCP credentials and AWS keys.
5. These credentials were then exfiltrated using curl to a basic web server set up on the C2 machine, showcasing how easily sensitive data can be stolen once root access is gained.

The demo starkly highlighted the "leaving your house door open with all your money on your table" analogy, underscoring that exposed Docker APIs present an immediate, high-severity risk that can lead to rapid, widespread compromise and data theft.

Defensive Implications

▶ Watch: Q&A: Docker vs. Podman security comparison (44:00)

The primary and most critical defensive implication is unequivocally: DO NOT expose the Docker API over a TCP socket without robust authentication (e.g., TLS). This single misconfiguration is the gateway for the vast majority of these opportunistic cryptomining attacks. If remote access is absolutely necessary, TLS authentication should be mandatory, ensuring only authorized clients can communicate with the Docker daemon.

Beyond this fundamental step, several other defensive strategies are crucial:

• Harden Docker Installations: While keeping the Docker engine up to date is generally good practice, it doesn't solve the exposed API problem. However, applying security good practices for container usage is vital. This includes specifying resource limits (CPU, RAM) for containers to prevent resource exhaustion from cryptominers, though these limits must be explicitly set by the user for each container.
• Implement Docker Rootless Mode: The speakers highlighted Podman as a more secure alternative because it uses user namespaces by default, meaning even if an attacker escapes a container, they only gain unprivileged user access on the host, requiring further privilege escalation. While Docker Rootless mode exists, it is not the default, but enabling it can significantly mitigate the impact of a container escape by ensuring the container process does not run as root on the host.
• Monitor for Specific TTPs and Indicators of Compromise (IoCs):
• Network Monitoring: Look for outbound connections from containers to known cryptomining pools or unusual C2 traffic patterns. Deploy the upcoming Suricata rules mentioned by the speakers to detect Kinsing's RC4 over HTTP communication.
• Process Monitoring: Monitor for suspicious processes running inside containers or on the host that are consuming high CPU, especially those named XMrig, KswapD00, or Sliver.
• File System Monitoring: Look for the presence of specific scripts like D.sh, tdg.sh, spre.sh, or the Sliver implant in /tmp. Also, check SSH authorized_keys for unusual entries, especially those containing profanities (an Outlaw signature).
• Docker API Versioning: Be aware that groups like Kinsing target older Docker API versions (e.g., v1.24). Monitor for POST requests targeting these older versions.
• Secure SSH: Enforce strong, unique passwords for all SSH accounts. Ideally, use SSH keys with passphrases and disable password authentication. Regularly review SSH authorized_keys files for unauthorized entries. This addresses the initial access and lateral movement techniques of groups like Outlaw and Team TNT.
• Protect Cloud Credentials: Implement strict access controls and least privilege for cloud environments. Monitor for suspicious access patterns to cloud APIs and for exfiltration of cloud credentials (e.g., AWS keys, GCP tokens).
• Runtime Security Tools: Deploy container runtime security solutions that can detect and prevent malicious activity within containers and on the host.
• Hope for Docker's Evolution: The speakers noted that Docker has been slow to deprecate insecure API exposure, unlike Redis, which significantly improved its default security posture by not running as root and limiting remote command execution. A similar shift in Docker's default configurations would drastically reduce the attack surface.

In summary, a multi-layered defense combining secure configuration, strong authentication, continuous monitoring, and awareness of specific threat actor TTPs is essential to protect containerized environments from these fast and opportunistic cryptomining campaigns.

Key Takeaways

• Exposed Docker API is a Critical Vulnerability: The core issue enabling these cryptomining campaigns is the exposure of the Docker API over an unauthenticated TCP socket, which effectively grants remote root access to the host system.
• Attacks are Opportunistic and Rapid: Threat actors like Kinsing, Team TNT, and Outlaw continuously scan the internet for misconfigured Docker instances. Once found, compromise, container escape, and cryptominer deployment can occur in seconds, often less than 15 seconds for the entire kill chain.
• Beyond Cryptomining: Credential Theft: While cryptomining is the primary goal, groups like Team TNT actively exfiltrate sensitive data, including cloud credentials (AWS, GCP tokens), highlighting the broader risks of these compromises.
• Diverse but Evolving TTPs: Each threat actor employs distinct methods for initial access, persistence, and lateral movement. Kinsing uses older Docker API versions and custom malware, Team TNT evolves to custom Docker images and the Sliver C2 framework, and Outlaw relies on SSH brute-forcing and a blend of custom and commodity tools.
• Strong Defensive Posture is Essential: Organizations must prioritize securing Docker API exposure (using TLS or Unix sockets only), implementing Docker Rootless mode, enforcing strong SSH security, and deploying robust container runtime security tools.
• Active Monitoring and Threat Hunting: Proactive monitoring for specific IoCs (e.g., D.sh, Sliver implant, profanities in authorized_keys, specific Docker API versions) and network traffic patterns (e.g., Kinsing C2) is crucial for early detection and response.

About the Speaker(s)

Bogdan Trufanda and Mihai Vasilescu are esteemed Threat Hunters at CrowdStrike. Their expertise lies in the in-depth analysis of cybercrime groups and their evolving methodologies. Through their work, they provide critical insights into emerging threats, especially in dynamic environments like containerization. Their presentation at DefCamp showcased their practical understanding of adversary TTPs and their commitment to arming security professionals with actionable intelligence to defend against prevalent threats like cryptomining campaigns.