Dans la campagne active Elektra-Leak, les attaquants recherchent les informations d’identification Amazon IAM dans les référentiels publics GitHub avant de les utiliser pour le cryptomining. Obtenez des conseils pour atténuer cette menace de cybersécurité.
Nouveau recherche de l’unité 42 de Palo Alto Networks expose une campagne d’attaque active dans laquelle un acteur malveillant recherche les informations d’identification Amazon IAM en temps réel dans les référentiels GitHub et commence à les utiliser moins de cinq minutes plus tard. La charge utile finale exécute le logiciel de cryptominage Monero personnalisé sur les machines virtuelles déployées sur les instances Amazon.
Sauter à:
Identifiants IAM exposés sur GitHub
GitHub offre à ses utilisateurs de nombreuses fonctionnalités pour gérer leur code au sein de la plateforme. L’une de ces fonctionnalités consiste à fournir une liste de tous les référentiels publics à tout utilisateur qui en fait la demande, ce qui aide les développeurs à suivre facilement les différents développements qui les intéressent. Le suivi se fait en temps réel et permet à quiconque, y compris les acteurs malveillants, de voir les nouveaux référentiels. dès qu’ils sont poussés vers GitHub.
VOIR: 8 meilleures solutions de gestion des identités et des accès (IAM) pour 2023 (TechRépublique)
Les chercheurs de l’unité 42 de Palo Alto Networks rapportent qu’il est possible de trouver des informations d’identification pour la gestion des identités et des accès d’Amazon Web Services dans les référentiels publics de GitHub et que ces informations d’identification sont activement recherchées par les cybercriminels.
Pour analyser le risque plus en profondeur, les chercheurs ont décidé de stocker les informations d’identification IAM sur GitHub et de vérifier toutes les activités autour de celui-ci. Ces tests de pot de miel ont révélé que les clés AWS divulguées, codées en base64 et stockées sur GitHub, n’étaient ni trouvées ni utilisées par les acteurs malveillants, qui récupéraient uniquement les clés AWS en texte clair cachées derrière une validation passée dans un fichier aléatoire.
Le pot de miel a permis aux chercheurs William Gamazo et Nathaniel Quist de détecter une campagne d’attaque particulière commençant dans les cinq minutes suivant la mise des informations d’identification sur GitHub.
Détails techniques sur cette campagne d’attaque
La campagne, baptisée EleKtra-Leak par les chercheurs en référence à la nymphe grecque des nuages Electra et à l’utilisation de Lek comme les 3 premiers caractères des mots de passe utilisés par l’acteur menaçant, est active depuis au moins décembre 2020, selon l’Unité 42. .
Une fois les informations d’identification IAM trouvées, l’attaquant effectue une série d’actions de reconnaissance pour en savoir plus sur le compte AWS auquel il accède (Figure A).
Figure A
Une fois ces actions effectuées, l’acteur malveillant crée de nouveaux groupes de sécurité AWS avant de lancer plusieurs instances Amazon Elastic Compute Cloud par région dans n’importe quelle région AWS accessible.
Gamazo et Quist ont pu observer plus de 400 appels d’API en sept minutes, tous effectués via une connexion VPN, montrant que l’acteur a automatisé l’attaque contre ces environnements de comptes AWS.
L’acteur malveillant visait les machines virtuelles cloud grand format pour effectuer leurs opérations, car celles-ci ont une puissance de traitement plus élevée, ce que recherchent les attaquants lorsqu’ils exécutent des opérations de cryptomining. L’acteur malveillant a également choisi des images privées pour Amazon Machine Images ; certaines de ces images étaient d’anciennes distributions Linux Ubuntu, ce qui amène les chercheurs à croire que l’opération remonte au moins à 2020.
L’auteur de la menace semble également bloquer les comptes AWS qui exposent régulièrement les informations d’identification IAM, car ce type de comportement peut provenir de chercheurs en menaces ou de systèmes de pots de miel.
Le but de cette campagne d’attaque : le Cryptomining
Une fois toutes les reconnaissances effectuées et les machines virtuelles lancées, une charge utile est livrée, téléchargée depuis Google Drive. La charge utile, cryptée sur le stockage Google, est déchiffrée lors du téléchargement.
L’unité 42 indique que la charge utile est un outil de cryptominage connu apparemment utilisé en 2021 et signalé par Intezer, société spécialisée dans les plateformes autonomes de systèmes d’opérations de sécurité. Dans la campagne d’attaque signalée, Intezer a indiqué qu’un acteur malveillant avait accédé à des instances Docker exposées sur Internet pour installer un logiciel de cryptominage permettant d’extraire la crypto-monnaie Monero. Ce logiciel de cryptominage personnalisé est le même que celui utilisé dans la nouvelle campagne exposée par Palo Alto Networks.
Le logiciel est configuré pour utiliser le pool de minage SupportXMR. Les pools de minage permettent à plusieurs personnes d’ajouter leur temps de calcul au même espace de travail, augmentant ainsi leurs chances de gagner plus de cryptomonnaie. Comme l’a déclaré Palo Alto Networks, le service SupportXMR ne fournit que des statistiques limitées dans le temps. Les chercheurs ont donc extrait les statistiques minières pendant plusieurs semaines, car le même portefeuille a été utilisé pour les opérations minières AWS (Figure B).
Figure B
Entre le 30 août 2023 et le 6 octobre 2023, un total de 474 mineurs uniques sont apparus, chacun étant une instance Amazon EC2 unique. Il n’est pas encore possible d’obtenir une estimation du gain financier généré par l’acteur menaçant, car Monero inclut des contrôles de confidentialité limitant le suivi de ce type de données.
Mesures automatisées de GitHub pour détecter les secrets
GitHub recherche automatiquement les secrets dans les fichiers stockés sur la plateforme et informe les fournisseurs de services des secrets divulgués sur GitHub.
Au cours de leur enquête, Gamazo et Quist ont remarqué que les secrets qu’ils stockaient intentionnellement sur GitHub, car les données du pot de miel pour leurs recherches avaient effectivement été détectées avec succès par GitHub et signalées à Amazon, qui à son tour a automatiquement appliqué en quelques minutes un politique de quarantaine qui empêche les attaquants d’effectuer des opérations telles que l’accès à AWS IAM, EC2, S3, Lambda et Lightsail.
Pendant le processus de recherche, l’unité 42 laissait la politique de quarantaine en place et étudiait passivement les tests des comptes par les attaquants ; Ensuite, la politique a été abandonnée pour étudier l’ensemble de la chaîne d’attaque.
Les chercheurs écrivent qu’ils « pensent que l’acteur malveillant pourrait être en mesure de trouver des clés AWS exposées qui ne sont pas automatiquement détectées » et que, selon leurs preuves, les attaquants l’ont probablement fait, car ils pourraient mener l’attaque sans aucune politique d’interférence. Ils déclarent également que « même lorsque GitHub et AWS sont coordonnés pour mettre en œuvre un certain niveau de protection en cas de fuite de clés AWS, tous les cas ne sont pas couverts » et que d’autres victimes potentielles de cet acteur menaçant auraient pu être ciblées de manière différente.
Comment atténuer ce risque de cybersécurité
Les informations d’identification IAM ne doivent jamais être stockées sur GitHub ou sur tout autre service ou stockage en ligne. Les informations d’identification IAM exposées doivent être supprimées des référentiels et de nouvelles informations d’identification IAM doivent être générées pour remplacer celles divulguées.
Les entreprises doivent utiliser des informations d’identification de courte durée pour exécuter toute fonctionnalité dynamique dans un environnement de production.
Les équipes de sécurité doivent surveiller les référentiels GitHub utilisés par leurs organisations. Audit Les événements de clonage qui se produisent sur ces référentiels doivent être effectués car il est nécessaire pour les acteurs malveillants de cloner d’abord les référentiels pour afficher leur contenu. Cette fonctionnalité est disponible pour tous les comptes GitHub Enterprise.
Une analyse dédiée et personnalisée des secrets sur les référentiels doit également être effectuée en permanence. Des outils tels que Truffière pourrait aider dans cette tâche.
S’il n’est pas nécessaire de partager publiquement les référentiels de l’organisation, les référentiels GitHub privés doivent être utilisés et accessibles uniquement au personnel de l’organisation. L’accès aux référentiels privés GitHub doit être protégé par une authentification multifactorielle pour éviter qu’un attaquant y accède avec des informations de connexion divulguées.
Divulgation: Je travaille pour Trend Micro, mais les opinions exprimées dans cet article sont les miennes.
