Threat actors are increasingly leveraging blockchain technology to launch cyberattacks. By taking advantage of the distributed and decentralized nature of blockchain, malicious actors can exploit its anonymity for a variety of attacks, ranging from malware propagation to ransomware distribution.
The Glupteba trojan is an example of a threat actor leveraging blockchain-based technologies to carry out their malicious activity. In this blog, Nozomi Networks Lab presents our latest findings on Glupteba and how security teams can search for malicious activity in the blockchain.
What is Glupteba?
Glupteba is a backdoor trojan that is downloaded via Pay-Per-Install networks – online ad campaigns that prompt software or application downloads – in infected installers or software cracks. Once Glupteba is active on a system, the botnet operators can deploy additional modules from the credential stealer to exploit kits compromising devices on the target network. There are several Glupteba modules aimed at exploiting vulnerabilities in various Internet of Things (IoT) appliances from vendors, such as MikroTik and Netgear.
Surprisingly, Glupteba leverages the Bitcoin blockchain to distribute its Command and Control (C2) domains to infected systems. Apart from the fact that this is an uncommon technique, this mechanism is also extremely resilient to takedowns as there is no way to erase nor censor a validated Bitcoin transaction. Using the same approach that Glupteba is using to hide data within the blockchain, researchers can hunt for malicious transactions and recover their payloads. If the said domains are not stored in plaintext, reversing the Glupteba samples enables security researchers to decrypt the payload and access the embedded domains.
Using the Blockchain to Store Data
The Bitcoin blockchain can be used to store arbitrary data. This is made possible by the OP_RETURN opcode that enables storage of up to 80 bytes of arbitrary data within the signature script. This storage mechanism has several advantages. First, it is resilient to takedowns. Once a transaction has been validated, there is no way to erase it – this is the nature of the blockchain. Using this mechanism to distribute C2 domain means that law enforcement officers, network defenders, and incident responders have no way to take down the Bitcoin address and erase the transaction. The way the Bitcoin blockchain is built on top of modern cryptography also makes this mechanism secure; without the Bitcoin address private key, one cannot send a transaction with such a data payload originating from the malicious address, hence, taking over the botnet is not possible. Additionally, threat actors can encrypt their payload from peering eyes, making the data storage scheme robust and cost effective.
This technique has also been used by the Cerber ransomware in the past. Bitcoin transactions originating from specific addresses were monitored and the first 6 characters of a destination address were used along with a .top TLD appended to> generate a domain, which would be used to query the active C2 infrastructure.
Glupteba is known to be using a similar mechanism relying on OP_RETURN instead of destination addresses to distribute its C2 domains. In case of a C2 domain being taken down, the botnet operators only need to send a new transaction from the Bitcoin address distributing the domains and voila, the malware will adjust its configuration the next time the C2 is refreshed. The latest identified Glupteba bitcoin transaction dates to the 8th of November 2022 with its embedded payload 000c0b0006171c11064d150a0b16.
The hexadecimal payload above does not seem to represent anything close to a domain name and that is because Glupteba uses, in its latest variant, a XOR encryption scheme to protect the data. Once the key is known, typically by reverse engineering a sample such as c6d4ce67dd25764f571a84caa19fa6c2b067cae6, decrypting the data becomes simple; see a sample of this decryption in Github.
The Evolution of Glupteba
Glupteba is known to use the Bitcoin blockchain to distribute its C2 servers since at least 2019. To retrieve the Bitcoin transactions, several providers are used, usually blockchain.com and blockstream.info. The Glupteba function responsible for querying blockchain.com to retrieve the transaction data is shown in Figure 1.
The way the domains are protected within the transactions has slightly evolved over time. In 2019, Glupteba used AES-GCM to protect and embed the data in the bitcoin transactions. Each sample was shipped with a hardcoded key and initialization vector enabling the sample to decrypt the payload from the Bitcoin transaction. Figure 2 shows the decryption routine in the oldest Glupteba versions..
In newer versions of the malware, this scheme was switched to a simple XOR cipher, which is currently being used. All samples we found were using the same key: “cheesesauce”. Figure 3 shows this key being moved around in memory in the function responsible to decrypt the ciphertext.
Timeline of Events
Given all that information, we went on a blockchain harvesting tour, scanning the entire Bitcoin blockchain for hidden C2 domains. We tried to decrypt the data payload of the OP_RETURN script present in each transaction of every block using all the algorithms and keys we know to be associated with Glupteba. In addition, we downloaded over 1500 Glupteba samples from VirusTotal and looked at the wallet addresses they used to make sure we did not miss anything. But that is not all: the latest set of TLS certificates Glupteba uses also exhibits a precise pattern in the Subject Alternative Names and, thanks to certificate transparency, this can be hunted for. Finally, we also took a close look at the passive DNS records at our disposal to find potential associated domains and hosts.
This research gave us a massive series of events we decided to summarize with the timeline below, showing when actions were taken by Glupteba operators.
The 4 Glupteba Campaigns
We have been able to identify 15 Glupteba bitcoin addresses spawning over 4 years and what we believe to be 4 different campaigns.
The oldest wave seems to have started in June 2019. Back then, only one single Bitcoin address was used to distribute the malicious domains. This also corroborates what Google found out in their lawsuit against two Glupteba operators.
Figure 4 shows a graph of the address transactions. We can see the OP_RETURN transactions like 3Jt2U where the funds bounce back to the 15y7d address. Interestingly all the remaining $36.18 on the 15y7d address were sent to the address 3Jwj7 in February 2020. No activity has been observed at that address since then.
The second wave seems to have started in April 2020, this time two Bitcoin addresses were used to distribute the malicious C2 domains. Interestingly we did not find any samples using the second address; it could be a testing address to ensure the Glupteba variants were behaving as expected. In addition, the domain distributed via the supposedly testing address deepsound[.]live has not been seen in any other transactions we were able to find across both addresses. It could also be that we simply are missing some samples.
Here the same pattern can be observed on the main address 1CgPC, after a period of activity, the remaining funds accounting for $28.45 were transferred back to some vendor or merchant in November 2021. At the supposed test Bitcoin address, the funds were not transferred and remain to this day on the account for a balance of $76.80. Figure 5 shows the transactions to and from both addresses.
The third campaign starts in November 2021; the number of bitcoin addresses used to deliver malicious domain doubled, from 2 in 2020 to 4 in 2021. This campaign was the shortest of all, with a lifespan of only about two months. We believe this is likely due to Google efforts to take the botnet down, when about a1 year ago Google filed a lawsuit against Glupteba two operators and several actions were taken to disrupt the botnet operations. This is also the first time TOR hidden services were used as a command-and-control server by Glupteba.
Glupteba operators used four wallets, with the most active one being 1CUha as shown in Figure 6. Again, there were no remaining funds left on the Bitcoin addresses. This is also the oldest address in this campaign and the one with the highest number of transactions. Interestingly, we were not able to find a single sample referring to the address 1GLjC which we believe could have been used for testing the malware, similar to 2020. The domain used newcc[.]com was also not registered at the time and could indicate it was used in a testing environment or we could be missing some samples.
The latest and ongoing campaign started in June 2022, 6 months after the Google lawsuit, and this time the number of malicious bitcoin addresses significantly increased. We believe this is due to several factors. First, having more Bitcoin addresses makes security researcher job more complicated. Second, to show that the Google lawsuit did not have a major effect on their Glupteba operations. For this campaign we were not able to find any samples for 3 of the addresses we gathered. We believe these addresses are not made for testing as they distribute some domains found in other Bitcoin addresses for which we found samples. In addition, there was a tenfold increase in TOR hidden service being used as C2 servers since the 2021 campaign.
The transactions graphs shown in Figure 7 involving the addresses used in the 2022 campaign show the upscaling of the operations since 2019. Lastly, we traced back these transactions even further, and we believe that at least five different merchants and exchanges were used to fund the Glupteba addresses since 2019.
In this blog, we have shown how Glupteba can be hunted by following blockchain transaction, TLS certificate registrations, and by reverse engineering samples. We also had a look at how the blockchain can be used to store arbitrary data and how threat actors leverage this in the wild. In addition, we tried to shed some light on the Glupteba campaigns over the years. In terms of resilience, we have seen how the actions Google took to disrupt the Glupteba botnet had an impact on the 2021 campaign, which we believe ended abruptly. Even with Google winning a favorable ruling recently, we hoped it would have inflicted a severe blow to Glupteba operations, but almost a year later we can say it most likely did not. Indeed, it took Glupteba about six months to build a new campaign from scratch and distribute it in the wild, and this time on a much larger scale.
For defenders and responders, we strongly suggest blocking blockchain-related domains like blockchain.info but also Glupteba known C2 domains in your environment. We also recommend monitoring DNS logs and keeping the antivirus software up to date to help prevent a potential Glupteba infection.