Depuis de nombreuses années, les attaquants sont passés de l'utilisation de logiciels malveillants automatisés et personnalisés à des attaques qui impliquent un piratage pratique par le biais d'utilitaires qui existent déjà sur les ordinateurs. Cette approche, connue sous le nom de « living of the land », s'étend également à l'infrastructure cloud en exploitant les services et les outils que les fournisseurs mettent à disposition dans le cadre de leur écosystème. Des chercheurs de la société de réponse aux incidents Mitiga ont récemment montré comment l'agent AWS Systems Manager (SSM) pouvait être détourné par des attaquants et transformé en cheval de Troie d'accès distant (RAT). L'agent SSM est un outil que les clients du fournisseur américain peuvent déployer sur des instances EC2, des serveurs sur site, ainsi que des machines virtuelles dans d'autres clouds pour les gérer et les surveiller via son service Systems Manager.

« Le concept est simple : lorsqu'un attaquant réussit à obtenir l'exécution initiale sur un terminal qui a déjà un agent SSM installé, plutôt que de télécharger une porte dérobée ou un RAT commercial ou développé en interne, il peut l'exploiter pour contrôler le terminal, le transformant effectivement en un RAT lui-même », ont déclaré les chercheurs de Mitiga dans leur rapport. « En exécutant des commandes à partir d'un compte AWS distinct, détenu par des personnes malveillantes, les actions effectuées par l'agent SSM resteront cachées dans le compte AWS d'origine, ne laissant aucune trace de l'intrusion ».

Les raisons qui poussent à détourner un agent SSM

L'agent SSM est un outil puissant pour l'exécution de commandes à distance et la collecte de données sur la machine, comme le ferait un cheval de Troie. La différence est que l'agent SSM est open source, développé et signé numériquement par Amazon, et qu'il est préinstallé sur de nombreuses instances machines (AMI) que les clients peuvent déployer sur leurs instances EC2 comme Amazon Linux, SuSE Linux Enterprise, MacOS et Windows Server. Il est également présent dans certaines images système fournies par des tiers sur le marché AWS ou développées par la communauté. Le principal avantage pour les attaquants est que l'agent SSM est déjà inscrit sur la liste blanche de nombreuses solutions de détection et de réponse à incidents (EDR) ou d'antivirus susceptibles d'être déployées sur un serveur géré par AWS. Aucun des 71 moteurs antivirus de VirusTotal n'a signalé le binaire comme étant malveillant.

En outre, comme l'agent SSM peut être configuré pour communiquer avec un compte AWS spécifique, il apporte aux attaquants une option simple de commande et de contrôle sans avoir à développer ou à déployer une infrastructure supplémentaire qui serait généralement nécessaire pour héberger une interface de contrôle RAT. Tout ce dont ils ont besoin, c'est d'un compte AWS. L'interface PowerShell, native de Windows et conçue pour automatiser les tâches administratives, pourrait être utilisée en parallèle. Étant donné que PowerShell est si puissant et qu'il s'accompagne de son propre langage de script, il a été adopté au fil des ans par un très grand nombre d'attaquants, ce qui a obligé Microsoft à ajouter de plus en plus d'avertissements, de protections et d'alertes de sécurité. Néanmoins, il existe encore des frameworks entiers de post-exploitation et de mouvement latéral écrits en PowerShell, ainsi que des logiciels malveillants dont le code source est ouvert.

Faire tourner de multiples instances d'agents SSM

