TeamPC CanisterWorm: destruction sélective et persistance dans les environnements de Kubernetes

Il y a quelques jours, des chercheurs en sécurité ont dévoilé une campagne qui combine les techniques de mouvement latéral dans les environnements nuageux avec une charge utile délibérément destructrice orientée vers les systèmes iraniens. La constatation, documentée par l'entreprise Aïkido, attribue l'opération au groupe appelé TeamPCP et l'associe aux activités antérieures qui ont engagé des outils open source et des paquets NPM sous le nom informel « CanisterWorm ».

La menace combine deux parties : Dans les environnements de Kubernetes, il profite des mécanismes natifs pour se propager et persister; en dehors de Kubernetes, il active un mécanisme d'effacement de masse qui peut laisser les machines inutiles si elle détecte certaines pistes du système.

Selon l'analyse technique, les logiciels malveillants tentent d'abord de déterminer si l'ordinateur correspond à l'Iran en examinant le temps et les paramètres des zones régionales. Si vous détectez ces signaux et que Kubernetes existe dans la machine, vous déployez un DaemonSet dans l'espace système qui met en place le système de fichiers hôte et démarre des conteneurs privilégiés. Chacun de ces conteneurs exécute une image minimale (Alpine) avec un binaire qui efface les entrées principales du disque hôte et force un redémarrage, une manœuvre qui peut, dans la pratique, laisser des nœuds et des applications irréparables.

D'autre part, lorsque le système n'est pas identifié comme iranien mais qu'il a Kubernetes, la même infrastructure de propagation est réutilisée pour installer un composant persistant : une porte arrière écrite en Python qui est laissée dans le système de fichiers et enregistrée comme un service système pour survivre aux travaux. Cette double stratégie - supprimer là où elle est considérée comme "objectif" et reculer là où elle n'est pas - confirme le caractère sélectif et orienté de la campagne.

L'acteur n'est pas limité à Kubernetes: Aikido documente également des variantes qui renoncent au mouvement latéral basé sur DaemonSet et ont recours à des mécanismes de propagation SSH plus traditionnels. Dans ces cas, les logiciels malveillants scannent les enregistrements d'authentification pour des identifiants valides, réutilisent les clés privées compromises et établissent des connexions SSH sortantes avec des options qui évitent les vérifications de l'empreinte de l'hôte (par exemple, en utilisant StritHostKeyChecking = non). Un autre canal d'expansion identifié est l'utilisation des API Docker exposées (habituellement le port 2375 sans TLS), qui permettent de démarrer des conteneurs privilégiés et monter l'hôte comme volume, qui reproduit l'effet destructeur en dehors de l'écosystème Kubernetes.

Il y a des indicateurs spécifiques à surveiller: parmi eux, l'activité dans le réseau sortant vers l'infrastructure de commande et de contrôle déjà associée à CanisterWorm, l'apparition de DaemonSet avec des noms suspects tels que "Host-proviser-Iran" ou "Host-proviser-std" dans le namespace kube-system, conteneurs alpins marqués "kamikaze", fichiers temporaires laissés sur les itinéraires / tmp / pglog et les connexions à APis Docker dans le port 2375 aux hôtes du sous-réseau local. Aikido indique également un conteneur spécifique utilisé comme C2; son rapport fournit des détails plus techniques et des artefacts du CIO pour l'équipement d'intervention : Rapport Aïkido.

Pour mettre en contexte les avantages de cette campagne, il est important de se rappeler comment fonctionnent certains éléments clés de Kubernetes et Docker. Les DaemonSet sont des objets Kubernetes qui assurent l'exécution d'un pod dans chaque noeud, donc, entre les mains d'un attaquant privilégié, ils sont un moyen efficace d'exécuter le code dans tous les hôtes d'un cluster; la documentation officielle explique sa conception et les risques: DaemonSet dans la documentation de Kubernetes. D'autre part, l'utilisation de volumes hostPath pour monter le système de fichiers host dans un conteneur permet au processus dans le conteneur de manipuler directement les fichiers système: Auberge à Kubernetes.

Du côté des conteneurs et des runtimes, exposer l'API Docker sans authentification (généralement via le port 2375) est une pratique connue et dangereuse : cette API permet de gérer les conteneurs et de monter l'hôte du réseau s'il n'est pas protégé. Les guides officiels de Docker comprennent des recommandations de sécurité pour atténuer ces scénarios : Sécurité des moteurs Docker.

Que peuvent faire les équipes et les administrateurs en ce moment? Tout d'abord, l'audit permet et l'accès au niveau du cluster : examiner qui peut créer DaemonSet ou modifier l'espace de noms kube-system, et appliquer des contrôles RBAC stricts pour empêcher les processus non autorisés de créer des objets avec des privilèges élevés. Il est essentiel de bloquer l'accès non authentifié à l'API d'exécution du conteneur et de segmenter le réseau afin qu'un hôte engagé ne puisse pas invoquer des API administratives dans le sous-réseau. Surveiller la création de ressources inhabituelles (noms, images alpines exécutées avec des privilèges, /) et établir des alertes sur les connexions SSH sortantes avec des options qui désactivent les vérifications d'impression sont pratiques et des contre-mesures à impact élevé.

En outre, les pratiques d'hygiène de base restent essentielles : rotation et protection des clés privées, désactivation du sudo sans mot de passe, mise à jour et correctifs des outils de la chaîne d'approvisionnement utilisés (si l'acteur s'est déjà montré intéressé aux projets open source, protéger ces flux est critique) et stockage des dossiers d'audit en dehors de la portée des nœuds individuels pour faciliter la recherche post-engagement.

Cette campagne rappelle que la sécurité dans les environnements cloud-natifs n'est plus seulement une question d'application de correctifs : il est nécessaire de concevoir des défenses qui prennent en compte les mécanismes d'orchestration, l'exposition des API d'exécution et la possibilité qu'un adversaire combine des techniques de persistance et de destruction. Pour ceux qui veulent approfondir l'analyse technique et les indicateurs, le rapport Aikido fournit une ventilation détaillée: lire le rapport d'Aikido.

Si vous gérez l'infrastructure critique ou les grappes Kubernetes, agissez en priorité : examinez les règles RBAC, fermez et assurez-vous que les API de Docker ne sont pas accessibles sans protection, surveillez les journaux et alertes pour un comportement anormal, et préparez un plan de réponse qui prévoit la possibilité d'effacer les données de masse. La combinaison d'intentions politiques et de techniques automatisées révélées par cette campagne accroît le risque et nécessite une intervention coordonnée entre les gestionnaires, les équipes de sécurité et les fournisseurs de services.