Jared Stroud
Cloud Security Researcher – Lacework Labs 

Points essentiels

• TeamTNT cible les API Docker exposées pour déployer des images malveillantes.
• Les images Docker contenant un malware TeamTNT sont hébergées dans un répertoire Docker au moyen de l'usurpation de comptes. 
• TeamTNT exploite les secrets exposés du hub Docker dans GitHub pour mettre en scène des images Docker malveillantes.
• Les techniques MITRE ATT&CK suivantes ont été observées : Deploy Container (T1610), User Execution: Malicious Image (T1204.003), Unsecured Credentials: Credentials In Files (T1552.002), Implant Internal Image (T1525) et Valid Accounts: Cloud Accounts (T1078.004).

 

Résumé

TeamTNT a indexé des images malveillantes sur Docker Hub en utilisant le compte Docker Hub d'un utilisateur légitime. Les identifiants du compte Docker Hub ont été accidentellement transmis à un répertoire GitHub public, où nous pensons que TeamTNT a obtenu un accès initial au compte. Lacework Labs a averti Docker Security et le propriétaire du compte visé (megawebmaster) qui a rapidement pris des mesures pour perturber les containers Docker indexés par TeamTNT en les supprimant de Docker Hub.

 

Pris la main dans le sac

L'équipe de recherche de Lacework Labs déploie un certain nombre de honeypots différents pour collecter des données sur les services courants déployés dans les environnements cloud. Cette approche « en circuit court » nous permet d'organiser des attaques opportunistes contre l'infrastructure factice exposée. Le honeypot de l'API Docker de Lacework Labs a capté la requête suivante qui a révélé la création d'une image de container du nom de « dockgeddon » à partir du compte Megawebmaster ( T1610). 

 

Honeypot Docker – Demande de création de containers

Lors de l'inspection de cette image Docker, les utilitaires TeamTNT ont été repérés dans les containers du compte de Docker Hub « Megawebmaster ». Dans l'image ci-dessus, les éléments surlignés en rouge correspondent à l'image en cours d'extraction (megawebmaster/dockgeddon), à la configuration du montage hôte liant la racine de l'hôte à /host dans le container, au mode réseau défini sur l'hôte, ainsi qu'au container tentant d'être déployé en tant que container privilégié. Le compte Docker Hub de MegawebMaster possède de nombreuses images publiques, dont cinq disposent des utilitaires TeamTNT avec un nombre important de téléchargements. Ces cinq images comprennent dockgeddon, docker, tornadopw et dcounter (T1204,003).

Hébergement d'images malveillantes sur le hub Docker

 

En rebondissant sur le nom d'utilisateur « Megawebmaster », un compte GitHub qui contenait un fichier de configuration comportant des secrets Docker Hub (T1552,001) a été découvert. Il est présumé que TeamTNT a exploité ce fichier de configuration pour charger des images Docker malveillantes sur le compte Docker Hub de cet utilisateur (T1525). Lacework Labs a contacté le propriétaire du compte GitHub ainsi que Docker Security pour supprimer à la fois les identifiants Docker exposés et les images Docker malveillantes.  

 

Explorer les images Docker

L'utilitaire open source « dive » permet d'explorer chaque couche d'une image Docker. Cela permet un triage rapide d'une image Docker pour comprendre quels fichiers ont été ajoutés à quelle couche. Pour chaque image Docker répertoriée ci-dessous, Lacework Labs a utilisé dive pour identifier les fichiers intéressants, puis a copié les fichiers hors du container Docker pour effectuer un triage plus poussé.

 

Images Docker – Dockgeddon

Dans l'image « dockgeddon », trois utilitaires malveillants ont été identifiés. Ces utilitaires comprenaient une variante du bot IRC Tsunami (TNTfeatB0rg), un utilitaire de capture de bannière (zgrab) et leur utilitaire de diffusion init.sh. L'image ci-dessous montre l'utilitaire dive affichant ces fichiers et leur emplacement dans l'image Docker.

Inspection en profondeur d'images Docker

Après l'obtention du binaire TNTFeatB0RG à partir de l'image Docker et son analyse dans Ghidra, les adresses IP et les domaines connus associés à TeamTNT ont pu être identifiés. 

Analyse de TNTFeatB0RG dans Ghidra

 

Des modifications supplémentaires apportées à TNTFeatB0RG comprennent l'exécution de commandes base64 dans le binaire via des appels de fonction system. La charge utile base64 intégrée est un script bash utilisé pour voler les identifiants AWS du service de métadonnées AWS hébergé sur 169.254.169.254 (T1078.004). 

Ghidra – Exécution de base64 

 

Script embarqué Base64 pour le vol de secrets AWS 

 

L'utilitaire init.sh télécharge XMRig pour commencer à miner Monero sur l'hôte victime. Le portefeuille associé montre que plusieurs employés sont utilisés pour renforcer les opérations illicites de TeamTNT. 

État du portefeuille Monero

Images Docker – small

