Réseaux et infrastructures
Particuliers et entreprisesDétournement de ressources cloud
Cloud resource hijacking
Un compte ou une clé volée permet d’utiliser, de créer ou d’exposer des ressources cloud.
Je pense être concerné : que faire ?
Comprendre et agir
Découvrez le piège à partir d’un exemple, puis les gestes que vous pouvez faire. Vous pouvez suivre cette lecture sans connaissances en informatique.
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
Un détournement cloud utilise à mauvais escient les accès ou les réglages d’une plateforme hébergée. Il peut toucher le stockage, les machines, les applications ou l’administration du compte. Le fournisseur peut fonctionner normalement pendant qu’un compte du client est piraté. Les responsabilités varient selon le service : il faut identifier qui protège les comptes, les données et leur 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.
Si vous remarquez l’un de ces signes, vérifiez la situation. Un indice isolé ne suffit pas à prouver 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 ?
Prenez un moment pour répondre et expliquer votre choix, puis ouvrez la correction.
Voir la réponse expliquée
La clé ou le compte de l’intrus peut être encore valide. Retirez cet accès et les permissions ajoutées, en plus de supprimer les ressources non autorisées.
Analyser un cas technique
Ce cas s’adresse aux personnes qui développent, administrent ou analysent ces systèmes. Si vous découvrez le sujet, commencez par « Comprendre et agir ».
Étude de cas fictive
Une session cloud temporaire crée un accès durable
La session du rôle BuildRole crée une clé pour un ancien compte d’automatisation. La session est temporaire ; la clé peut, elle, rester valide après son expiration. Recherchez les identités et les secrets créés avant de considérer que la fermeture de la première session a retiré tous les accès.
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.
Quelles informations comparer
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.
Ce que ces indices ne permettent pas de conclure
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
L’équipe responsable du système peut utiliser ces contrôles dans un environnement de test autorisé. Vous pouvez lire et comprendre le cas sans effectuer ces manipulations.
- 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 ?
Quelle décision prendriez-vous, et sur quel indice vous appuieriez-vous ? Répondez 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
Les extraits permettent de s’exercer à lire les traces du cas. Si vous disposez des outils et des accès nécessaires, le guide de collecte vous aide aussi à rechercher ces informations.
Lire les extraits commentés (reconstitution fictive)
Ces extraits contiennent des valeurs fictives. Certains champs correspondent à ceux des outils documentés ; d’autres réunissent plusieurs sources pour faciliter l’explication. Vos propres exports pourront donc avoir une autre forme. Lisez d’abord les explications des champs, puis repérez-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
Utilisez les sources disponibles dans vos outils et auxquelles vous êtes autorisé à accéder. Vous pouvez comprendre la fiche sans posséder ces outils. Vérifiez que les journaux étaient activés pendant la période étudiée. Gardez l’export original avec son fuseau horaire et sa provenance dans un espace à accès restreint. Pour l’analyse, travaillez sur une copie dont vous avez retiré les 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
Ces cas réels montrent où ce mécanisme a été observé. Les années indiquent quand les faits ont eu lieu. Chaque notice précise la source qui les relie à un groupe ou à une campagne.
- àGroupeTeamTNT
Des ressources cloud utilisées pour miner
Unit 42 décrit le vol d’identifiants cloud puis l’installation de mineurs de cryptomonnaie dans les systèmes compromis. Les attaquants détournent les accès et utilisent une puissance de calcul dont la victime paie la facture.
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
Noms et appellations : Antique Typhoon depuis 2024 chez Microsoft
Des jetons falsifiés donnent accès à des messageries
À partir de mai 2023, des attaquants utilisent des jetons d’authentification falsifiés pour lire les courriels de plusieurs organisations. Le contrôle d’accès est trompé au niveau de la signature et de sa validation.
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
Cette sélection ne couvre pas tous les incidents. Plusieurs acteurs peuvent utiliser une même technique. Les exemples fictifs de la fiche ne décrivent les actions d’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 comprendre votre situation et trouver de l’aide : 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
