Go malware Campaign est distribué via les modules Go et les fournisseurs Terraform

Les chercheurs en sécurité ont détecté une campagne qui distribue un malware écrit dans les modules Go through Go et, pour la première fois documenté publiquement, par l'intermédiaire de fournisseurs publiés dans le registre Terraform de HashiCorp. Ce qui est confirmé par analyse technique de différents équipements (Aikido, JFrog, SafeDep et autres) est que les paquets légitimes ont été hachés ou publiés avec des dépendances malveillantes qui, en se joignant à des projets, mettent en œuvre un binaire Go qui partage l'infrastructure de commande et de contrôle avec les versions précédentes observées dans npm et PyPI.

L'échantillon a été trouvé dans au moins deux modules Go et deux fournisseurs Terraform - vecteurs qui permettent aux attaquants d'atteindre à la fois les développeurs et les environnements d'infrastructure - et l'échantillon réutilise des mécanismes sophistiqués: deux canaux C2 simultanés (un basé sur une chaîne de blocs de testnet et un sur l'API Slack), cryptographie asymétrique pour protéger la charge utile et les contrôles d'exécution qui activent la charge utile uniquement dans des conditions spécifiques. Le registre des fournisseurs de HashiCorp est disponible ici : https: / / registry.terraform.io /.

Fonctionnement technique (confirmé par l'analyse): Lors de l'exécution, les logiciels malveillants collectent les informations du système (hardware, SO, nom d'hôte, disponibilité des nœuds) et les envoient à un canal contrôlé par l'attaquant sur Slack à l'aide de l'API (la technique profite des appels répétés pour les conversations de fin de course.histoire): https: / / api.slack.com / methods / conversations. historique. Puis il génère une clé éphémère et combine cette clé avec deux clés publiques des attaquants pour dériver des clés partagées qui protègent la communication entre le client et l'opérateur. En parallèle, l'agent consulte toutes les quelques secondes un contrat intelligent dans le réseau de test Etheum (Arbitrum Sepolia, selon les rapports) à la recherche de commandes chiffrées qui peuvent déchiffrer et exécuter en code Go ou JavaScript. La consultation sur le testnet peut être vérifiée auprès de scouts tels que Sepolia : https: / / sepolia.etherscan.io /.

Caractéristiques qui compliquent l'analyse: Une partie de la charge utile est cryptée avec une clé asymétrique et ne se décompose que dans des conditions spécifiques (par exemple la résolution d'un système linéaire spécifique ou la performance d'une opération cryptographique particulière), suggérant une conception d'opérations dirigées ou empêchant les chercheurs qui trouvent le front sans les éléments contextuels qui activent la charge utile. Des rapports indiquent également que les agresseurs utilisent des mécanismes pour gonfler les compteurs de téléchargement par l'intermédiaire des travailleurs de GitHub Actions, en cherchant l'apparence de légitimité.

Les vecteurs d'entrée documentés comprennent les techniques d'ingénierie sociale : offres de faux emplois, entrevues à distance et tâches de programmation qui obligent la victime à inclure une dépendance qui introduit la porte arrière. Le matériel de sécurité a observé la même tactique appliquée aux dépôts et aux paquets en npm, PyPI et maintenant Terraform / Go, qui montre un modèle de réutilisation de la chaîne d'approvisionnement du logiciel.

Qui il affecte et pourquoi il importe: les développeurs qui incorporent des unités tierces sans vérification suffisante, l'équipement utilisant des fournisseurs et des organisations Terraform tiers avec CI / CD coureurs (GitHub Actions, etc.) sont les plus exposés. Un fournisseur malveillant Terraform a le potentiel d'atteindre les secrets de production (p. ex. les états, les références et les fournisseurs de cloud) plus directement qu'une bibliothèque d'utilisateur final, de sorte que l'émergence de fournisseurs manipulés augmente le risque opérationnel.

Impacts réels plausibles (confirmés par rapport aux estimations): confirmé: exfiltration du système d'inventaire et établissement de canaux C2 doubles; estimé: exécution de modules livrés dynamiquement par les opérateurs (les chercheurs ont récupéré l'implantation mais pas toujours le code suivant, de sorte que les actions finales que les attaquants exécutés sur des machines compromises sont encore incertaines). La combinaison d'une chute morte dans la chaîne de verrouillage et d'une deuxième canalisation Slack réduit le risque pour l'opérateur, car les commandes peuvent être chiffrées de sorte que seuls certains clients les interprètent, limitant également la capacité d'interférence des tiers.

Plusieurs équipes ont noté des coïncidences avec des campagnes attribuées à des acteurs liés à la République populaire démocratique de Corée, tels que Graphalgo ou PolinRider. Il s'agit d'une attribution suggérée par des analystes externes.(ReversingLabs, Aikido et d'autres l'ont mentionné) mais, comme toujours dans les rapports de cybermenace, l'attribution technique n'est pas une certification absolue et doit être traitée avec prudence jusqu'à ce que des preuves opérationnelles plus publiques et vérifiables soient recueillies.

Que doit faire le lecteur maintenant (mesures concrètes et immédiates): et de réduire la dépendance et l'IC de manière pragmatique: 1) Dans les projets critiques, évitez d'accepter des changements dans les dépendances sans examen humain : faites SCA (analyse de composition logicielle) et comparez les signatures et les hachages; 2) renversez et faites pivoter les jetons et les lettres d'identité qui peuvent avoir été exposés dans les dépôts ou les actions, et limitez la portée des coureurs de CI; 3) activez MFA et de préférence les clés de sécurité dans les comptes de maintenance et de dépôt; 4) bloquez ou surveillez les connexions sortantes inhabituelles des coureurs de construction et des environnements de fonctionnement vers les PI et les domaines suspects (p. ex. PI cités dans certaines analyses), et limitez l'accès aux API comme Slack pour les robots non vérifiés; 5) auditez et limitez les fournisseurs Terraform : traitez les fournisseurs externes comme un code d'infrastructure critique et appliquez un examen par une tierce partie avant l'utilisation; 6) mettez en oeuvre les politiques SLSA / artefacts signés et la demande de bâtiments reproductibles pour empêcher les actions engagées ou les lettres d'identification des artefacts malveillants.

