Réseaux et infrastructures
Particuliers et entreprisesDétournement de ressources cloud
Cloud resource hijacking
Un accès cloud est détourné pour créer, exploiter ou exposer des ressources.
Je pense être concerné : que faire ?
Comprendre et agir
À la fin de cette lecture, vous pourrez expliquer le piège et choisir une première réaction adaptée à votre rôle. Aucun prérequis informatique n’est nécessaire.
Une situation concrète
Une clé d’accès publiée par erreur permet à un tiers de créer des ressources dans un compte cloud. Le propriétaire découvre une facture inhabituelle, mais l’attaquant a aussi pu consulter des données ou modifier les droits.
Comment cela fonctionne
Le détournement cloud exploite des accès ou configurations d’une plateforme hébergée. Il peut viser le stockage, les machines, les applications ou l’administration du compte. Le fournisseur peut fonctionner correctement alors qu’une identité du client est compromise. Le partage des responsabilités dépend du service utilisé : il faut savoir qui protège les comptes, les données et la configuration.
- Un accès cloud est compromis
Clé, compte ou autorisation trop large.
- Des API sont utilisées
Création, copie ou modification.
- Le compte supporte les conséquences
Données, disponibilité et dépenses.
Les signes qui doivent attirer l’attention
- Des clés, rôles ou ressources apparaissent sans besoin connu.
- La consommation et les dépenses augmentent.
- Des règles de partage ou de journalisation sont modifiées.
Ces signes invitent à vérifier la situation. Pris isolément, ils ne prouvent pas tous qu’une attaque a réussi.
Ce que vous pouvez faire
Vos premiers réflexes
Pour un compte d’hébergement personnel, activez la double authentification et les alertes de dépenses. Ne publiez pas vos clés d’accès dans un dépôt ou un document partagé.
Si vous êtes responsable du service ou de l’organisation
Limitez les droits des identités et conservez les journaux dans un espace protégé. Après une alerte, inspectez toutes les régions et ressources accessibles à la clé compromise.
Arrêter une machine suspecte ne retire pas une clé cloud encore valide.
À vous de décider
Vous supprimez les machines créées par l’intrus. Pourquoi peut-il en créer d’autres ?
Choisissez votre réponse et expliquez pourquoi avant de lire la correction.
Voir la réponse expliquée
Sa clé ou son compte peut rester valide. Il faut révoquer l’accès et retirer les permissions ajoutées, en plus de traiter les ressources non autorisées.
Analyser un cas technique
Pour les personnes qui développent, administrent ou analysent les systèmes concernés. Commencez par « Comprendre et agir » si ces notions sont nouvelles pour vous.
Étude de cas fictive
Une session cloud temporaire crée un accès durable
Une session du rôle BuildRole crée une clé pour un compte d’automatisation ancien. La session est temporaire, mais la clé créée peut rester utilisable après son expiration. Fermer la session initiale sans rechercher les identités et secrets qu’elle a créés laisserait donc un accès possible.
Il faut remonter de l’action d’administration à la session assumée, puis à l’identité qui l’a obtenue. L’émetteur de session, les politiques du rôle et les conditions de confiance servent à comprendre les droits réellement disponibles. Le nom du rôle ou de la clé n’établit pas leur légitimité. Une opération réalisée par une chaîne CI peut être normale, tout comme elle peut résulter d’un secret CI volé.
Les journaux d’administration montrent la création de clés et les changements de permissions. Ils ne couvrent pas automatiquement toutes les lectures d’objets ou de données. Vérifier la collecte des événements de données avant de conclure qu’aucune information n’a été consultée. Étendre l’enquête aux comptes, régions et services accessibles avec les nouvelles permissions.
Le déroulement en schéma
Faites défiler le diagramme pour suivre les échanges ; les noms des acteurs restent en haut. Sur petit écran, faites aussi défiler de gauche à droite.
- Action
AssumeRole ou fédération
Job ou client vers AWS STS
Trace événement STS
- Réponse
Session BuildRole émise
AWS STS vers Job ou client
Trace ARN et sourceIdentity
- Action
CreateAccessKey
Job ou client vers IAM
Trace eventID evt-42
- Réponse
Clé persistante créée
IAM vers Job ou client
Trace objet IAM
- Action
Accès objet à rechercher
Job ou client vers Ressource S3
Trace événements de données
- Action sur place
Correction des politiques
IAM
Trace état approuvé
- Refus / blocage
Test des anciens accès
Job ou client vers Ressource S3
Trace refus attendu
Comment repérer cette attaque
Indices à rechercher
Surveiller les créations de clés, les nouvelles relations de confiance, les extensions de permissions et les accès aux données par des sessions inhabituelles.
Éléments à croiser
Suivre le principal et la session qui créent un nouvel accès, puis les opérations réalisées avec cet accès. Rapprocher les identifiants non secrets disponibles ; ne jamais collecter la clé secrète elle-même.
Limites de l’interprétation
sourceIPAddress peut être celle d’un proxy ou d’un service AWS. Une opération tentée avec errorCode n’est pas une création réussie ; l’identité affichée peut être un rôle, pas la personne à l’origine de la fédération.
Comment réagir
Désactiver les clés créées illicitement, restaurer les politiques à partir d’un état fiable et traiter les sessions temporaires selon les mécanismes du service. Corriger la relation de confiance CI et le moindre privilège avant relance. Inspecter les autres régions, comptes et ressources accessibles au rôle, sans supposer que l’incident reste dans la région de l’alerte.
Vérifier la correction
Ces contrôles s’adressent à l’équipe responsable du système. Les simulations se préparent dans un environnement de test autorisé ; la lecture du cas ne nécessite aucune manipulation.
- Dans un compte de test, vérifier qu’un rôle de build ne peut créer aucune clé IAM.
- Contrôler la collecte des événements de données sur les ressources réellement sensibles.
- Tester les anciens identifiants après confinement et vérifier la continuité du déploiement légitime.
À vous de raisonner
La session temporaire compromise expire, mais elle a créé une clé d’accès. L’expiration suffit-elle à fermer l’incident ?
Formulez votre décision et l’élément qui la justifie avant d’ouvrir la correction.
Comparer avec le raisonnement expliqué
Non : la clé peut rester utilisable. Recherchez les identités, clés et permissions créées, retirez les accès concernés et vérifiez leur refus. Contrôlez séparément la couverture des lectures de données ; un journal d’administration silencieux ne prouve pas qu’aucun objet n’a été lu.
Consulter les détails techniques
Pour aller plus loin après l’étude du cas : les extraits servent à s’exercer à la lecture des traces ; le guide de collecte aide les personnes qui disposent des outils et des accès nécessaires.
Lire les extraits commentés — reconstitution fictive
Ces extraits utilisent des valeurs fictives. Certains reprennent des champs documentés ; d’autres regroupent plusieurs sources dans un format pédagogique. Ce ne sont pas des exports bruts à retrouver tels quels dans vos outils. Commencez par les champs expliqués, puis retrouvez-les dans les extraits.
sessionIssuer- Rôle ayant fourni la session temporaire, pas automatiquement identité humaine.
requestParameters- Paramètres de la demande : à lire avec le résultat et les erreurs éventuelles avant de conclure qu’elle a abouti.
Identité de session dans un événement CloudTrail
JSONExtrait synthétique volontairement réduit ; conserver eventID, eventTime et l’événement complet dans l’enquête.
{
"eventSource":"iam.amazonaws.com","eventName":"CreateAccessKey",
"eventID":"evt-42","eventTime":"2026-09-17T10:02:00Z",
"userIdentity":{
"type":"AssumedRole","principalId":"ROLEID:build-17",
"arn":"arn:aws:sts::111122223333:assumed-role/BuildRole/build-17",
"sessionContext":{"sessionIssuer":{"arn":"arn:aws:iam::111122223333:role/BuildRole"}}
},
"requestParameters":{"userName":"automation-legacy"},
"sourceIPAddress":"198.51.100.24"
}Préparer une collecte dans votre environnement
Choisissez les sources qui correspondent à vos outils et à votre périmètre d’intervention. Cette liste n’est pas un équipement requis pour comprendre la fiche. Vérifiez que les journaux nécessaires étaient activés pendant la période étudiée. Conservez l’export original, son fuseau horaire et sa provenance dans un espace à accès restreint ; travaillez sur une copie expurgée des secrets.
AWS — événements CloudTrail
- Où les trouver
- Console CloudTrail → Event history pour les événements de gestion disponibles ; pour une collecte plus large, consulter le trail ou l’event data store réellement configuré.
- Quoi relever
- Lire eventTime, eventSource, eventName, eventID, userIdentity, sourceIPAddress, requestParameters et errorCode s’il existe. Pour un rôle assumé, examiner aussi sessionContext et sessionIssuer.
- Accès et prérequis
- Droits de lecture AWS. Les événements de données, notamment les lectures d’objets S3, nécessitent une collecte dédiée : leur absence dans Event history ne prouve pas qu’aucun objet n’a été lu.
Microsoft Entra ID — Sign-in logs
- Où les trouver
- Centre d’administration Entra → Entra ID → Monitoring & health → Sign-in logs. Examiner séparément les connexions interactives, non interactives et celles des applications si elles sont concernées.
- Quoi relever
- Si AWS est fédéré à Entra, rapprocher la connexion au fournisseur d’identité de l’obtention de la session cloud. Pour un autre fournisseur, demander ses événements de fédération équivalents.
- Accès et prérequis
- Rôle de lecture adapté, par exemple Reports Reader. Vérifier la période conservée et les exports disponibles ; une session applicative n’engendre pas nécessairement une nouvelle connexion Entra.
Dans l’histoire des cyberattaques
Groupes et campagnes documentés
Des faits réels pour situer ce mécanisme. Les années sont celles des faits ; chaque notice précise qui établit le lien avec le groupe ou la campagne.
- àGroupeTeamTNT
Des ressources cloud utilisées pour miner
Unit 42 documente le vol d’identifiants cloud et le déploiement de mineurs de cryptomonnaie dans des environnements compromis. Le détournement porte à la fois sur l’accès aux ressources et sur la puissance de calcul facturée à la victime.
Ce qu’établit la source. Campagnes attribuées à TeamTNT par Unit 42. Les chercheurs distinguent les identifiants recherchés par les outils et les usages qu’ils ont effectivement observés.
Consulter le rapport TeamTNT Operations Actively Enumerating Cloud EnvironmentsPalo Alto Networks Unit 42 · Publié le
- GroupeStorm-0558
Repères de nommage : Antique Typhoon depuis 2024 chez Microsoft
Des jetons falsifiés donnent accès à des messageries
À partir de mai 2023, des jetons d’authentification falsifiés permettent de consulter les courriels de plusieurs organisations. La confiance dans une signature et sa validation devient ici le point critique du contrôle d’accès.
Ce qu’établit la source. Microsoft attribue l’opération à Storm-0558. Il s’agit de jetons de services cloud, pas de tickets Kerberos : les deux mécanismes ne doivent pas être confondus.
Consulter le rapport Analysis of Storm-0558 techniques for unauthorized email accessMicrosoft · Publié le
Sélection de cas documentés, non exhaustive. Une technique peut être utilisée par de nombreux acteurs. Les cas fictifs de la fiche ne sont attribués à aucun de ces groupes.
Si vous pensez être concerné
- Révoquez les accès compromis depuis une identité fiable.
- Inventoriez les ressources et droits créés avant leur suppression.
- Examinez données, facturation et mécanismes de persistance.
Pour qualifier votre situation et être orienté : obtenir une assistance sur 17Cyber. Dans une organisation, prévenez aussi le responsable ou prestataire chargé de la sécurité.
Sources et repères pour approfondir
- MITRE ATT&CK — Cloud Accounts — attack.mitre.org
- AWS — userIdentity CloudTrail — docs.aws.amazon.com
- AWS — catégories d’événements — docs.aws.amazon.com
