Des chercheurs en cybersécurité ont découvert une nouvelle campagne de cryptojacking ciblant l’API Docker Engine dans le but de coopter les instances pour qu’elles rejoignent un Docker Swarm malveillant contrôlé par l’acteur menaçant.
Cela a permis aux attaquants « d’utiliser les fonctionnalités d’orchestration de Docker Swarm à des fins de commande et de contrôle (C2) », selon les chercheurs de Datadog Matt Muir et Andy Giron. dit dans une analyse.
Les attaques exploitent Docker pour un accès initial afin de déployer un mineur de crypto-monnaie sur des conteneurs compromis, tout en récupérant et en exécutant des charges utiles supplémentaires chargées d’effectuer des mouvements latéraux vers des hôtes associés exécutant Docker, Kubernetes ou SSH.
Plus précisément, cela implique d’identifier les points de terminaison de l’API Docker non authentifiés et exposés à l’aide d’outils d’analyse Internet, tels que masscan et ZGrab.
Sur les points de terminaison vulnérables, l’API Docker est utilisée pour générer un conteneur Alpine, puis récupérer un script shell d’initialisation (init.sh) à partir d’un serveur distant (« solscan[.]live ») qui, à son tour, vérifie s’il s’exécute en tant qu’utilisateur root et si des outils comme curl et wget sont installés avant de télécharger le mineur XMRig.
Comme d’autres campagnes de cryptojacking, elle utilise le rootkit libprocesshider pour masquer le processus mineur malveillant à l’utilisateur lors de l’exécution d’outils d’énumération de processus tels que top et ps.
Le script shell est également conçu pour récupérer trois autres scripts shell – kube.latéral.sh, spread_docker_local.sh et spread_ssh.sh – du même serveur pour un déplacement latéral vers les points de terminaison Docker, Kubernetes et SSH du réseau.
Spread_docker_local.sh « utilise masscan et zgrab pour analyser les mêmes plages LAN […] pour les nœuds avec les ports 2375, 2376, 2377, 4244 et 4243 ouverts », ont déclaré les chercheurs. « Ces ports sont associés soit à Docker Engine, soit à Docker Swarm. »
« Pour toute adresse IP découverte avec les ports cibles ouverts, le malware tente de générer un nouveau conteneur portant le nom alpin. Ce conteneur est basé sur une image nommée upspin, hébergée sur Docker Hub par l’utilisateur nmlmweb3. »
L’image upspin est conçue pour exécuter le script init.sh susmentionné, permettant ainsi au malware du groupe de se propager à la manière d’un ver vers d’autres hôtes Docker.
De plus, la balise d’image Docker utilisée pour récupérer l’image depuis Docker Hub est spécifiée dans un fichier texte hébergé sur le serveur C2, permettant ainsi aux acteurs de la menace de se remettre facilement d’un retrait potentiel en modifiant simplement le contenu du fichier pour pointer vers un autre image du conteneur.
Le troisième script shell, spread_ssh.sh, est capable de compromettre les serveurs SSH, ainsi que d’ajouter une clé SSH et un nouvel utilisateur nommé ftp qui permet aux acteurs malveillants de se connecter à distance aux hôtes et de maintenir un accès persistant.
Il recherche également divers fichiers d’informations d’identification liés à SSH, Amazon Web Services (AWS), Google Cloud et Samba dans les chemins de fichiers codés en dur au sein de l’environnement GitHub Codespaces (c’est-à-dire le répertoire « /home/codespace/ »), et si trouvé, les télécharge sur le serveur C2.
Dans la dernière étape, les charges utiles de mouvement latéral Kubernetes et SSH exécutent un autre script shell appelé setup_mr.sh qui récupère et lance le mineur de crypto-monnaie.
Datadog a déclaré avoir également découvert trois autres scripts hébergés sur le serveur C2 :
- ar.sh, une variante d’init.sh qui modifie les règles iptables et efface les journaux et les tâches cron pour échapper à la détection
- TDGINIT.sh, qui télécharge les outils d’analyse et dépose un conteneur malveillant sur chaque hôte Docker identifié
- pdflushs.sh, qui installe une porte dérobée persistante en ajoutant une clé SSH contrôlée par l’acteur de la menace au fichier /root/.ssh/authorized_keys
TDGINIT.sh se distingue également par sa manipulation de Docker Swarm en forçant l’hôte à quitter tout Swarm existant dont il peut faire partie et à l’ajouter à un nouveau Swarm sous le contrôle de l’attaquant.
« Cela permet aux acteurs malveillants d’étendre leur contrôle sur plusieurs instances Docker de manière coordonnée, transformant ainsi les systèmes compromis en un botnet pour une exploitation ultérieure », ont déclaré les chercheurs.
On ne sait pas actuellement qui est derrière la campagne d’attaque, bien que les tactiques, techniques et procédures présentées chevauchent celles d’un groupe menaçant connu connu sous le nom de TeamTNT.
« Cette campagne démontre que des services tels que Docker et Kubernetes restent utiles pour les acteurs malveillants qui effectuent du cryptojacking à grande échelle », a déclaré Datadog.
« La campagne repose sur l’exposition des points de terminaison de l’API Docker à Internet sans authentification. La capacité du malware à se propager rapidement signifie que même si les chances d’accès initial sont relativement minces, les récompenses sont suffisamment élevées pour maintenir les groupes de malwares axés sur le cloud suffisamment motivés pour continuer à mener ces attaques. »
Ce développement intervient alors qu’Elastic Security Labs met en lumière une campagne sophistiquée de logiciels malveillants Linux ciblant les serveurs Apache vulnérables pour établir la persistance via GSocket et déployer des familles de logiciels malveillants telles que Kaiji et RUDEDEVIL (alias Lucifer) qui facilitent le déni de service distribué (DDoS) et la cryptomonnaie. minière, respectivement.
« La campagne REF6138 impliquait du cryptomining, des attaques DDoS et un potentiel blanchiment d’argent via des API de jeu, mettant en évidence l’utilisation par les attaquants de logiciels malveillants évolutifs et de canaux de communication furtifs », chercheurs Remco Sprooten et Ruben Groenewoud. dit.