L'utilisation de l'agent SSM comme cheval de Troie ou porte dérobée n'est pas une idée nouvelle. D'autres ingénieurs cloud et chercheurs en sécurité ont mis en garde contre son potentiel d'abus. Cependant, Mitiga est allé plus loin en montrant comment détourner l'agent de manière plus subtile et même sans avoir d'accès root. La façon la plus directe d'abuser de l'agent SSM dans un scénario post-compromission où l'attaquant a déjà des privilèges root ou admin sur la machine, est d'arrêter le service et de le démarrer avec un nouveau code d'activation qui le lierait à un compte AWS contrôlé par l'attaquant et activerait son mode hybride. Dans ce cas, l'agent sera en mesure de mettre en place un mécanisme de persistance pour redémarrer le système. Le problème de cette approche est que le propriétaire du compte sous lequel tourne l'instance EC2 compromise pourra immédiatement se rendre compte que quelque chose ne va pas car il perdra l'accès SSM à cette machine sur son propre compte une fois que l'agent aura été détourné.

Pour résoudre ce problème, Mitiga a cherché des moyens de ne pas toucher à l'agent original et d'exécuter une deuxième instance malveillante se connectant au compte de l'attaquant. Bien que l'agent soit conçu pour ne pas s'exécuter s'il existe déjà un processus d'agent SSM, cela peut être contourné de plusieurs façons : en tirant parti de la fonctionnalité des espaces de noms Linux pour exécuter l'agent dans un espace de noms différent, ou en activant le mode « conteneur » pour la deuxième instance de l'agent qui ne nécessite pas de privilèges root. Le mode conteneur est limité car il ne dispose pas du module RunCommand mais il permet aux attaquants d'ouvrir une session à distance pour accéder à la machine.

Déploiement d'un deuxième processus d'agent SSM

Sur les machines Windows, les chercheurs ont réussi à lancer un deuxième processus d'agent SSM en configurant certaines variables d'environnement pour placer la configuration dans un emplacement différent. Ironiquement, une façon de déployer une seconde instance d'agent SSM sans avoir les privilèges root sur la machine elle-même est d'utiliser l'instance SSM existante et d'émettre des commandes à travers elle pour configurer la seconde, puisque l'agent fonctionne déjà avec des privilèges élevés. Cela nécessite un accès au compte AWS de la victime qui est déjà utilisé pour gérer la machine via SSM. Cela dit, la nécessité d'avoir un compte AWS pour contrôler un agent SSM détourné n'est pas forcément intéressante pour tous les attaquants.

Tout d'abord, s'ils utilisent le même compte pour contrôler plusieurs machines appartenant à différentes victimes, il suffit qu'un seul d'entre eux découvre la compromission, la signale à AWS et le compte sera suspendu. Il s'avère que l'agent SSM dispose de deux options de configuration appelées http_proxy et https_proxy qui peuvent être utilisées pour acheminer le trafic de l'agent SSM vers une adresse IP contrôlée par l'attaquant au lieu d'une adresse Amazon. Les chercheurs de Mitiga ont pu construire un serveur fictif qu'un pirate pourrait exécuter de son côté pour tirer parti de la fonction RunCommand sans s'appuyer sur le service SSM d'AWS.

Détecter et empêcher les attaques par l'agent SSM

Les chercheurs ont publié quelques indicateurs de compromission qui pourraient être utilisés pour détecter que deux instances d'agent SSM sont en cours d'exécution. Ils recommandent également de supprimer l'agent SSM de la liste d'autorisation de tout antivirus ou solution EDR afin qu'ils puissent analyser son comportement et ajouter des techniques de détection de ce type de détournement à leur solution SIEM.

« L'équipe de sécurité d'AWS a proposé une solution pour restreindre la réception des commandes du compte/organisation AWS d'origine à l'aide du point de terminaison Virtual Private Cloud pour Systems Manager », ont déclaré les chercheurs. « Si vos instances EC2 se trouvent dans un sous-réseau privé sans accès au réseau public via une adresse EIP publique ou une passerelle NAT, vous pouvez toujours configurer le service Systems Manager via un point de terminaison VPC. Ce faisant, vous pouvez vous assurer que les instances EC2 ne répondent qu'aux commandes émanant des mandants de leur compte AWS ou de leur organisation d'origine. Pour mettre en œuvre cette restriction de manière efficace, reportez-vous à la documentation relative à la politique des points d'extrémité VPC ».