Des chercheurs en cybersécurité ont découvert une nouvelle technique de post-exploitation dans Amazon Web Services (AWS) qui permet à l’agent AWS Systems Manager (agent SSM) d’être exécuté comme un cheval de Troie d’accès à distance sur les environnements Windows et Linux
« L’agent SSM, un outil légitime utilisé par les administrateurs pour gérer leurs instances, peut être réutilisé par un attaquant qui a obtenu un accès à privilèges élevés sur un point de terminaison avec l’agent SSM installé, pour mener des activités malveillantes de manière continue », a déclaré Mitiga. ont déclaré les chercheurs Ariel Szarf et Or Aspir dans un rapport partagé avec The Hacker News.
« Cela permet à un attaquant qui a compromis une machine, hébergée sur AWS ou n’importe où ailleurs, de maintenir l’accès à celle-ci et d’effectuer diverses activités malveillantes. »
SSM Agent est un logiciel installé sur les instances Amazon Elastic Compute Cloud (Amazon EC2) qui permet aux administrateurs de mettre à jour, de gérer et de configurer leurs ressources AWS via une interface unifiée.
Les avantages de l’utilisation d’un agent SSM en tant que cheval de Troie sont multiples dans la mesure où il est approuvé par les solutions de sécurité des terminaux et élimine le besoin de déployer des logiciels malveillants supplémentaires susceptibles de déclencher la détection. Pour brouiller davantage les pistes, un acteur malveillant pourrait utiliser son propre compte AWS malveillant comme commande et contrôle (C2) pour superviser à distance l’agent SSM compromis.
Les techniques de post-exploitation détaillées par Mitiga présupposent qu’un attaquant dispose déjà des autorisations pour exécuter des commandes sur le point de terminaison Linux ou Windows sur lequel un agent SSM est également installé et en cours d’exécution.
Plus précisément, cela implique l’enregistrement d’un agent SSM pour qu’il s’exécute en mode « hybride », lui permettant de communiquer avec différents comptes AWS autres que le compte AWS d’origine sur lequel l’instance EC2 est hébergée. Cela oblige l’agent SSM à exécuter des commandes à partir d’un compte AWS appartenant à l’attaquant.
Une approche alternative utilise la fonction d’espaces de noms Linux pour lancer un deuxième processus d’agent SSM, qui communique avec le compte AWS de l’attaquant, tandis que l’agent SSM déjà en cours d’exécution continue de communiquer avec le compte AWS d’origine.
Enfin et surtout, Mitiga a constaté que la fonctionnalité de proxy SSM pouvait être utilisée de manière abusive pour acheminer le trafic SSM vers un serveur contrôlé par l’attaquant, y compris un point de terminaison de compte non AWS, permettant ainsi à l’auteur de la menace de contrôler l’agent SSM sans avoir à s’appuyer sur Infrastructure AWS.
Il est recommandé aux organisations de supprimer les fichiers binaires SSM de la liste d’autorisation associée aux solutions antivirus afin de détecter tout signe d’activité anormale et de s’assurer que les instances EC2 répondent aux commandes provenant uniquement du compte AWS d’origine à l’aide du point de terminaison Virtual Private Cloud (VPC) pour les systèmes. Directeur.
« Après avoir contrôlé l’agent SSM, les attaquants peuvent mener des activités malveillantes, telles que le vol de données, le cryptage du système de fichiers (en tant que ransomware), l’utilisation abusive des ressources des terminaux pour l’extraction de crypto-monnaie et la tentative de propagation à d’autres terminaux du réseau – le tout sous couvert d’utiliser un logiciel légitime, l’Agent SSM », ont déclaré les chercheurs.