This post is also available in: 日本語 (Japanese)
New evidence has emerged that suggests the group WatchDog was behind a cryptojacking campaign that we attributed to TeamTNT in a blog published on June 8, 2021. This updated information changed our view on the evidence initially gathered by Unit 42 researchers.
Specifically, the domain oracle.zzhreceive[.]top was originally linked to TeamTNT operations due to the usage of the term zzhreceive, which has been witnessed within several TeamTNT operations. Given recent developments and the growing analytic visibility within the cloud research community, this domain has now been attributed to the cryptojacking operations associated with the group WatchDog. The following is an update of our original blog, more accurately aligned to the current intelligence community information regarding WatchDog’s mimicry of TeamTNT operations.
The copying and incorporation of cryptomining operational codebase or script functions have become a central behavioral indicator of cryptojacking groups and their operations. Unit 42 researchers have identified tactics, techniques and procedures (TTPs) used by the TeamTNT cryptojacking group being used by the WatchDog cryptojacking group. The new scripts from WatchDog are overtly copying TeamTNT infrastructure naming conventions and using a known WatchDog C2 hosting system, 199.199.226[.]117.
With the identification of these new WatchDog scripts, Unit 42 researchers found that techniques that have been synonymous with the TeamTNT group have gone missing. For instance, the new scripts do not:
- Use the latest attack patterns, Kubernetes (K8s) or Docker API targeting, which were featured in two reports focusing on TeamTNT operations, Black-T: New Cryptojacking Variant from TeamTNT and Hildegard: New TeamTNT Cryptojacking Malware Targeting Kubernetes.
- Exfiltrate any identified credentials found on the compromised cloud instances.
- Use the network scanning tool zgrab.
Researchers have also observed that the new WatchDog scripts do not use the exploit-laden GoLang binaries traditionally associated with WatchDog.
While WatchDog is believed to be the author of these new scripts, several of the scripts were found within TeamTNT-owned public malware repositories. It appears that WatchDog may be attempting to expand their cryptojacking operations, while simultaneously masking their operations to appear more like the known cryptojacking operations performed by TeamTNT.
The stealing, hijacking or incorporation of cryptojacking TTPs within other cryptojacking operations has become a common trend within cryptojacking groups. Most notably, TeamTNT was reported to have copied the code used to detect and remove Alibaba Cloud Security from compromised instances from the Kinsing group. Also, cryptojacking groups such as “Rocke” began as a forked GitHub repository from the cryptojacking operation created by “The 8220 Mining Group.” This operation shares up to 30% of its cryptomining code base with tools developed by the group “Pacha.” Pacha and Rocke were subsequently involved in a documented crypto war, which has lasted nearly two years. While little research has been written on recent Pacha operations, Rocke is still developing new malware.
Palo Alto Networks customers running Prisma Cloud are protected from the threats presented in this report through the Runtime Protection feature, Cryptominer Detection feature and the Prisma Cloud Compute Kubernetes Compliance Protection, which alerts on an insufficient Kubernetes configuration and provides secure alternatives. Additionally, Palo Alto Networks VM-Series and CN-Series products offer cloud protections that can prevent network connections from cloud instances toward known malicious IP addresses and URLs.
There are two samples that show the evolution of WatchDog techniques to mimic TeamTNT operations, 36ca9f84864ad022c255b7d91e75997f035716e4df5dc1c90ee2651f092f5d79 and 49366ae4766492d94136ca1f715a37554aa6243686c66bf3c6fbb9da9cb2793d. These samples, first witnessed on Dec. 5 and 11, 2020, respectively, show the direct replacement of the known WatchDog C2 infrastructure with new C2 infrastructure. As shown in Figure 1, the original WatchDog infrastructure, in the dark blue rectangle, has been commented out of the bash script functionality and replaced with the new infrastructure seen in the light blue rectangle.
The new script also makes use of the exact URL address directory tree pattern that is present within the known WatchDog operations, with the directories b2f628 (red) and b2f628fff19fda999999999 (orange), as shown in Figure 2.
These two samples contain a hardcoded Monero (XMR) wallet address and an associated mining pool, as shown in Figure 3.
If these changes are indeed new TeamTNT behaviors, which is highly unlikely, it would represent the first time the TeamTNT cryptojacking operations have used a mining pool outside their traditional Monero mining pool, MoneroOcean[.]stream. This cryptojacking operation introduces two new mining pools never before known to be used by TeamTNT actors, but have been witnessed within WatchDog operations. These mining pools are nanopool[.]org, shown in Figure 4, and f2pool[.]com, shown in Figure 5. The new mining pools are both instructed to use the Monero wallet address, 43Xbgtym2GZWBk87XiYbCpTKGPBTxYZZWi44SWrkqqvzPZV6Pfmjv3UHR6FDwvPgePJyv9N5PepeajfmKp1X71EW7jx4Tpz.
Of note are the names of the mining pool workers associated with this Monero wallet address within the mining pools. According to nanopool[.]org records related to this Monero wallet address, there are a total of 20 unique workers, as shown in Figure 6.
The following table, Table 1, lists 19 of the currently known malicious samples which contain the Monero wallet address, the Nanopool mining pool and the name of one of the workers listed within Figure 6.
Table 1. Malware samples with hardcoded Nanopool mining operation workers.
There were also 13 malicious samples containing the 43Xb Monero wallet address, but these samples are designed to use the f2pool[.]com mining pool instead of the nanopool[.]org Monero mining pool (see Table 2).
Table 2. Malware samples with hardcoded f2pool mining pool operation workers.
Seven samples within the previous table contain instructions to find and remove any processes using the WatchDog-identified 43XB Monero wallet address, as shown in Figure 7.
The scripts will then rebuild mining operations and begin using two known WatchDog Monero wallet addresses, 82etS8QzVhqdiL6LMbb85BdEC3KgJeRGT3X1F3DQBnJa2tzgBJ54bn4aNDjuWDtpygBsRqcfGRK4gbbw3xUy3oJv7TwpUG4 and 87q6aU1M9xmQ5p3wh8Jzst5mcFfDzKEuuDjV6u7Q7UDnAXJR7FLeQH2UYFzhQatde2WHuZ9LbxRsf3PGA8gpnGXL3G7iWMv. These two Monero wallets are just two of the three known Monero wallets that are associated with the WatchDog cryptojacking group. Of note, the IP address listed within Figure 8, 139.99.102[.]72, resolves to the previously mentioned xmr-asia1.nanopool[.]org mining pool.
The URL addresses and Monero wallet address, 87A5fSCR98nFSR9NCRxt6UFytca3hJXaRdDgf9NxhWTjT3q3AA8HECyZ1FdF93D5LPXsSqS8dKNsxCxafrbuVeZfMW3V7ib, specifically called out within the sample 36bf7b2ab7968880ccc696927c03167b6056e73043fd97a33d2468383a5bafce (see Figure 9), are known WatchDog indicators. However, the sample also includes the email address hilde@teamtnt[.]red, which is a known TeamTNT email address.
Now to the malware sample, 8adc8be4b7fa2f536f4479fa770bf4024b26b6838f5e798c702e4a7a9c1a48c6, which contains the new WatchDog Monero wallet, as shown in Figure 10. The same MOxmrigMOD URL address as the known TeamTNT IoC shown within Figure 9 is present, but in this sample we also see additional URL addresses that have very strong ties to WatchDog infrastructure, specifically those involving the domain name oracle.zzhreceive[.]top.
With the presence of the C2 infrastructure from these new scripts, Figure 9 and Figure 10, both of which use the WatchDog directory, b2f628, there is a clear link to the TeamTNT infrastructure. The domain oracle.zzhreceive[.]top resolves to the IP address 199.19.226[.]117, which is also the resolution IP address for the known TeamTNT subdomain zzhrecieve.anondns[.]net.
The usage of the anondns[.]net domain has been linked to several TeamTNT campaigns across multiple reports including, irc.anondns[.]net, ircbd.anondns[.]net, sampan.anondns[.]net and teamtntisback.anondns[.]net. Additionally, the 199.19.226[.]117 system has also been linked to WatchDog operations through the toolkit file 1.0.4.tar.gz, 51de345f677f46595fc3bd747bfb61bc9ff130adcbec48f3401f8057c8702af9, which was hosted on hxxp://global.bitmex[.]com[.]de/cf67355a3333e6/1.0.4.tar.gz and contains C code for the masscan utility, which is the same toolkit used in the TeamTNT operations. The bitmex[.]com[.]de URL had previously been linked to the WatchDog cryptojacking group.
The malware repository 85.214.149[.]236:443/sugarcrm/themes/default/images/ contains known TeamTNT malware that includes the same files as the known TeamTNT repository hxxp://dockerupdate.anondns[.]net:443/sugarcrm/themes/default/images/, which is linked to TeamTNT via the malware sample 1aaf7bc48ff75e870db4fe6ec0b3ed9d99876d7e2fb3d5c4613cca92bbb95e1b, as shown in Figure 11.
Of note, some the of malware samples included in this repository were the Kubernetes and Docker-focused malware, ‘kube.jpg’ and ‘tshd’, presented in Unit 42's Black-T blog, but these appear to no longer be used in the new scripts discussed within this blog. See the appendix for a full listing of the known TeamTNT malware metadata collected from the malware repository.
The malware sample 0414946ab4bced2c1c41f4b8a75be672b34bbdee6f29e0a0bf7946b93f7044b1 is of note in this context as it contains the hardcoded IP address, 199.19.226[.]117, as well as the hardcoded Monero wallet address associated with the nanopool and f2pool mining pools, and the mining workers previously discussed (Figures 12 and 13). As the previous section mentioned, the IP address 199.19.226[.]117 also resolves to the known TeamTNT domain zzhrecieve.anondns[.]net.
Finally, another TeamTNT malware repository was identified by Unit 42 researchers, as shown in Figure 14. The larger Chimaera repository contains known TeamTNT cryptojacking scripts and binary files. Within the spread/redis directory, the file b.sh, 3b14c84525f2e56fe3ae7dec09163a4a9c03f11e6a8d65b021c792ad13ed2701, was found, which directly links TeamTNT to the cryptojacking operations expressed in this report.
The b.sh script contains the 43xb TeamTNT and WatchDog Monero wallet address and points to the 199.19.226[.]117 TeamTNT and WatchDog IP addresses (Figure 15). It also contains a hardcoded link to a known TeamTNT cloud enumeration script hosted on the known TeamTNT domain borg[.]wtf, see Figure 16.
The borg[.]wtf domain was linked to TeamTNT via a previous Unit 42 report. The correlations between TeamTNT and WatchDog are intrinsically connected with this b.sh script.
Considering the above evidence, it appears that WatchDog operations have incorporated the TTPs of the TeamTNT cryptojacking group and have significantly increased their own cryptojacking operations. The new WatchDog operation does not appear to use the advanced functionalities TeamTNT has used recently, namely cloud credential scraping as well as targeted Kubernetes- and Docker-focused lateral movement and exploit scripts.
It’s also noteworthy that the new operation does not incorporate the more advanced GoLang binaries traditionally associated with WatchDog, which are capable of exploiting Windows- or NIX-based operating systems.
It appears that WatchDog actors are attempting to expand their cryptojacking operations, while simultaneously masking their operations with those of the known cryptojacking operations performed by TeamTNT. Unit 42 researchers will continue to monitor this cryptojacking event and provide updates as needed.
The following tips are highly recommended by Unit 42 researchers to assist in the protection of cloud infrastructure.
- Monitor and block network traffic to known malicious endpoints.
- Only deploy vetted container images within production environments.
- Implement and use Infrastructure as Code (IaC) scanning platforms to prevent insecure cloud instances from being deployed into production environments.
- Use cloud infrastructure configuration scanning tools that enable governance, risk management and compliance (GRC) to identify potentially threatening misconfigurations.
- Use cloud endpoint agents to monitor and prevent the running of known malicious applications within cloud infrastructure.
Palo Alto Networks Prisma Cloud customers are protected from these threats through the Runtime Protection feature, Cryptominer Detection feature and the Prisma Cloud Compute Kubernetes Compliance Protection, which alerts on an insufficient Kubernetes configuration and provides secure alternatives. Additionally, Palo Alto Networks VM-Series and CN-Series products offer cloud protections that can prevent network connections from cloud instances toward known malicious IP addresses and URLs.