Commando Cat : une nouvelle attaque de cryptojacking abusant des serveurs API distants Docker
Nuage
Nous analysons une campagne d’attaque de cryptojacking exploitant des serveurs API distants Docker exposés pour déployer des mineurs de cryptomonnaie, à l’aide d’images Docker du projet open source Commando.
Temps de lecture: ( mots)
- Nous analysons une campagne d’attaque de cryptojacking exploitant des serveurs API distants Docker exposés pour déployer des mineurs de cryptomonnaie, à l’aide d’images Docker du projet open source Commando.
- Des acteurs malveillants emploient le cmd.cat/chattr image pour l’accès initial, en utilisant des techniques telles que chroot et la liaison de volume pour sortir du conteneur et accéder au système hôte.
- Les indicateurs d’attaque peuvent inclure des chaînes User-Agent spécifiques, ainsi que l’utilisation de DropBear SSH sur le port TCP 3022, ce qui peut aider à détecter la présence du logiciel malveillant.
- Pour atténuer de telles attaques, il est essentiel de respecter les meilleures pratiques en matière de sécurité des conteneurs, telles que la configuration correcte des conteneurs et des API et l’utilisation d’images Docker fiables.
Nous avons observé une campagne d’attaque abusant des serveurs API distants Docker exposés pour déployer des mineurs de cryptomonnaie. Cette campagne d’attaque porte le nom de Commando Cat en raison de sa première étape, qui implique le déploiement de conteneurs inoffensifs générés à l’aide du projet Commando accessible au public (un projet GitHub open source qui crée des images Docker à la demande pour les développeurs). Commando, qui est accessible au public, est déployé à l’aide de cmd.cat. Les assaillants ont utilisé le cmd.cat/chattr conteneur d’images Docker qui récupère la charge utile de leur propre infrastructure de commande et de contrôle (C&C). Cette campagne d’attaque est active depuis début 2024.
Pour obtenir un accès initial, l’attaquant déploie une image Docker nommée cmd.cat/chattr, une image Docker inoffensive. Une fois déployé, l’acteur malveillant crée un conteneur Docker basé sur cette image et utilise chroot pour sortir du conteneur et accéder au système d’exploitation hôte. Il utilise également curl/wget pour télécharger le binaire malveillant sur l’hôte.
Décomposons étape par étape le déroulement de l’attaque :
1. Sonder le serveur API Docker Remote
La séquence d’événements de cette campagne d’attaque commence par un ping vers le serveur API Docker Remote, qui sert de point de départ crucial pour la chaîne d’actions qui s’ensuit.
2. Création du conteneur à l’aide du cmd.cat/chattr image:
Après avoir confirmé l’état du serveur comme « OK », l’attaquant procède à l’instanciation d’un conteneur à l’aide du image cmd.cat/chattr.
Dans la demande de création de conteneur, nous voyons l’acteur malveillant employer chroot et une liaison de volume pour échapper au conteneur. En utilisant chrootl’attaquant peut jeter un coup d’œil à l’extérieur du conteneur, puis pénétrer dans le système hôte à l’aide du Lie paramètre, qui spécifie les liaisons de volume.
La reliure /:/heure monte le répertoire racine de l’hôte dans le répertoire du conteneur /hs répertoire, accordant à l’attaquant un accès illimité au système de fichiers hôte. Il lie également le socket Docker (/var/run/docker.sock:/var/run/docker.sock), donnant au conteneur un accès direct au démon Docker sur l’hôte, permettant ainsi aux attaquants de contrôler Docker comme s’ils étaient sur la machine hôte elle-même.
3. Création d’images en l’absence
Si la requête ci-dessus renvoie une réponse No such image, l’attaquant extraira le chat image Docker du cmd.cat dépôt.
4. Déploiement de conteneurs
Une fois l’image en place, l’attaquant crée un conteneur Docker, exécutant ainsi une réplique de l’étape précédente.
Lors de la création du conteneur Docker, l’acteur malveillant exécute une chaîne codée en base64 :
Cela se traduit par le script shell suivant :
Le script commence par une vérification conditionnelle pour déterminer si un fichier nommé « z » existe dans le répertoire /usr/sbin/. Si le fichier n’existe pas, le script procède au téléchargement et à l’exécution du binaire malveillant depuis son serveur de fichiers (hxxp[:]/leetdbs[.]anondns[.]net/z) et l’enregistre dans le répertoire /usr/sbin/, qui est potentiellement ZiggyStarTux, un robot IRC open source basé sur le malware Kaiten. Ce binaire est compressé à l’aide du packer UPX.
Lors de l’analyse, nous avons constaté que le serveur C&C était en panne. Cependant, les chaînes User-Agent suivantes présentes dans le binaire peuvent être utilisées pour surveiller la présence de ce malware sur le réseau :
- Agent utilisateur : HackZilla/1.67 [en] (X11 ; U ; Linux 2.2.16-3 x64)
- Agent utilisateur : Mozilla/4.75 [en] (X11 ; U ; Linux 2.2.16-3 i686)
Les chaînes présentes dans ce binaire/code suggèrent que ce malware utilise DropBear SSH, un serveur SSH relativement petit et une application client sur le port TCP 3022. Cela pourrait servir d’indice supplémentaire pour repérer le malware.
Le malware déployé tente de connecter son serveur C&C 45[.]9[.]148[.]193 sur le port 1219. La figure 6 représente le trafic réseau initial, qui montre la communication IRC initiale.
L’importance de cette campagne d’attaque réside dans l’utilisation d’images Docker pour déployer des scripts de cryptojacking sur des systèmes compromis. Cette tactique permet aux attaquants d’exploiter les vulnérabilités des configurations Docker tout en évitant la détection par les logiciels de sécurité. Alors que les chercheurs en cybersécurité continuent de surveiller cet acteur malveillant, il est essentiel pour les organisations de renforcer leurs défenses contre les attaques liées à Docker.
Pour protéger les environnements de développement contre les attaques ciblant les conteneurs et les hôtes, nous vous recommandons de mettre en œuvre les bonnes pratiques suivantes :
- Les conteneurs et les API doivent toujours être correctement configurés pour minimiser les risques d’attaques d’exploitation. Docker a des directives spécifiques sur la manière dont leurs utilisateurs peuvent renforcer leur sécurité.
- Les organisations doivent utiliser uniquement des images officielles ou certifiées pour garantir que seul du contenu fiable est exécuté dans l’environnement.
- Les conteneurs en cours d’exécution ne doivent pas être exécutés avec les privilèges root, mais plutôt en tant qu’utilisateurs d’application.
- Les conteneurs doivent être configurés de manière à ce que l’accès soit accordé uniquement aux sources fiables, telles que le réseau interne.
- Les organisations doivent adhérer aux meilleures pratiques recommandées. Par exemple, Docker fournit une liste complète des meilleures pratiques et dispose de fonctionnalités de sécurité intégrées que les utilisateurs peuvent suivre pour améliorer la sécurité de leurs environnements cloud.
- Des audits de sécurité doivent être effectués à intervalles réguliers pour rechercher tout conteneur ou image suspect.
- Conclusion
La campagne d’attaque Commando Cat met en évidence la menace posée par l’abus des serveurs API distants Docker exposés. En exploitant les configurations Docker et en tirant parti d’outils open source comme cmd.cat, les attaquants peuvent obtenir un premier accès et déployer des fichiers binaires malveillants, tout en évitant les mesures de sécurité conventionnelles. L’utilisation d’images Docker par la campagne pour propager des scripts de cryptojacking souligne l’importance de mettre en œuvre des pratiques robustes de sécurité des conteneurs.
Les solutions de sécurité suivantes sont recommandées pour protéger les serveurs Docker.
Les protections suivantes existent pour détecter les activités malveillantes et protéger les clients Trend contre les attaques évoquées dans cet article de blog :
- 1010326 – Appel d’API distant du démon Docker identifié
- 1008619 – Docker d’applications
- 1010349 – Appels d’API à distance du démon Docker
Requête de chasse Trend Vision One
Le texte suivant répertorie les requêtes potentiellement utiles pour la recherche de menaces dans Vision One :
eventId:100115 AND (remarques : POST_IMG_BLD_CRE OU remarques : POST_CON_CREATE) AND « cmd.cat »
ATTAQUE À ONGLET ET CK
| Tactique | Technique | Identifiant technique |
|---|---|---|
| Accès initial | Exploiter une application destinée au public | T1190 |
| Exécution | Déployer un conteneur | T1610 |
| Interpréteur de commandes et de scripts : Unix Shell | T1059.004 | |
| Augmentation des privilèges | Échapper à l’hôte | T1611 |
| Commander et contrôler | Encodage des données : encodage standard | T1132.001 |
| Transfert d’outil d’entrée | T1105 |
Indicateurs de compromis
Les indicateurs de compromission pour cette entrée peuvent être trouvés ici.
Mots clés
sXpIBdPeKzI9PC2p0SWMpUSM2NSxWzPyXTMLlbXmYa0R20xk