L'image Docker du nom de « small » contient trois fichiers : « dockerd », « kernel » et « init.sh ». Le binaire nommé « kernel » était une autre variante Tsunami qui a été détectée sur les mêmes serveurs IRC TeamTNT que ceux identifiés dans dockgeddon. Cependant, cette variante rejoint le canal « #DockerAPI » alors que dockgeddon rejoint le canal IRC « #masspwn ». Les deux ont en commun le nom de processus « kworker/08:15-events ».

 

Décompilation Ghidra du bot IRC Tsunami de l'image Docker Dockgeddon (à gauche) et bot IRC Tsunami de l'image Docker small (à droite)

Par rapport à dockgeddon, cette variante Tsunami n'avait pas de charges utiles base64 intégrées. La sortie décompilée Ghidra ci-dessous montre en quoi les variantes Tsunami de TeamTNT sont différentes. Ces petits changements dans les bots Tsunami montrent l'évolution constante des TTP mis en place par TeamTNT.

Ghidra – Différences dans la fonction principale des bots Tsunami  

Le binaire « dockerd » est un binaire UPX Ezuri compressé qui télécharge un binaire XMRig. Ce binaire s'exécute ensuite en tant que « kworker/13:37 » et utilise le même portefeuille que celui de l'image dockgeddon.

Configuration XMRig dans TeamTNT

 

Le script init.sh est un wrapper pour l'utilitaire de portée WeaveWorks qui est généralement utilisé pour la gestion d'un environnement de containers (T1613). À partir de la portée, il est possible d'obtenir un accès à distance et une visibilité sur l'environnement de la victime via l'interface utilisateur WeaveWorks.

TeamTNT exploitant la portée de WeaveWorks

Image Docker – dcounter

Dans l'image dcounter, un seul script (init.sh) a été identifié. Ce script s'appuie sur le service gratuit iplogger.org, qui permet de suivre les utilisateurs finaux lorsqu'ils accèdent à une ressource spécifique. Dans ce scénario, TeamTNT l'utilise en tant que service de notification. Chaque fois que le container Docker « dcounter » est exécuté, on accède à cette ressource pour consigner l'adresse IP de la victime. De plus, l'infrastructure TeamTNT héberge également ce que les équipes de recherche Lacework Lab pensent être un service de journalisation end-point à l'adresse IP indiquée dans l'image ci-dessous.

 

Script de suivi TeamTNT

 

Image Docker – tornado

L'image Docker tornado contient un script intitulé « tornado.sh ». Cet utilitaire s'appuie sur massscan et zgrab pour procéder à la reconnaissance à partir de la plage d'adresses IP cible et des ports donnés au container. En la présence d'une phrase clé comme « Home page – Select or create a notebook », « Kubeflow Central Dashboard », « Jupyter Lab » ou « JupyterLab », l'utilitaire « jq » filtre ensuite l'adresse IP hors de ces correspondances, qui sont ensuite ajoutées à un tableau de « rndstr ». Les résultats de ces données sont envoyés à une adresse IP contrôlée par TeamTNT. Lacework Labs évalue avec une confiance moyenne à élevée ces résultats qui sont ciblés pour des infractions ultérieures.

Script d'analyse TeamTNT

Conclusion

TeamTNT continue de cibler l'infrastructure cloud afin d'obtenir un accès, d'effectuer des opérations de cryptojacking et d'extraire les secrets du cloud. Il est essentiel de s'assurer que les environnements cloud n'exécutent pas de points de terminaison non authentifiés exposés pour éviter que des hackers opportunistes n'accèdent à votre environnement. Comprendre la surface d'attaque de votre container/Kubernetes déployé ainsi que celle des workloads cloud est primordial dans l'environnement cloud qui, aujourd'hui, ne cesse d'évoluer. Tous les IOC sont disponibles dans le GitHub de Lacework Labs. Abonnez-vous à @LaceworkLabs sur Twitter et LinkedIn pour suivre nos dernières recherches.

 

 

 

IOCs

 

File	Hash
tornado.sh	c8ed6a70790ae58a1e10debb92a9ec4f864153fc1599431fb8b3a03b7edc8641
x	e85ab365fe239373669c08ad9d18b1cae95565e6767415a51aacdb8abe7e2315
docker.sh	94da4e21def0c6390879a838b5e64b9edabd5d7cf525ec2edfbe478ce7b0b4a7
init.sh	d4c7ee2acd9b59c2add80cfb61e8efba663b7917537fa0f356b2545c43e956b4
TNTfeatB0rg	9504b74906cf2c4aba515de463f20c02107a00575658e4637ac838278440d1ae
init.sh	b8e4f8b3d43c7864ad1a05ff82612ac5721d1c62ef6a2c5fef82dc301a6f4e31
kernel	ea0ed7cbc0fefb534a26c6c6b8412c9fb843da8d09a507cbb160916eac25441b
dockerd	84078b10ad532834eb771231a068862182efb93ce1e4a8614dfca5ae3229ed94
init.sh	d0bc3b8a8a5da1d14dfb16297d825d7f40a065d64aae96645062905f4c90008e
wallet	46EPFzvnX5GH61ejkPpNcRNm8kVjs8oHS9VwCkKRCrJX27XEW2y1NPLfSa54DGHxqnKfzDUVW1jzBfekk3hrCVCmAUrFd3H