Cloud‑native attackers are building a worm‑like campaign targeting exposed JupyterLab and Docker APIs, deploying Tsunami malware, cryptomining, and a backdoor while concealing infrastructure with proxies and DNS‑over‑HTTPS. Researchers attribute the activity to TeamTNT or a copycat and outline the evolving attack tooling, infrastructure, and early defensive steps. #TeamTNT #Tsunami
Keypoints
- Aqua Nautilus identified an aggressive cloud worm infrastructure aimed at misconfigured cloud native environments, especially exposed JupyterLab and Docker APIs.
- Four container images were analyzed (shanidmk/jltest2, jltest, sysapp, blob) and Docker Hub removed the malicious images.
- The campaign uses ZGrab, masscan, a cryptominer, and Tsunami as a backdoor, with C2 communications via HTTP and DNS‑over‑HTTPS, masking behind NGROK.
- The attacker scripts deploy run.sh and docker_entrypoint.sh to automate deployment, scanning, and payload delivery within containers.
- TeamTNT attribution is discussed, with the campaign described as early‑stage and likely to expand unless mitigated, plus recommendations for hardening cloud environments.
- Recommendations include securing JupyterLab Docker API exposure, least privilege, image scanning, logging/monitoring, and cloud security tooling.
MITRE Techniques
- [T1046] Network Service Scanning – The masscan tool scans and pipes the IP to be utilized by ZGrab for assessing whether there is an exposed Jupyter Lab instance operating at http://Currently_found_IP_Address:8888/lab. “masscan tool scans and pipes the IP to be utilized by ZGrab …”
- [T1059.004] Unix Shell – The run.sh shell script is designed to commence upon the startup of the shanidmk/jltest2 container. “run.sh shell script designed to commence upon the startup of the shanidmk/jltest2 container.”
- [T1105] Ingress Tool Transfer – The container workflow downloads packages to secure the necessary utilities for the environments. “The downloading of some packages to secure the necessary utilities for the environments.”
- [T1090] Proxy – The attacker uses proxy mechanisms (proxychains3) to route traffic through a proxy chain. “It uses the proxychains3 application, which is designed to force any TCP connection … to follow through a proxy.”
- [T1071.001] Web Protocols – Command and control communications utilize HTTP to send results back to the C2 server. “The output is then transmitted to the attacker’s C2 server.”
- [T1071.004] DNS – The attacker leverages DNS‑over‑HTTP (anondns.net) to mask C2 activity; a silentbob subdomain is used for C2. “Anondns is a DNS over HTTP service enabling the attacker to interact with his backend without revealing the actual address.”
Indicators of Compromise
- [Domain] silentbob.anondns.com – Used as a C2 domain/subdomain for DNS‑over‑HTTP based communication.
- [Domain] anondns.net – DNS over HTTP service used to mask the C2 server.
- [File Hash] ba1b03bc2c262d724c0616eba9d7828b – ELF/cryptominer component referenced in the sysapp image.
- [File Hash] 87c8423e0815d6467656093bff9aa193 – Tsunami malware component referenced in blob image.
- [File] run.sh – Shell script executed at container startup to initiate the attack chain.
- [File] docker_entrypoint.sh – Script that runs on container launch to initialize the attack sequence.
- [File] aws.sh.txt – Script suspected of scanning for AWS keys/secrets in the environment.
- [File] x.noback / x.back – Possible Tsunami payload variants referenced in the blob image.
- [Domain] http://Currently_found_IP_Address:8888/lab – URL observed during the JupyterLab discovery stage.
- [URL] silentbob[.]anondns[.]com – C2 domain used in wild activity for testing patterns.
Read more: https://blog.aquasec.com/threat-alert-anatomy-of-silentbobs-cloud-attack