On 17 August 2020, Cado Security reported a cryptomining worm that did something new: as well as mining Monero, it searched every host it infected for Amazon Web Services credentials and sent them to its operators. The group behind it called itself TeamTNT. The worm spread by scanning the internet for Docker APIs left open without protection, starting containers on them and installing itself. On each compromised system it copied the AWS command line tool's credentials and configuration files, which are stored unencrypted in the user's home directory, and uploaded them to an attacker server. Cado said a mining pool page listed 119 compromised systems, including Kubernetes clusters and Jenkins build servers. Cado sent TeamTNT decoy AWS keys and had not seen them used at the time of writing. The campaign showed that cryptojacking crews had started treating cloud keys left on servers as loot in their own right.
Key takeaways
- Cado Security disclosed on 17 August 2020 a TeamTNT worm that stole AWS credential and configuration files from every host it infected; Cado called it the first worm it had seen with such AWS-specific functionality.
- The worm spread through Docker APIs exposed to the internet, then ran the XMRig miner and a set of rootkit, backdoor and log-cleaning tools.
- Cado counted 119 compromised systems on a mining pool page, including Kubernetes clusters and Jenkins build servers; CERT-EU repeated the figure.
- Cado's decoy AWS keys had not been used when it published, so the confirmed harm is credential theft and mining; any later use of stolen keys was not reported.
- The identity lesson: a long-lived cloud key saved in a file on a server is only as safe as that server, and any malware that lands there can take it.
At a glance
| Organisations | Operators of at least 119 compromised Docker and Kubernetes hosts and Jenkins servers, according to Cado Security and CERT-EU; no victims named |
|---|---|
| When | Spreading over the weekend of 15 to 16 August 2020; disclosed by Cado Security on 17 August 2020 |
| Attacker | TeamTNT, a cryptojacking group that named itself in the malware, according to Cado Security |
| Entry point | Docker APIs exposed to the internet, found by mass scanning |
| Identities abused | AWS access keys stored in plain text in the AWS command line tool's credentials file, plus other local credentials |
| Impact | AWS credential files exfiltrated from compromised hosts; compute hijacked for Monero mining; no confirmed use of the stolen keys reported |
| Category | NHI. Incident class: confirmed NHI breach (cloud credential files stolen from compromised hosts by a self-spreading worm) |
What happened
Cryptojacking worms that hunt for exposed Docker APIs were not new in 2020. Help Net Security noted that MalwareHunterTeam and Trend Micro researchers had first spotted an earlier version of this worm in May 2020. What Cado Security found in August was an update. "Over the weekend we've seen a crypto-mining worm spread that steals AWS credentials," Cado wrote, adding: "It's the first worm we've seen that contains such AWS specific functionality." Cado said the attackers, "who call themselves 'TeamTNT', compromise a number of Docker and Kubernetes systems."
The worm used the masscan tool to search for Docker APIs reachable from the internet. When it found one, it started a container and installed itself, then continued scanning from the new host. On each system it looked for the AWS command line tool's files in the .aws folder of the user's home directory: the credentials file, which Cado noted the tool "stores credentials in an unencrypted file", and the configuration file. It uploaded both to an attacker-controlled server, which answered "THX". Cado observed that "The code to steal these files is relatively straightforward," and said the worm also stole other local credentials. TeamTNT had borrowed code from another worm, Kinsing, to stop Alibaba Cloud security tools.
The payload was a full toolkit. The worm installed XMRig to mine Monero, along with an SSH post-exploitation tool called punk.py, a log-cleaning tool, the Diamorphine rootkit and the Tsunami IRC backdoor. Cado said a mining pool page listed 119 compromised systems, some identified as Kubernetes clusters and Jenkins build servers, and that about 3 Monero (around 300 US dollars) had been mined to two wallets linked to the attacks. CERT-EU issued a threat memo on 19 August citing "at least 119 systems affected, including some Jenkins servers".
What happened to the stolen keys is less clear. Cado tested this directly: "We sent credentials created by CanaryTokens.org to TeamTNT, however have not seen them in use yet." It suggested the attackers might review credentials by hand, or that their automation was not yet working. CERT-EU described the malware as able to acquire AWS credentials and use them to pivot to additional systems, but no source we read reports a confirmed case of a stolen key being used. Cado's advice centred on the credentials themselves: "It's common to find development credentials have accidentally been left on production systems."
Timeline
| Date | Event |
|---|---|
| May 2020 | MalwareHunterTeam and Trend Micro spot an earlier version of the TeamTNT worm targeting exposed Docker APIs, according to Help Net Security. |
| 15 August 2020 | The updated worm spreads over the weekend of 15 to 16 August, stealing AWS credential files, according to Cado Security. |
| 17 August 2020 | Cado Security discloses the worm and its AWS credential theft. |
| 18 August 2020 | Help Net Security and Virtualization Review report Cado's findings. |
| 19 August 2020 | CERT-EU publishes a threat memo citing at least 119 affected systems. |
How it happened: the identity attack path
- Exposed Docker APIs found. The worm used masscan to find Docker APIs reachable from the internet without access control.
- Container started and worm installed. Through the open API it started a container and installed itself, then scanned for further targets.
- Cloud credentials harvested. On each host it read the AWS command line tool's credentials and configuration files, stored unencrypted in the home directory, and other local credentials.
- Keys exfiltrated. The files were uploaded with curl to an attacker-controlled server.
- Host abused. XMRig mined Monero while a rootkit, a backdoor and a log cleaner helped the attackers stay hidden.
Impact
- Confirmed: at least 119 systems compromised, including Kubernetes clusters and Jenkins build servers, according to Cado Security and CERT-EU, with AWS credential files taken from infected hosts.
- Confirmed: compute hijacked for Monero mining, with about 300 US dollars mined to two wallets, according to Cado.
- Not confirmed: use of the stolen AWS keys. Cado's decoy keys had not been used when it published.
- Potential: any stolen AWS key carries the rights of the user or role it belongs to, so a key from a build server or administrator workstation could open the wider cloud account.
What this means for NHI governance
This belongs on an NHI list because the target changed. Earlier worms wanted CPU time; this one wanted the cloud access keys sitting on the machines it infected. Static AWS access keys in a credentials file are machine credentials: they do not expire unless someone rotates them, they work from anywhere, and the server they sit on is often a build host or a developer's test box that nobody treats as sensitive. A worm that lands on such a host inherits whatever cloud access that file grants.
The fixes sit on both sides of the key. On the host side, close exposed management interfaces like the Docker API. On the identity side, stop leaving long-lived keys on servers at all: workloads on AWS can use instance roles or other short-lived credentials, and keys that must exist should be scoped tightly and monitored for use from unexpected places. Our Cloud Workload Identity Guide and Cloud PAM and CIEM Guide cover these controls. The same pattern of stolen cloud keys feeding crypto-mining has continued since, as in the Amazon AWS crypto-mining campaign.
Recommendations
- Remove static AWS keys from servers. Find every host with an AWS credentials file, delete the ones not needed, and replace the rest with instance roles or other short-lived credentials. See our Cloud Workload Identity Guide.
- Rotate keys from any host that may have been infected. Treat keys on a compromised machine as stolen and check CloudTrail for their use. See the Leaked Credential Response Playbook.
- Close exposed Docker APIs. Use firewall rules, ideally an allowlist, to restrict access to the Docker API, as Cado advised. See the Kubernetes NHI Security Guide.
- Scope cloud keys to least privilege. A key on a build server should not hold administrator rights. See the Cloud PAM and CIEM Guide.
- Watch for credential files leaving the network. Monitor for AWS credential files sent over HTTP and for connections to mining pools or the Stratum protocol, both of which Cado recommended.
- Use decoy credentials. Canary keys placed where real keys would sit give early warning when an attacker tries to use stolen credentials.
Frequently asked questions
What did the TeamTNT worm steal?
The worm copied the AWS command line tool's credentials and configuration files from each infected host and uploaded them to an attacker server, according to Cado Security. It also stole other local credentials and installed the XMRig miner.
How did the TeamTNT worm spread?
It scanned the internet for Docker APIs exposed without protection, started a container through each one and installed itself, then kept scanning. Cado Security counted 119 compromised systems on a mining pool page, including Kubernetes clusters and Jenkins servers.
Were the stolen AWS keys used?
Not that anyone confirmed at the time. Cado Security sent decoy AWS keys to TeamTNT's server and had not seen them used when it published. CERT-EU described the malware as able to use stolen credentials to pivot to other systems, but no confirmed case was reported in the sources we read.
Related NHI Mgmt Group resources
Kubeflow Cryptomining Attacks 2020 · Tesla Kubernetes Cryptojacking 2018 · Amazon AWS Crypto-Mining Campaign 2025 · Cloud Workload Identity Guide · Cloud PAM and CIEM Guide
How NHI Mgmt Group can help
Static cloud keys left on servers are among the easiest machine credentials to steal. We help teams find them, replace them with short-lived workload identities and set up the monitoring that spots a stolen key in use. See our NHI and AI agent security training.
References
- Cado Security: Team TNT – The First Crypto-Mining Worm to Steal AWS Credentials (17 August 2020)
- Help Net Security: Updated cryptojacking worm steals AWS credentials (18 August 2020)
- Virtualization Review: Crypto-Mining Worm Steals AWS Creds: '/thx/for/your/key' (18 August 2020)
- CERT-EU: Threat Memo, A cryptomining worm that steals AWS credentials (19 August 2020)