Le groupe de hackers TeamPCP cible les clusters Kubernetes à l’aide d’un script malveillant capable d’effacer toutes les machines configurées pour l’Iran.
Cette menace est à l’origine d’une attaque récente sur la chaîne d’approvisionnement du scanner de vulnérabilités Trivy, ainsi que d’une campagne basée sur NPM nommée ‘CanisterWorm’, qui a débuté le 20 mars.
Payload de destruction sélective
Les chercheurs de la société de sécurité applicative Aikido indiquent que cette campagne utilise le même mécanisme de commande et de contrôle (C2), le code de porte dérobée et le chemin d’accès observés lors des incidents liés à CanisterWorm.
Cette nouvelle campagne se distingue par un payload destructeur ciblant spécifiquement les systèmes iraniens et en installant la porte dérobée CanisterWorm sur des nœuds situés ailleurs.
« Le script utilise le même ICP canister (tdtqy-oyaaa-aaaae-af2dq-cai[.]raw[.]icp0[.]io) que celui que nous avons documenté dans la campagne CanisterWorm. Même C2, même code de porte dérobée, même chemin de dépôt dans /tmp/pglog », déclare Aikido.
Le mouvement latéral natif à Kubernetes via DaemonSets correspond à la typologie connue du TeamPCP, mais cette variante inclut une nouveauté : un payload destructeur ciblant des systèmes iraniens.
Selon les chercheurs, le malware est conçu pour détruire toute machine correspondant au fuseau horaire et à la locale de l’Iran, peu importe la présence de Kubernetes.
Lorsque ces conditions sont remplies, le script déploie un DaemonSet nommé ‘Host-provisioner-iran’ dans ‘kube-system’, utilisant des conteneurs privilégiés et montant le système de fichiers racine hôte dans /mnt/host.
Chaque pod exécute un conteneur Alpine nommé ‘kamikaze’ qui efface tous les répertoires de premier niveau du système de fichiers hôte, avant de forcer un redémarrage.
Si Kubernetes est présent mais que le système n’est pas identifié comme iranien, le malware déploie un DaemonSet nommé ‘host-provisioner-std’, utilisant également des conteneurs privilégiés avec le système de fichiers hôte monté.
Au lieu de supprimer des données, chaque pod écrit une porte dérobée en Python sur le système de fichiers hôte et l’installe en tant que service systemd, assurant ainsi sa persistance sur chaque nœud.
Sur les systèmes iraniens sans Kubernetes, le malware supprime tous les fichiers de la machine, y compris les données systèmes, accessibles à l’utilisateur courant, en exécutant la commande rm -rf/ avec l’option –no-preserve-root. En cas de privilèges root insuffisants, il tente d’exécuter un sudo sans mot de passe.
source : Aikido
Dans les systèmes où aucune condition n’est remplie, le malware ne prend aucune mesure malveillante et quitte simplement.
Aikido a rapporté qu’une version récente du malware, qui utilise le même ICP canister, a omis le mouvement latéral basé sur Kubernetes et a plutôt opté pour la propagation via SSH, analysant les journaux d’authentification à la recherche de crédentials valides et utilisant des clés privées volées.
Les chercheurs ont mis en évidence des indicateurs clés de cette activité, tels que des connexions SSH sortantes avec l’option ‘StrictHostKeyChecking+no’ depuis des hôtes compromis, des connexions sortantes vers l’API Docker sur le port 2375 à travers le sous-réseau local, et des conteneurs privilégiés Alpine via une API Docker non authentifiée avec / monté comme hostPath.