Bitcoins, Blockchains, and Botnets
Executive summary
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.
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. In this post, we examine how this data is used by their campaign to help distribute their malware, ensure persistence, and likely serve as an uncensorable defense against take-down efforts, as well as the concerning implications of these findings.
The infection
The infection starts with the exploitation of a Remote Code Execution (RCE) vulnerability. The payload delivered causes the vulnerable machine to download and execute a malicious shell-script. Akamai SIRT traced a variety of these scripts, captured by our honeypots, back to a handful of known publicly disclosed RCE vulnerabilities in Hadoop Yarn, Elasticsearch (CVE-2015-1427), and ThinkPHP (CVE-2019-9082).
We estimate the operators of this campaign have mined well over $30,000 in Monero to public pools over the past three years. In that time, multiple variations have been identified, with different techniques and tools being used by operators as the campaign has matured. In older campaigns, the shell script itself handled the key functions of infection. The stand-alone script disabled security features, killed off competing infections, established persistence, and in some cases, continued infection attempts across networks found within the known_hosts files.
Newer instances of the shell script are written with far fewer lines of code, and a move to binary payloads for handling more system interactions, like killing off competition, disabling security features, modifying SSH keys, downloading, and starting the miners. If readers would like a deeper dive into the underlying capabilities and components of this infection, Trend Micro published a great technical write-up on the topic.
Takedowns & setbacks
Takedowns are nearly inevitable for a campaign this noisy and prolonged. The operators running the campaign understand this and have planned accordingly.
This campaign uses cron jobs and rootkits for persistence and updates to distribution, ensuring infected machines will regularly check-in and be re-infected 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.
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 late December 2020, we detected the presence of a Bitcoin wallet address being included in newer variants of this malware, a URL for a wallet checking API, and a cryptic series of nested bash one-liners. In examining these additions further, it became clear the wallet data being fetched from the API was being used to calculate an IP address. This IP is then used for persistence and additional infection operations.
This is a very clever and strategic technique. It enables the operators to stash obfuscated configuration data on the blockchain. By pushing a small amount of BTC into the wallet, they can recover infected systems that have been orphaned. They essentially have devised a method of distributing configuration information in a medium that is effectively unseizable and uncensorable. Using this method, the operators of the campaign have turned potential offensive actions against their infrastructure from a serious disruption, to something that can be recovered from quickly and easily.
During our research into the latest evolution of this campaign, the Chinese Ministry of Industry and Information Technology actively seized the very domain (*.powreofwish.com) we were looking into.
Fig. 1 Active sinkholing of the C2 domain by the Chinese government
BTC/IP conversions
To convert the Bitcoin transactions into an IP address, the script first needs to know what transactions the wallet has sent and received. The operators achieve this by doing a simple HTTP request to a blockchain explorer API (api.blockcypher.com) for the last two transactions for the given wallet address, then converting the Satoshi values of these transactions into the backup C2 IP address.
Fig. 2 Bash script snippet of the Satoshis to C2 IP conversion
Essentially, the infection is using the wallet address as a DNS like record, and the transaction values as a type of A record. In Fig. 2, 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. To achieve this conversion, four nested Bash one-liners (one each, per-octet) are concatenated together. While the mess of cURLs, seds, awks, and pipes is hard to make sense of at first glance, it's a fairly simple technique. To make the process a bit easier to read and to help defenders better understand such operations, here is the same process implemented in Python.
Fig. 3 Simplified Satoshis to C2 IP conversion script
The nitty-gritty conversion details
The Satoshis to C2 IP conversion process starts with an API request to fetch the two most recent transactions on the wallet. The API query results, at the time of this writing, are shown in Fig. 4.
Fig. 4 The API query returns the latest 2 transactions on the wallet
A single transaction value is used to represent two octets of the IP address, meaning that transaction 1 (most recent) contains the 3rd and 4th octets, and transaction 2 (most recent+1) contains the 1st and 2nd octets of the final C2 IP address.
Knowing this, let's look at the values of these transactions and convert them into IP address octets. The most recent transaction has a value of 6,957 Satoshis, converting this integer value into its hexadecimal representation results in the value 0x1b2d. Taking the first byte (0x1b) and converting it into an integer results in the number 45 -- this will be the 3rd octet of our final IP address. Taking the second byte (0x2d) and converting it into an integer results in the number 27, which will become the 4th octet in our final IP address.
The same process is done with the second transaction to obtain the first and second octets of the C2 IP address. In this case, the value of the second transaction is 36,305 Satoshis. This value converted to its hexadecimal representation results in the hex value of 0x8dd1. The first byte (0x8d), and the second byte (0xd1), are then converted into integers. This results in the decimal numbers 141 and 209 which are the second and first octets of the C2 IP address respectively. Putting the four generated octets together in their respective order results in the final C2 IP address of 209.141.45.27.
Fig. 5 Representation of the satoshis to C2 IP conversion process
How it's used
The resulting IP address served as a backup piece of infrastructure throughout this campaign in recent months. Initially, the IP address was generated, but only used if the primary server timed out or responded with any HTTP status code, besides 200 or 405, during the infection process. The reinfection process, in these cases, relied on the crontab to execute the /etc/newdat.sh script every half hour, thus testing the primary, and in case of failure, the backup C2 for fetching the latest malware builds. This means that recovery could be achieved in roughly 30 minutes.
In more recent campaigns, the RCE isn't being leveraged for kicking off mining, killing off competitors, or even compromising the machine itself. The RCE has been modified to create a Redis scanning and compromising bot. The same wallet and technique are used, but they're used to craft a series of commands that are launched against Redis servers with weak passwords. This, in turn, converts the Redis servers into miners and scanners as well.
Not just for mining as of late
The Redis scanning and infection campaign first begins by building a file named .dat, which the script fills with a series of Redis commands. It then modifies the Redis commands file, replacing all occurrences of localhost with the C2 IP address using sed -i "s/localhost/$cc/g" .dat, where $cc is a variable that contains the C2 IP address that was generated using the Bitcoin wallet transactions.
Fig. 6 .dat file being build and modified
Fig. 7 The modified .dat file with the C2 IP address in place
Once the .dat file is set up and ready for distribution, the machine is instructed to begin scanning networks using pnscan and masscan for TCP/6379 (Redis). These scans also target LAN IP address ranges and move laterally into Redis servers across the local network that may not be Internet-accessible. When the script identifies a host it thinks is running Redis, it attempts a series of connections using the redis-cli tool with weak passwords. If it successfully authenticates, it proceeds to cause Redis to write configuration files to disk in /var/spool/cron/root and /var/spool/cron/crontabs that will ultimately get picked up and run by the local cron daemon on the remote machine, thus establishing its foothold.
Fig. 8 Scanning for Redis servers on LAN, brute-forcing them, and injecting cron jobs
Disrupting operations
It's likely the operators here used a public wallet that appears to be part of a coinjoin/tumbling service (money laundering/improved anonymity) that sees very large bursts of activity to and from multiple other wallets (some containing over $1 million in funds). This is likely by design, to obfuscate transactions and identity/ownership of the respective wallets and to blend in with the noise.
This technique opens up the potential for disruption campaigns. Because they're using the two newest transactions seen in a wallet that anyone can send funds to (likely because they don't control the wallet), sending values to the wallet causes their system to start generating invalid IP addresses.
If a single transaction for a single Satoshi is sent to the wallet, the single Satoshi is processed and results in a mangled IP address of 45.27..1. This mangled IP address will be recognized as an attempt to resolve an (invalid) domain name and kill attempts to successfully fetch infection payloads.
This type of disruption can be recovered from by the operators by simply sending two more transactions to the wallet. However, it's important we realize the cost involved. Without accounting for transaction fees, the raw cost of a disruption is 1 Satoshi, about $0.0004. This means for $1 about 2,500 disruption transactions can be placed in the wallet. In the case of the current IP address, the Satoshi values that must be sent to the wallet by the operators to recover control total 43,262 Satoshis, or about $16.50. The quick math at current market prices for BTC suggests that for every $1 spent on disruption, the operators will need to spend over $41,000 ($16.50*2,500) to recover their operations and get the orphaned infected systems back to their (current) IP address. These amounts will fluctuate along with the price of Bitcoin and the IP address that needs encoding, but it will always work in favor of the disruptor over the operator.
Sinkholing operations
Knowing what we know, it's possible to figure out what values need to be sent to the wallet in order to cause new infections to calculate a new C2 IP address that we control.
Using a script written by Akamai SIRT (encoder.py), the example Fig. 9 explains how a defender could direct infections to an IP address under their control. In this example, we're using 172.27.166.86.
The script encodes any IP address into the proper BTC values that can then be sent to the wallet using two transactions in order to sinkhole the botnet. Sending these values to the wallet will cause new infections to calculate the IP address we provided and use it as their new C2 IP address.
Fig. 9 The encoder.py source code
Fig. 10 The two BTC transaction values after encoding the IP address
In the above example, encoding the IP address 172.27.166.86 results in two BTC values, 0.00007084 and 0.00022182. If these values were sent to the wallet, newly (re)infected machines would decode their C2 IP address into 172.27.166.86 instead of the original C2 IP address of the operators.
To verify this, we will attempt to decode the two BTC values we got from encoding our IP address and will end up with 172.27.166.86 as expected. The decoder.py script is shown below. It takes in the two BTC transaction values as arguments, decodes them, and outputs a C2 IP address.
Fig. 11 The decoder.py takes in the 2nd transaction value in Satoshi as the first argument and the 1st transaction value in Satoshi as the second argument. It then decodes these values into the C2 IP address that would be calculated by the malware
Fig. 12 The Satoshi values were successfully decoded back to the original ip address we provided to the encode.py script
The decoder.py script was able to decode the BTC values into the IP address that we control, indicating what would be a successful sinkhole of the botnet. The overall cost of this action costs the defender 29,266 Satoshis which is about $11.15 at market price as of this writing. The price once again fluctuates based on the IP address used; for example, pointing the IP address to 255.255.255.255 would cost about (65535*2 Satoshis) $50.
Sinkholing, simpified
As highlighted previously, the backup C2 IP address is only leveraged when the primary C2 fails to establish a connection or receives HTTP status codes besides 200 or 405. If sinkhole operators successfully sinkhole the primary infrastructure for these infections, they only need to respond with a 200 status code for all incoming requests to prevent the existing infection from failing over to using the BTC backup IP address.
Closing
This campaign uses a previously unseen means of effectively hiding its infrastructure configuration details on the Bitcoin blockchain. The technique of fetching real-time data from a decentralized and essentially uncensorable data source to generate a C2 IP address makes the infection difficult to take down and makes pivoting the C2 IP address simple and fast.
This discovery and technique have serious implications for tracking, defending against, and taking down botnets by researchers, infrastructure operators, and law enforcement. Seizing domains, taking over servers, and sinkholing active infections could prove to be very difficult.
The technique isn't perfect. There are improvements that can be made, which we've excluded from this write-up 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.
To ensure your system has not been compromised by this campaign, refer to the IoC section below and check your infrastructure against the IoCs provided.
IOC'S for this infection
BTC Wallet
1Hf2CKoVDyPj7dNn3vgTeFMgDqVvbVNZQq
SSH keys injected into /root/.ssh/authorized_keys:
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC9WKiJ7yQ6HcafmwzDMv1RKxPdJI/oeXUWDNW1MrWiQNvKeSeSSdZ6NaYVqfSJgXUSgiQbktTo8Fhv43R9FWDvVhSrwPoFBz9SAfgO06jc0M2kGVNS9J2sLJdUB9u1KxY5IOzqG4QTgZ6LP2UUWLG7TGMpkbK7z6G8HAZx7u3l5+Vc82dKtI0zb/ohYSBb7pK/2QFeVa22L+4IDrEXmlv3mOvyH5DwCh3HcHjtDPrAhFqGVyFZBsRZbQVlrPfsxXH2bOLc1PMrK1oG8dyk8gY8m4iZfr9ZDGxs4gAqdWtBQNIN8cvz4SI+Jv9fvayMH7f+Kl2yXiHN5oD9BVTkdIWX root@u17
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDQtnEBuyv0ZtwDsy01cvXjj/4oawDXu1rCHqStPj0CrRoxk1Vr9d/kq2RjQQ81LUVKGcqoa+hNrqxjQvipt3BI2UEvQQCx9Ic4LQmFJM24Ydar8bnJj/u6Q17LUgluZ8tyioCTDth6fVcqMnV3QZnvulHHSpgP+TOq8giCyDCCeNeGJGoZi4BG7ow/s2a81FHCbvgHUC1dEpJ49/7ssodZ3mbbqwfybmqZ6gflOJk6BtfI5kKm4XJSsY46UXizuJj9zdDdbJBNKR+tjvn5X+FnvoDnCsCyKlH9/tBhQS7tvHORV5TenIRiEKp0ijCcDoz8DfpaLs2U520yPxI1YGqL root@gengine
Files (hashes) *
b5a9c7bd8fdb2b6e5c4431a90b83010f (crypto miner)
c5147da98446cae3648fcce55b4d26b7 (crypto miner)
31ccae78b56a9dae3a316dd389963647 (trojan)
e5bf1033e289cb643d81aebae8dda30d (trojan)
1b849002406d6370754c45c6b3a41e9a (btc variant shellscript)
0ff358d012ccbb5b6820b800291d5a7f (btc variant shellscript)
bff33617e1d7faea78315521c640c240 (btc variant shellscript)
69632cecca6ec207e0b0183d37ee6a37 (btc variant shellscript)
9578142d2cc12bd73d064fa1d71db63e (btc variant shellscript)
7be2526bdc463799c823320e03b196db (btc variant shellscript)
45f7ffff8a0f519eae996beb9b98b28f (btc variant shellscript)
4d9a348877a07c2052639dc7eb6fbd03 (btc variant shellscript)
1eba0ab788c06544b8d38f6202cb615e (btc variant shellscript)
3e5a3b049766f3fe760febb7b283a8c8 (btc variant shellscript)
80e5da0733fbee1ff0527b383a33df0b (btc variant shellscript)
8bc9a07be534c90e4c7079c1a271631e (btc variant shellscript)
0efcc74b2361a0150db2db9534e633fd (btc variant shellscript)
46c6bbc5e97a4bb4d44671dc1c5265a7 (btc variant shellscript)
b543049bef613f3d292df5a842f04ad5 (btc variant shellscript)
0456f373bafc25e314a579738a844dec (btc variant shellscript)
c8bb80a13f2be0ee53f1b185312afc6d (btc variant shellscript)
7d62cbcfa32091746570903c83463b8b (btc variant shellscript)
cbdc3a5c3a3c4bca9d4f71b2f5a285ee (btc variant shellscript)
5cd9dce73199cf40f77369af7cc416f3 (btc variant shellscript)
a834d5c1ed5fe10a137c19933449ff3d (non-btc variant shellscript)
cd8d2111de264ecd88cf4fc7d20d77c6 (non-btc variant shellscript)
0d415c5b046b2426f9d719cda4b28a43 (non-btc variant shellscript)
97da8c3e63de45400e7b4ac4225e0506 (non-btc variant shellscript)
7a987e37b4db64eb86c36f022aa0a678 (non-btc variant shellscript)
92eb6d40d72250e241ab04d450bf0f94 (non-btc variant shellscript)
9307fe8a3e37fd4387451bb1fd926562 (non-btc variant shellscript)
90b484eac57bec8de09790325b01d5c5 (non-btc variant shellscript)
c3600c53a013cb2e412ec885afc51c56 (non-btc variant shellscript)
0289c2eea4cb2c23579995f61fec1395 (non-btc variant shellscript)
a6fee74a88dbc7c2b1ef3bf86b91df61 (non-btc variant shellscript)
9c0220960cdc31aab358673ffb207474 (non-btc variant shellscript)
b0fdb6b447d83558321c7da3d514a42f (non-btc variant shellscript)
6baddab01039ed7e11306def855096e3 (non-btc variant shellscript)
24bb4e4da5b29bd91c4b3cb00940f9f9 (non-btc variant shellscript)
cb4c890a14596f18feaf02c5aa52adaa (non-btc variant shellscript)
304b50b2c3c7b0af367c0aa393739d7d (non-btc variant shellscript)
7ab7f6bac22b94a422b5fd7a45c54419 (non-btc variant shellscript)
da0e7657415ce43e6f4dc1cc77b4364f (non-btc variant shellscript)
117ec298f84891015035040eec4cae2a (non-btc variant shellscript)
e816431cfd1ddddcee24d03c607e29cc (non-btc variant shellscript)
8fd76759af09b08e2ba7f069394b3033 (non-btc variant shellscript)
88939ff4ac085190fbf4c5551c25818e (non-btc variant shellscript)
82b0c43595dcaa705ca99e55ae2fae1d (non-btc variant shellscript)
7145dd649a253b18a1364970b197683c (non-btc variant shellscript)
41e85e86314dd8783e514b253e766c1b (non-btc variant shellscript)
3aa3f7aadb67e6166a8568ed5b3770a1 (non-btc variant shellscript)
d6ee2f5a2626a28dafe76668b194e35b (non-btc variant shellscript)
e7becff8d9b3b0837ee72b0832a0efef (non-btc variant shellscript)
c20e6aff7e0923b555f7107d11ad88b5 (non-btc variant shellscript)
7ff6507f3ea4cc5a2f7f4dd4a5ce237f (non-btc variant shellscript)
e2121f6135b56035ae2ecb1bebfabe30 (non-btc variant shellscript)
fbb3b04357255ebcc2017a934a8e0322 (non-btc variant shellscript)
067e118631c5fd5ab8dffa9dc47cc7cc (non-btc variant shellscript)
83f2d29ea6109937b4a31641aa66ca81 (non-btc variant shellscript)
84c0282bfce8d4216481611974eac069 (non-btc variant shellscript)
6a4425696366569d0d6b633bc2990ff4 (non-btc variant shellscript)
7ad04e295ae48d19bb5cd0b62cf7b3b2 (non-btc variant shellscript)
a64185d58605258732ceec1c6cf59415 (non-btc variant shellscript)
76f284f18ec381825a435dd910a80843 (non-btc variant shellscript)
42713d8cb562e8102cc472809a1acd6b (non-btc variant shellscript)
b4480777a746423fa642476f90c7e3be (non-btc variant shellscript)
147546e8dc13d1d358b77fc8148f5d50 (non-btc variant shellscript)
fd1935ac43e7b8c1a8b0d4f732936f54 (non-btc variant shellscript)
ee63606d7cff9b05433a50adf65c1ef5 (non-btc variant shellscript)
085a78c69b680a9f0650352c34d0af44 (non-btc variant shellscript)
ae0d088614f798112b39151de625f096 (non-btc variant shellscript)
bffa1d8cd3a8de0c7b2e8a5b7cc49b53 (non-btc variant shellscript)
9a1be8accad9f965b03902a42b94ce77 (non-btc variant shellscript)
32d339db4b18dd98459128cb71542c5a (non-btc variant shellscript)
816d6520176c908dabe930ea8071cf64 (non-btc variant shellscript)
9786e509a83ebca4ae38a9485528a0be (non-btc variant shellscript)
59a92952dfa09ff62d19b42918621fc2 (non-btc variant shellscript)
a791500d17bf92aaaa521401a6c54bde (non-btc variant shellscript)
f81a15bd10425a309c74c4ba4522b95c (non-btc variant shellscript)
25beb7598a49f6d74b150ce94def32b1 (non-btc variant shellscript)
8e300a5d1409a7079328f7af2f85069b (non-btc variant shellscript)
070676495e2f2f3fd94838a2db55df02 (non-btc variant shellscript)
fd65e8902672386504351e66f61f761a (non-btc variant shellscript)
25114bb9366b16c405c6e4cd6f163c0f (non-btc variant shellscript)
abb97af91c8e6eaa46f277da0eb159da (non-btc variant shellscript)
0af1a6bd7106237ea9f13335626f9549 (non-btc variant shellscript)
60341dddb61fda6a199f2a922936a0b0 (non-btc variant shellscript)
65f8d9b11e67fd93932eb8c551fe2a98 (non-btc variant shellscript)
c396e1eb65e2fcc50d057fe6564d0efd (non-btc variant shellscript)
245b05b00761b80de06b8fd78ed5a094 (non-btc variant shellscript)
efc1dde53119a063e73c8924fc133666 (non-btc variant shellscript)
6f60766b2bd7c1747bb75b10a6a9f58c (non-btc variant shellscript)
94e5be1877d85ee01bd092c73315ea50 (non-btc variant shellscript)
67dec55db346cee8ff541bd4d10ab032 (non-btc variant shellscript)
3af4b0e86f1c107591710f0cdb200998 (non-btc variant shellscript)
e21df0948431ff9621efb47e6806f367 (non-btc variant shellscript)
6775dc6438d66a8ba5553efaf9949b1d (non-btc variant shellscript)
1a241d1f61c2c44a6f09f76ebee23759 (non-btc variant shellscript)
9b661b9bef2d970336bb72f152532c37 (non-btc variant shellscript)
e19a028290147489db3b36eeed380efe (non-btc variant shellscript)
233cea3edc710c21d44134050da9c6d2 (non-btc variant shellscript)
40b6cfdc99f003566d01c2154cb684bb (non-btc variant shellscript)
34fa8ef7ea3e0a38cb725ec6b5d88882 (non-btc variant shellscript)
798ad37b48014a1191c0758f739be5ce (non-btc variant shellscript)
5372fe641200fa6c707711394797a832 (non-btc variant shellscript)
787da2011f4f664a9a4ff83208ea5913 (non-btc variant shellscript)
e8e4e31151df03ea02d285a71a9b09e0 (non-btc variant shellscript)
793ddf6170a6b649b6e4d2ac2385c563 (non-btc variant shellscript)
dd160c9f89f52a47c0df04df19307c7e (non-btc variant shellscript)
965e827ab4229f132cf4284de739f9ee (non-btc variant shellscript)
a5687c9d25e4755820c16a4ba0701474 (non-btc variant shellscript)
48e69a7ed1516d884e83421e5b7755ff (non-btc variant shellscript)
179fd51fe6b061e8b54b0f3ca2e8bd26 (non-btc variant shellscript)
1d461c5afe941f54b4edb655c4214385 (non-btc variant shellscript)
f4e9c8ecbd857c392d3f8f7bf5c8b3b1 (non-btc variant shellscript)
31a4bf622df54ce81ed3ffd3b64d727e (non-btc variant shellscript)
3112fb090700ed03755ffc84f552080a (non-btc variant shellscript)
3a77903e5409859afd0a9df4ca180f13 (non-btc variant shellscript)
2f3c29f18b5437f8c2f2b246ec9632bb (non-btc variant shellscript)
73b5a80f94a0ab1a4b4f453dc40eca02 (non-btc variant shellscript)
b689ee49d8e51b54d3d3c5c04d7d1a91 (non-btc variant shellscript)
75e1d7a73cdc62dc277695aa516188cd (non-btc variant shellscript)
1dad9513da6e1be3f5aa4af1c768bd1c (non-btc variant shellscript)
dd89a470acbd707e73050d6739f2b5e2 (non-btc variant shellscript)
0eb2392e6ea0097fc4922a8b66145e5f (non-btc variant shellscript)
28f296bbc23ac31eb147821c0f481c1f (non-btc variant shellscript)
d226685b6a3dbffff4131adbaf8969e1 (non-btc variant shellscript)
811c9d48ca06911014952ed4490e8b9c (non-btc variant shellscript)
a73763c8b4c295cfba065586514a127c (non-btc variant shellscript)
1faac0a71d6e3dca0225e6349ba02dd1 (non-btc variant shellscript)
4cc8f97c2bf9cbabb2c2be292886212a (non-btc variant shellscript)
5c020577abe1fc601a01a4baa649e041 (non-btc variant shellscript)
98efa1f0c025f049db58a4224c948de0 (non-btc variant shellscript)
d80ed52c77088b93a9208f16bb84c3a9 (non-btc variant shellscript)
c956115127200e06c3daa0265d05299b (non-btc variant shellscript)
f3271b1a28d443b13c63bcd067f248bd (non-btc variant shellscript)
f5844389e796391d0c2ac6fa3a3827cc (non-btc variant shellscript)
ec77f4fde27bda1adc8cbc1a102e5eaf (non-btc variant shellscript)
edc7a8e3fb23be835b6e67e4f44bc183 (non-btc variant shellscript)
838fd860c14ba296e8f45b1d983e4882 (non-btc variant shellscript)
daec95f4af9da8969c89cf4a94a791ac (non-btc variant shellscript)
dc607c2952efd47f78b3edd8743e402d (non-btc variant shellscript)
14a2564694edcde963fa23dcea9c4f66 (non-btc variant shellscript)
4eae06207313f0d8baf89bf3a09e438d (non-btc variant shellscript)
0d45428758e61759f2ae0d0b8adcfb0c (non-btc variant shellscript)
7979081df6b8ebaa46ce838f66de14a6 (non-btc variant shellscript)
92979a11f63f2965dd52dc2eaaed9340 (non-btc variant shellscript)
66d0830a46fdb045e0f7edefa6fb5894 (non-btc variant shellscript)
33a36319355dcc874b859dea91c93870 (non-btc variant shellscript)
5ae9e77a3b809caf17f674f58b0bc264 (non-btc variant shellscript)
a8aa7dc51d85e733475d9434484cdfad (non-btc variant shellscript)
ec2a7b782ee1b176217ad2754b2b7568 (non-btc variant shellscript)
86ef8c2656981f0da6c8f388f23ab4b2 (non-btc variant shellscript)
5ccb07aef75f220f7513d9205ffdc614 (non-btc variant shellscript)
* note: due to connectivity issues with C2 infrastructure, several partially fetched shell scripts linked to this campaign ended up in honeypots. We have included these partial scripts in the IoC hashes list, as they could lead to partial compromise, even if they won't match against full infection payloads. These hashes also include older versions of the non-BTC variants.
Network
209.141.45.27 (malware hosting)
89.203.251.220 (malware hosting)
139.199.171.45 (malware hosting)
185.181.10.234 (malware hosting)
146.71.79.230 (malware hosting)
176.123.7.127 (malware hosting)
103.125.218.107 (malware hosting)
146.71.79.230 (malware hosting)
176.123.7.127 (malware hosting)
185.247.117.64 (malware hosting)
45.9.148.37 (malware hosting)
93.115.23.117 (malware hosting)
*.powreofwish.com (malware hosting)
*.powerofwish.com (malware hosting)
*.epelcdn.com (malware hosting)
*.hearme.xyz (malware hosting)
global.bitmex.com.de (malware hosting)**
https://api.blockcypher.com/v1/btc/main/addrs/{BTC wallet here}?limit=2
update.aegis.aliyun.com (not malicious, used to disable/uninstall security tools)
pooltosugar.isaid.xyz:3366 (crypto mining)
sugar.ss.dxpool.com:3366 (crypto mining)
stratum-eu.rplant.xyz:7042 (crypto mining)
stratum-asia.rplant.xyz:7042 (crypto mining)
stratum-ru.rplant.xyz:7042 (crypto mining)
** global.bitmex.com.de does not appear to be affiliated with the cryptocurrency exchange bitmex.com
Filesystem
/root/.ssh/authorized_keys (created and/or modified)
/usr/bin/cdt (relocated curl)
/usr/bin/wdt (relocated wget)
/bin/t (relocated chattr)
/usr/bin/wget (missing)
/usr/bin/curl (missing)
/usr/bin/chattr (missing)
/tmp/phpupdate
/tmp/networkmanager
/tmp/newdat.sh
/tmp/config.json
/etc/phpupdate
/etc/networkmanager
/etc/newdat.sh
/etc/config.json
