Cyber Threats
Using gRPC and HTTP/2 for Cryptominer Deployment: An Unconventional Approach
In this blog entry, we discuss how malicious actors are exploiting Docker remote API servers via gRPC/h2c to deploy the cryptominer SRBMiner to facilitate their mining of XRP on Docker hosts.
Summary
- Trend Micro researchers recently observed a malicious actor targeting Docker remote API servers to deploy the SRBMiner cryptominer and mine XRP cryptocurrency.
- In this attack, the threat actor used the gRPC protocol over h2c to evade security solutions and execute their cryptomining operations on the Docker host.
- The attacker first checked the availability and version of the Docker API, then proceeds with requests for gRPC/h2c upgrades and gRPC methods to manipulate Docker functionalities.
- Afterwards, the attacker downloaded and deployed the SRBMiner cryptominer from GitHub, and started mining to their cryptocurrency wallet and public IP address.
Recently we observed a malicious actor targeting Docker remote API servers for cryptomining. Docker is a platform that helps developers build, test, deploy, and share applications. One of Docker's features is its remote API, which allows users to manage containers, images, and volumes remotely. However, this feature also introduces security risks if remote API servers are left misconfigured and exposed to the internet, which could lead to security breaches and exploitation by malicious actors.
In this attack, we observed the malicious actor utilizing gRPC protocol over h2c (clear text HTTP/2 protocol) to evade security solutions and deploy the SRBMiner cryptominer on the Docker host to mine XRP, a cryptocurrency developed by the US-based Ripple Labs.
As shown in the attack chain (Figure 1), the attacker starts the discovery process by checking the Docker API’s availability and version (Figures 2 and 3). The attacker then sends a request for a gRPC/h2c upgrade (Figure 4).
Finally, the attacker checks for gRPC methods (Figure 5). These methods are designed to facilitate various operations within Docker, including health checks, file synchronization, authentication, secrets management, and SSH forwarding. They enable clients to perform tasks that are essential for managing and operating Docker environments. As shown in Table 1, each method serves a specific purpose, contributing to the overall functionality and security of Docker-based workflows.
| Method | Purpose | Functionality |
| /grpc.health.v1.Health/Check | Typically used to perform health checks on services. | Allows a client to query the health status of a service. The service responds with its current health status, which can be SERVING, NOT_SERVING, or other statuses defined by the gRPC health protocol. |
| /grpc.health.v1.Health/Watch | Similar to the Check method, but provides a continuous stream of health status updates. | The client subscribes to health status updates, and the server sends updates whenever the health status changes. |
| /moby.filesync.v1.FileSync/DiffCopy | Synchronizes files between the host and a Docker container. | Compares files between the source and destination and copies only the differences to minimize data transfer. |
| /moby.filesync.v1.FileSync/TarStream | Transfers files as a tar stream. | Streams files in the tar format, which is a common archive format in Unix-like systems. |
| /moby.filesync.v1.Auth/Credentials | Manages authentication credentials. | Likely handles storing, retrieving, or validating credentials used for authentication. |
| /moby.filesync.v1.Auth/FetchToken | Retrieves an authentication token. | Fetches a token that can be used for authenticating subsequent requests. |
| /moby.filesync.v1.Auth/GetTokenAuthority | Retrieves information about the token authority. | Provides details about the authority that issues authentication tokens. |
| /moby.filesync.v1.Auth/VerifyTokenAuthority | Verifies the token authority. | Checks the legitimacy and trustworthiness of the token authority. |
| /moby.buildkit.secrets.v1.Secrets/GetSecret | Retrieves a secret. | Fetches a secret, such as an API key, password, or other sensitive information. |
| /moby.sshforward.v1.SSH/CheckAgent | Checks the status of an SSH agent. | Likely verifies whether an SSH agent is running and available for forwarding. |
| /moby.sshforward.v1.SSH/ForwardAgent | Forwards an SSH agent. | Sets up SSH agent forwarding, allowing the client to use the SSH keys stored on the host for authentication with remote systems. |
The attacker then sends a connection upgrade request to h2c protocol. Once the connection upgrade request has been processed by the server with all the required parameters using gRPC requests, the attacker sends the /moby.buildkit.v1.Control/Solve gRPC request to build the Docker image-based Dockerfile.srb (Figure 6), which contains Docker container building details based on the legitimate Docker image, debian:bookworm-slim (FIgure 7).
In the Dockerfile.srb details (Figure 8), we observed that the threat actor downloads and unzips the SRBMiner from GitHub into the /tmp/.1 directory, then deploys the cryptominer in the /usr/sbin directory. Afterwards, the threat actor starts the mining process; it provides their cryptocurrency wallet address, which starts with “r” (Ripple wallet IDs commonly start with this letter), and the cryptominer’s public IP address (with the periods replaced with underscores).
Conclusion
Containerization platforms like Docker are instrumental in modern-day application development, but their features can become security liabilities if not meticulously protected. As demonstrated in this attack, cybercriminals can exploit features like remote management APIs to their advantage: The malicious actor in this case leveraged the gRPC protocol over H2C, effectively bypassing several security layers to deploy the SRBMiner cryptominer on the Docker host and mine XRP cryptocurrency illicitly.
To safeguard development environments from attacks targeting containers and hosts, we recommend that organizations relying on Docker adopt the following best practices:
- Containers and APIs should always be properly configured to minimize the chance of exploitative attacks. Docker provides guidelines on how their users can strengthen their security.
- Running containers should not be run with root privileges, but rather as application users instead.
- Containers should be configured so that access is granted only to trusted sources, such as the internal network.
- Organizations should adhere to recommended best practices. For example, Docker provides a comprehensive list of best practices and has built-in security features users can follow to improve the security of their cloud environments.
- Security audits should be performed at regular intervals to check for any suspicious containers and images.
Trend Micro also offers the following security solutions for safeguarding Docker servers:
- Trend Vision One™ – Container Security - for automated container image and registry scanning that helps detect threats early on
- Trend Cloud One™ – Workload Security - for protecting new and existing workloads against even unknown threats using techniques such as machine learning and virtual patching
Trend Micro Vision One Threat Intelligence
To stay ahead of evolving threats, Trend Micro customers can access a range of Intelligence Reports and Threat Insights within Trend Micro Vision One. Threat Insights helps customers stay ahead of cyber threats before they happen and better prepared for emerging threats. It offers comprehensive information on threat actors, their malicious activities, and the techniques they use. By leveraging this intelligence, customers can take proactive steps to protect their environments, mitigate risks, and respond effectively to threats.
Trend Micro Vision One Intelligence Reports App [IOC Sweeping]
Using gRPC and HTTP/2 for Crypto Miner Deployment
Trend Micro Vision One Threat Insights App
Emerging Threats: Using gRPC and HTTP/2 for Cryptominer Deployment: An Unconventional Approach
Hunting Queries
Trend Micro Vision One Search App
Trend Micro Vision One Customers can use the Search App to match or hunt the malicious indicators mentioned in this blog post with data in their environment.
SBRMiner C&C Connections:
eventId:3 AND ("src:59.93.45.16*" OR "dst:59.93.45.16*" OR "src:167.71.194.227:3333" OR "dst:167.71.194.227:3333")
More hunting queries are available for Vision One customers with Threat Insights Entitlement enabled.
Indicators of Compromise (IOCs)
Hashes
| SHA256 | Detection |
| 0d4eb69b551cb538a9a4c46f7b57906a47bcabb8ef8a5d245584fbba09fc5084 | PUA.Linux.SRBMine.A/277100 |
URLs
- https://github[.]com/doktor83/SRBMiner-Multi/releases/download/2.5.8/SRBMiner-Multi-2-5-8-Linux.tar.g
- 167[.]71[.]194[.]227:3333
- 59[.]93[.]45[.]16
MITRE ATT&CK Techniques
| Tactic | Technique | Technique ID |
| Initial Access | Exploit Public-Facing Application | T1190 |
| External Remote Services | T1133 | |
| Execution | Deploy Container | T1610 |
| Command and Control | Ingress Tool Transfer | T1105 |
| Application Layer Protocol: Web Protocols | T1071.001 | |
| Impact | Resource Hijacking | T1496 |
| Discovery | System Network Configuration Discovery: Internet Connection Discovery | T1016.001 |