A Cryptomining botnet abuses Bitcoin blockchain transactions as C2 backup mechanism
Vulnerabilities mentionedAll →
| CVE | Vulnerability | CVSS | EPSS | Flags | Affected | Exposure | Published |
|---|---|---|---|---|---|---|---|
| CVE-2015-1427 | Sandbox Bypass RCE in Elasticsearch Groovy Scripting Engine The Groovy scripting engine used by Elasticsearch for dynamic scripts (script fields, script-based sorting and queries) fails to properly confine user-supplied Groovy code, allowing a crafted script to escape the sandbox (CWE-284, improper access control) and invoke Java APIs such as Runtime to run arbitrary shell commands on the server. It is triggered remotely when an attacker who can reach the Elasticsearch HTTP API submits a malicious dynamic script (e.g., via the _search endpoint) on instances with dynamic scripting enabled. A successful attacker gains arbitrary command execution on the host running Elasticsearch, which can lead to full server compromise and follow-on activity such as malware or ransomware deployment. Affected deployments are Elasticsearch prior to 1.3.8 and 1.4.x prior to 1.4.3 (per public advisory records; the CISA source data lists no explicit version range), with fixes shipped in 1.3.8 and 1.4.3. The flaw is confirmed exploited in the wild — CISA added it to the KEV catalog on 2022-03-25 with ransomware use unknown — and EPSS ranks it in the 100th percentile (99.9% probability of exploitation within 30 days), though no public PoC is listed in the source data. Do: Upgrade Elasticsearch to 1.3.8 (1.3.x) or 1.4.3 (1.4.x) or later, consistent with CISA's required action to apply updates per vendor instructions; as an interim mitigation, disable dynamic Groovy scripting (script.dynamic: false) and restrict port 9200 to trusted networks. Inventory internet-exposed instances (Shodan/Censys on port 9200), verify installed versions via the cluster's root endpoint, and hunt for signs of command execution such as unexpected processes, new cron/systemd entries, or outbound connections from Elasticsearch hosts. | — | 100% | KEV |
| mass≈100,000+ internet-exposed Elasticsearch instances (order of magnitude 100k, from public internet-wide scans) | |
| CVE-2019-9082 | Unauthenticated RCE in ThinkPHP < 3.2.4 (Open Source BMS, ZzzCMS zzzphp) CVE-2019-9082 is an unauthenticated remote code execution flaw (CWE-94 code injection, CWE-306 missing authentication) in ThinkPHP versions before 3.2.4, as shipped in Open Source BMS v1.1.1 and other ThinkPHP-based products. An attacker triggers it by sending a crafted HTTP GET request to the route public/?s=index/\think\app/invokefunction&function=call_user_func_array&vars[0]=system&vars[1][]=<command>, which makes the framework invoke the system function with attacker-controlled arguments. Because no authentication is required, any remote attacker who can reach the web application can execute arbitrary operating-system commands with the privileges of the web server, typically gaining a foothold for data theft, ransomware, or botnet/cryptomining implants. Affected users are operators of ThinkPHP-based sites and applications, specifically ThinkPHP prior to 3.2.4, Open Source BMS v1.1.1, and ZzzCMS zzzphp as listed by CISA. Exploitation is confirmed in the wild: the flaw is in CISA KEV (added 2021-11-03), has a 97.4% EPSS probability of exploitation within 30 days, and threat-actor activity against old ThinkPHP flaws — including a Chinese threat actor since October 2023 and the DirtyMoe wormable botnet — keeps pressure on unpatched servers. Do: Upgrade ThinkPHP to version 3.2.4 or later (or a currently supported maintained branch) and update Open Source BMS beyond v1.1.1 and zzzphp to vendor-patched releases, per CISA's required action. Check access logs for requests to the invokefunction route (public/?s=index/\think\app/invokefunction with call_user_func_array/system) and hunt for signs of follow-on webshell, botnet, or cryptomining activity, given active abuse by Chinese-linked actors and the DirtyMoe botnet. As interim mitigation, block or restrict the invokefunction route at a WAF/reverse proxy for unauthenticated users; remediation is mandatory under BOD 22-01 because the flaw is in KEV. | 8.8 | 97% | KEV PoC ×3 |
| massOn the order of hundreds of thousands of internet-exposed ThinkPHP instances, plus additional downstream Open Source BMS and zzzphp deployments |
Full article641 words · extracted from securityaffairs.com · click to collapse
Pierluigi Paganini
February 24, 2021
Crooks are exploiting BTC blockchain transactions to hide backup command-and-control (C2) server addresses for a cryptomining botnet.
Security experts from Akamai have spotted a new botnet used for illicit cryptocurrency mining activities that are abusing Bitcoin (BTC) transactions to implement a backup mechanism for C2.
This technique allows botnet operators to make their infrastructure resilient to takedown conducted by law enforcement.
“A recent piece of malware from a known crypto mining botnet campaign has started leveraging Bitcoin blockchain transactions in order to hide its backup C2 IP address. It’s a simple, yet effective, way to defeat takedown attempts.” reads the post published by Akamai. “Recent infection attempts against Akamai SIRT’s custom honeypots uncovered an interesting means of obfuscating command and control (C2) infrastructure information. The operators of a long-running crypto-mining botnet campaign began creatively disguising their backup C2 IP address on the Bitcoin blockchain.”
The infection chain begins the exploitation of a Remote Code Execution (RCE) vulnerabilities affecting Hadoop Yarn, Elasticsearch (CVE-2015-1427), and ThinkPHP (CVE-2019-9082).
Botnet operators used Redis server scanners to find installs that could be compromised to mine cryptocurrencies.
The experts estimated that botnet operators have mined more than $30,000 in Monero in public pools since 2018. Experts identified multiple variants over the time, using different techniques and tools.
The older versions were using a shell script to carry out the main functions, such as disabling security features, killing off competing infections, establishing persistence, and in some cases, propagating within the compromised network.
Newer variants of the shell script leverage binary payloads for handling more system interactions, like killing off competition, disabling security features, modifying SSH keys, downloading, and starting the miners.
Botnet operators use cron jobs and rootkits to achieve persistence and re-infect with the latest version of the malware.
“These methods rely on domains and static IP addresses written into crontabs and configurations. Predictably these domains and IP addresses get identified, burned, and/or seized. The operators of this campaign expected this and included backup infrastructure where infections could fail over and download an updated infection that would, in turn, update the infected machine to use new domains and infrastructure.” continues the report.
“While this technique works, a coordinated takedown effort that targets domains and failover IP address/infrastructure all at once could effectively cut the operators out of maintaining their foothold on infected systems.”
In December 2020, the researchers discovered a BTC wallet address that was included in new variants of the miner, along with an URL for a wallet-checking API and bash one-liners. The experts discovered that the wallet data were being fetched by the API and used to calculate an IP address used to maintain persistence.
By fetching addresses via the wallet API, botnet operators are able to obfuscate and backup configuration data on the blockchain.
Experts noticed that by pushing a small amount of BTC into the wallet, operators can recover infected systems that have been orphaned.
“Essentially, the infection is using the wallet address as a DNS like record, and the transaction values as a type of A record. the variable aa contains the Bitcoin wallet address, variable bb contains the API endpoint that returns the latest two transactions used to generate the IP address, and variable cc contains the final C2 IP address after the conversion process is completed.” continues the report. “To achieve this conversion, four nested Bash one-liners (one each, per-octet) are concatenated together.”
Experts believe the technique can be improved to avoid providing pointers and feedback to the botnet developers.
“Adoption of this technique could be very problematic, and it will likely gain popularity in the near future.” concludes the report.
If you want to receive the weekly Security Affairs Newsletter for free subscribe here.
| [adrotate banner=”9″] | [adrotate banner=”12″] |
(SecurityAffairs – hacking, botnet)
[adrotate banner=”5″]
[adrotate banner=”13″]
Text extracted automatically; images, tables and formatting may be missing. Original: https://securityaffairs.com/114984/cyber-crime/bitcoin-blockchain-botnet.html