"Efficient Cryptominer Deployment with gRPC and HTTP/2"

Trend Micro researchers observed attackers abusing exposed Docker remote API servers to build and deploy a containerized SRBMiner cryptominer that mines XRP. The adversary leveraged gRPC over h2c to evade protections, performed API discovery and buildkit gRPC calls to create a Dockerfile.srb that downloads SRBMiner from GitHub and starts mining to a Ripple wallet. #SRBMiner #Docker #XRP

Keypoints

Attackers targeted exposed Docker remote API servers to gain access and control over container hosts.
The threat actor used gRPC over h2c (cleartext HTTP/2) to bypass security controls and upgrade connections to gRPC.
The SRBMiner cryptominer was downloaded from GitHub and deployed inside a malicious image to mine XRP.
The attacker performed discovery steps including ping and version checks against the Docker API before proceeding.
gRPC methods (including a buildkit Solve request) were used to create a Dockerfile.srb based on debian:bookworm-slim and to build the malicious container.
The miner was placed under /usr/sbin after being extracted in /tmp/.1 and configured to use a Ripple wallet address and a public IP target.
Trend Micro recommends securing Docker APIs, avoiding root containers, restricting access, performing audits, and offers Vision One container and workload protections.

MITRE Techniques

[T1190] Exploit Public-Facing Application – Used to gain initial access by abusing Docker’s exposed remote API (‘targeting Docker remote API servers to deploy the SRBMiner cryptominer’).
[T1133] External Remote Services – Leveraged remote management services to interact with and control Docker hosts (‘the attacker starts the discovery process by checking the Docker API’s availability and version’).
[T1610] Deploy Container – Built and deployed a malicious container image via gRPC build requests to execute the cryptominer (‘the attacker sends the /moby.buildkit.v1.Control/Solve gRPC request to build the Docker image-based Dockerfile.srb’).
[T1105] Ingress Tool Transfer – Retrieved the SRBMiner binary from an external GitHub release and transferred it into the target environment (‘downloads and unzips the SRBMiner from GitHub into the /tmp/.1 directory’).
[T1071.001] Application Layer Protocol: Web Protocols – Used gRPC over h2c (HTTP/2 cleartext) as the transport to issue commands and evade detection (‘utilizing gRPC protocol over h2c (clear text HTTP/2 protocol) to evade security solutions’).
[T1496] Resource Hijacking – Illicitly used the host’s CPU resources for cryptocurrency mining (SRBMiner configured to mine XRP to the attacker’s wallet and IP).
[T1016.001] System Network Configuration Discovery: Internet Connection Discovery – Performed network discovery and API version checks to identify exploitable Docker instances (‘checking the Docker API’s availability and version’).

Indicators of Compromise

[SHA256] SRBMiner binary detection – 0d4eb69b551cb538a9a4c46f7b57906a47bcabb8ef8a5d245584fbba09fc5084 (detected as PUA.Linux.SRBMine.A/277100)
[Download URL] Malicious GitHub release used to retrieve miner – https://github.com/doktor83/SRBMiner-Multi/releases/download/2.5.8/SRBMiner-Multi-2-5-8-Linux.tar.g
[IP addresses] Miner C2/pool connections and endpoints – 167.71.194.227:3333, 59.93.45.16
[File paths / names] Malicious build artifacts and runtime locations – Dockerfile.srb, /tmp/.1 (download/unzip), /usr/sbin (deployed miner)

Trend Micro researchers recently documented a campaign in which an actor exploited misconfigured Docker remote API servers to deploy a containerized cryptominer. Docker’s remote management API enables powerful remote operations for containers, images, and volumes, but when it is exposed to the internet without proper controls it becomes an attractive entry point for attackers. In these incidents the adversary used gRPC over h2c—a cleartext HTTP/2 upgrade—to slip past security measures and establish the protocol channel necessary to issue gRPC method calls to the Docker service.

The intrusion began with reconnaissance: the attacker probed the target by sending ping and version requests to the Docker API to confirm availability and the API version. Following successful discovery, the actor requested a protocol upgrade to gRPC/h2c and enumerated available gRPC methods. Those methods included health checks, file sync, authentication/token operations, secrets retrieval, and SSH agent forwarding; the attacker leveraged build-related methods such as /moby.buildkit.v1.Control/Solve to instruct the server to construct an image from a Dockerfile named Dockerfile.srb.

Using the buildkit Solve request, the threat actor provided build parameters that referenced a benign base image (debian:bookworm-slim) but included additional instructions to fetch and install SRBMiner. The build process downloaded a release archive from GitHub, extracted the SRBMiner binary into a temporary folder (/tmp/.1), and installed the miner into /usr/sbin inside the resulting image. The container was then used to start mining XRP, configured with the attacker’s Ripple wallet address (wallets commonly begin with “r”) and a public IP indicator formatted in the miner configuration.

This approach illustrates several risks unique to container platforms: remote APIs that are exposed or misconfigured can be used to build and launch arbitrary images, and protocol upgrade mechanisms like h2c can be abused to tunnel unexpected management traffic. By exploiting those capabilities, the adversary combined discovery, remote build, and in-environment binary retrieval to achieve resource hijacking without deploying a traditional executable drop on the host filesystem outside of the container workflow.

To reduce exposure to similar attacks, organizations should ensure Docker remote APIs are never openly accessible on the internet, apply strict access controls and network segmentation, and follow Docker’s security best practices. Containers should run with least privilege rather than as root, and access to management interfaces should be limited to trusted networks and authenticated users. Regular security audits, image and registry scanning, and monitoring for anomalous gRPC or build requests will help detect abuse early.

Trend Micro highlights relevant protections and services for containerized environments, including automated image and registry scanning and workload protection that applies machine learning and virtual patching. Customers of Trend Micro Vision One can consult Threat Insights and use hunting queries to pivot on the indicators described in this report; for example, sample query fragments provided for SBRMiner command-and-control activity reference the IPs 59.93.45.16 and 167.71.194.227:3333. The SRBMiner sample file hash observed in this campaign is 0d4eb69b551cb538a9a4c46f7b57906a47bcabb8ef8a5d245584fbba09fc5084, detected as PUA.Linux.SRBMine.A/277100.

Container platforms enable fast development and deployment, but like any powerful management interface they demand careful configuration and monitoring. The incident documented here underscores how attackers can chain discovery, protocol upgrade, gRPC method calls, and external downloads to produce a malicious image that consumes host resources for illicit cryptocurrency mining. Applying configuration hygiene, restricting remote management endpoints, performing periodic audits, and using layered runtime protections are key to preventing similar compromises.

SHARE THIS STORY

WhatsApp X (Twitter)Telegram Bluesky Facebook LinkedIn Threads Email Print

“Efficient Cryptominer Deployment with gRPC and HTTP/2”