De plus, les détenteurs de paquets devraient examiner l'historique de l'accès à leurs comptes, vérifier les engagements non autorisés et faire pivoter tout titre de créance avec accès à plusieurs dépôts. Les équipes de sécurité devraient déployer la détection d'anomalies (signatures comportementales, sortie inattendue, accès aux API de messagerie et appels aux testnets avec des modes de scrutin fréquents) et préparer des livres de lecture pour désactiver les canaux C2 (jetons de rappel, contrats de blocage ou adresses impliqués dans des communications malveillantes).

Informations encore incertaines ou à confirmer: Les fonctions exactes des charges utiles après l'implantation récupérée n'ont pas été entièrement récupérées par les chercheurs - ils sont chiffrés et déchiffrés uniquement dans leur contexte - et la relation finale entre toutes les campagnes mentionnées et une attribution géopolitique ferme reste à analyser. On ne sait pas non plus à quelle échelle les attaquants opèrent avec les fournisseurs Terraform : les résultats actuels montrent des cas précis, mais il n'existe toujours aucune preuve publique d'abus massifs et soutenus à grande échelle.

Cet épisode renforce une leçon clé : la chaîne d'approvisionnement logicielle n'est plus seulement le code de bibliothèque ; elle inclut les fournisseurs d'infrastructure, les coureurs d'IC et les comptes de maintenance. Des mesures d'atténuation efficaces exigent des contrôles techniques, des comptes d'hygiène et une surveillance continue des infrastructures et des dispositifs.