Previously Undiscovered TeamTNT Payload Recently Surfaced

Introduction

Sysdig’s threat research team recently reported on a fascinating client engagement they conducted, in response to a sophisticated cloud attack resulting in the loss of proprietary data. This multi-stage attack piqued the interest of those working in the cloud security industry, as it involved a complex exploitation chain - including credential theft and lateral movement between AWS services.

Part of the attack lifecycle involved the deployment of a miner, which Sysdig analysts suspect may have been deployed as a distraction or decoy to aid data exfiltration. After understanding the details of this attack, Cado threat researchers performed a quick VirusTotal triage of files uploaded around the time of the report. Some interesting IoCs were found as a result.

One such IoC was the name of an XMRig configuration file: config_background.json. A quick search in VirusTotal led us to this file, uploaded on the 25th of February 2023. Three days prior to the publication of Sysdig’s blog.

From the XMRig configuration file, we could see an obvious pivot to the parent executable, which is where things start to get really interesting - potentially involving a well-known cloud threat actor: TeamTNT.

An Old Friend?

At Cado we know TeamTNT well, having been the first organisation to identify their original AWS-specific attacks.

There has been some speculation about the return of TeamTNT for some time now, since their public announcement of retirement in late 2021. 

In that time, several cloud-focused threat actors have appropriated TTPs attributed to TeamTNT, in an attempt to foil attribution of their own activities. Since much of the TeamTNT tooling is delivered as shell scripts, it’s very easy to copy the functionality.

That makes the question - “Is this TeamTNT? And if so, is this new activity or just newly uncovered older activity?” harder to answer.

Malware Analysis

The script begins with the header from the screenshot above and includes strings like “hilde”, known to be linked to TeamTNT. The domain DonaldTrump[.]cc was last updated on the 2nd of May 2021 and hasn’t previously been attributed to a malware campaign (TeamTNT or otherwise). 

System Preparation

A number of system weakening and preparatory techniques to facilitate mining can be observed at the start of the script. These techniques are common and aren’t worth elaborating on, but they include:

• Configuration of resource limits via the ulimit command,
• setting the $HISTFILE envar to /dev/null to prevent command history logging and
• configuring iptables to accept all ingress or egress traffic.

Similarly, enumeration of hardware resources in preparation for the miner can be seen further down the script.

System Cleaning and Dynamic Linker Hijacking

Typical for TeamTNT, two functions have been dedicated to cleaning the system of artifacts left by prior compromises - both by themselves and competing miner groups.

The first such function - named CLEANUP_BY_TRUMP() (references to Donald Trump are found throughout) - includes an additional base64-encoded payload entitled LD.PRELOAD.CLEANER. At the time of writing, this payload was unavailable on VirusTotal and other public repositories. Making it more likely that these payloads are from an as yet undiscovered TeamTNT campaign.

As the name suggests, this script ensures that the file /etc/ld.so.preload exists and is writable. It also unsets envars related to the dynamic linker, preparing the system for dynamic linker hijacking (T1574.006). This is another technique typically leveraged by TeamTNT, normally it is used to register a process hider which is able to cloak the XMRig miner process.

A final note on the LD.PRELOAD.CLEANER script: log statements found throughout the script are written in German, consistent with prior TeamTNT campaigns and knowledge about this threat actor. 

The rest of the CLEANUP_BY_TRUMP() function handles removing miner domains from /etc/hosts, reverting a renamed version of the ps command (a technique WatchDog have leveraged in the past) and cleaning evidence of prior compromise from the crontab.

Wallet Configuration

XMRig ships with a default configuration file, within which mining parameters can be set. Most cryptojacking scripts set these parameters dynamically and this script is no different. In a function named WalletConfigSet(), parameters - such as the mining pool address, username and password - are written to disk. The config file is then renamed to config_background.json, which happens to be the same configuration filename referenced in the Sysdig blog.

The user parameter (wallet address) seen in the above has been observed in prior campaigns attributed to TeamTNT. A full list of IoCs is available at the end of this blog.

Registering a Process Hider

Cryptojacking groups frequently make use of libprocesshider, a Linux shared object executable used in conjunction with the LD Preload dynamic linker hijacking technique mentioned earlier to hide their malicious processes. 

In this script we can see the shared object file being retrieved from the URL hxxps://park74110[.]github[.]io/virus/processhider[.]so, which hasn’t previously been seen in cryptojacking campaigns. The file was uploaded to VirusTotal on the same date as the shell script in question and has a high detection ratio, with most vendors detecting it as “libprocesshider” or similar.

As expected, the path to the process hider, renamed as “p.so”, is then inserted into the /etc/ld.so.preload file.

After generating a hash of the retrieved process hider and cross–referencing with VirusTotal, it became clear that this version had been modified. Examining the binary shared object in a disassembler revealed the following process names had been hardcoded:

• kworkers

• dbus

• autoupdate

• ping

• xmrig

These names are consistent with the processes seen in this malware and similar campaigns. After registering the hider with the dynamic linker, anything with these names would be hidden from process listing utilities. 

Persistence

A number of techniques are used to persist the miner across reboots.

First, a simple shell script, named ping.sh, is written to the working directory. This script checks whether XMRig is running via the pidof command. If it’s not, XMRig is executed in the background using the nice command. 

This script is then written to the file .profile in the user’s home directory. The .profile file is a BASH configuration file typically including commands run at login. Naturally, this is an effective persistence mechanism, as these commands are executed when the user activates a shell session (i.e. logging in after a reboot).

After determining whether systemctl is available on the system, the script then goes on to register an additional persistence mechanism in the form of a systemd service unit. The service itself is straightforward, simply running the downloaded version of XMRig via the nice command and a priority of 10. The service is then saved as SystemRaid.service and added to the systemd directory. 

The script checks to see whether the systemctl command used to start the service was successful and if not, it uses nohup to manually execute the miner in the background.

Finally, a file existence check is performed to determine whether the ping.sh script mentioned previously exists, if so a cron job is written to execute it at an interval of every minute.

The above procedure is repeated for a file named trump.sh. This file was not retrieved during this analysis but it seems likely that it could be a copy of the script that forms the basis of this blog. 

Conclusion

Without more information, it’s impossible to conclusively link the sample analysed in this blog to the attack that Sysdig reported, but it’s interesting that these files surfaced around the same time. Perhaps this was the “decoy” miner that they referred to in their original blog.

This malware does bear several syntactic and semantic similarities to prior TeamTNT payloads, and includes a wallet ID that has previously been attributed to them. As a result, it can be determined that this script is indeed a TeamTNT payload. 

New infrastructure, in the form of a previously-unattributed C2 domain, suggests that this sample is part of a new campaign. 

However, Passive DNS results show that the domain was last updated on the 2nd of May 2021. It seems more likely that this is an old sample that’s never been reported on. Either way, it’s interesting to unearth a previously-undiscovered payload from a threat actor well-known to Cado researchers.

Indicators of Compromise (IoCs)

For best practices on investigating and responding to threats in AWS cloud environments, check out our technical playbook.