Vol d’identité machine dans le cloud : quand vos instances deviennent vos ennemies

Catégories

🔍 Licence d'Utilisation 🔍

Sauf mention contraire, le contenu de ce blog est sous licence CC BY-NC-ND 4.0.

© 2025 à 2042 Sébastien Gioria. Tous droits réservés.

Dans le cloud, vos machines ont une identité (IAM roles, service accounts, managed identities…). Si un attaquant compromet une instance, il hérite de ses permissions et peut pivoter dans tout votre environnement cloud.

🎯 Objectif des attaquants : exploiter les identités machines sur-privilégiées pour accéder à des ressources critiques (bases de données, secrets, buckets S3, Key Vaults…).

Traitez chaque identité machine comme un utilisateur privilégié. Un rôle IAM trop permissif est aussi dangereux qu’un mot de passe admin partagé.

⚠️ Le metadata service (169.254.169.254) est la cible #1 des attaquants en cas de SSRF. Protégez-le comme votre annuaire Active Directory.

🔎 Scénarios d’Attaque

1. Instance compromise avec rôle IAM sur-privilégié

  • Vecteur : vulnérabilité applicative (RCE, SSRF) sur une EC2/VM Azure
  • Exploitation : récupération des credentials temporaires via metadata service
  • Impact : accès à tous les services autorisés par le rôle IAM

2. SSRF vers metadata service

  • Vecteur : faille SSRF dans une application web
  • Exploitation : http://169.254.169.254/latest/meta-data/iam/security-credentials/
  • Impact : vol des credentials IAM sans besoin de RCE

3. Token de service account Kubernetes exfiltré

  • Vecteur : pod compromise ou misconfiguration
  • Exploitation : lecture du token monté dans /var/run/secrets/kubernetes.io/serviceaccount/token
  • Impact : accès à l’API Kubernetes avec les permissions du service account

4. Managed Identity abuse (Azure)

  • Vecteur : instance compromise avec managed identity
  • Exploitation : appel à http://169.254.169.254/metadata/identity/oauth2/token
  • Impact : obtention de tokens Azure AD pour accéder à d’autres ressources

5. IMDSv1 exploitation (AWS)

  • Vecteur : SSRF ou accès réseau non filtré
  • Exploitation : requêtes non authentifiées vers metadata service v1
  • Impact : récupération de credentials IAM sans barrières

🧪 Exemples d’Attaques Récentes (2024-2025)

Vecteur initial Technique d’exploitation Identité compromise Impact observé Référence
RCE sur EC2 WordPress Metadata service IMDSv1 Rôle IAM admin S3 Exfiltration 50TB données clients Capital One 2019
SSRF dans API Gateway Proxy vers 169.254.169.254 Rôle Lambda sur-privilégié Accès Secrets Manager, pivot multi-comptes AWS SSRF Advisory
Pod Kubernetes malveillant Token service account par défaut ClusterAdmin rights Compromission totale cluster K8s Tesla Breach 2018
VM Azure avec managed identity Token OAuth2 via metadata Contributor sur subscription Création backdoor VMs, crypto-mining ChaosDB 2021
Container escape Accès host metadata service Node IAM role Destruction infrastructure via API calls TeamTNT Campaigns

📰 Cas d’incidents notables

Capital One Data Breach (2019) - Cas d’école SSRF/IMDS

Tesla Kubernetes Cryptojacking (2018)

  • Contexte : Compromission d’un cluster Kubernetes non sécurisé
  • Technique : Console Kubernetes publique sans authentification + credentials AWS dans pods
  • Impact : Mining de cryptomonnaie, accès à données propriétaires sur S3
  • Analyse : RedLock - Tesla Kubernetes Breach

Uber GCP Token Leak (2016)

  • Contexte : Credentials GCP exposés dans un repository GitHub privé
  • Technique : Service account keys hardcodées dans le code source
  • Impact : Accès non autorisé à 57 millions de comptes clients et chauffeurs
  • Leçon : Ne jamais stocker de credentials long-terme, utiliser Workload Identity

Microsoft Azure Cosmos DB Vulnerability “ChaosDB” (2021)

  • Contexte : Vulnérabilité dans Jupyter Notebook feature de Cosmos DB
  • Technique : Exploitation permettant l’accès aux primary keys d’autres tenants
  • Impact : Accès potentiel à des milliers de bases de données Cosmos DB
  • Analyse : Wiz - ChaosDB Explained

TeamTNT Container Escape Campaigns (2020-2024)

  • Contexte : Groupe APT ciblant les environnements conteneurisés
  • Technique : Container escape + accès au metadata service du host + vol de credentials IAM
  • Impact : Compromission multi-cloud (AWS, Azure, GCP), cryptomining, botnet
  • Analyse : TeamTNT Analysis

✅ Bonnes pratiques

🔐 Principe du moindre privilège

AWS

  • Scoper les rôles IAM au strict minimum : pas de wildcard * sur les actions
  • Utiliser IMDSv2 : requiert un token session (protection SSRF) 
    # Forcer IMDSv2 sur toutes les instances
aws ec2 modify-instance-metadata-options \
  --instance-id i-xxxxx \
  --http-tokens required \
  --http-put-response-hop-limit 1
  • Condition sur les rôles : restreindre l’usage avec des conditions IAM (IP source, VPC, tags…)
  • Pas de credentials long-terme : utiliser exclusivement les rôles IAM

Azure

  • Managed identities uniquement : pas de service principals stockés dans les VMs
  • RBAC granulaire : assigner les rôles au niveau ressource, pas subscription
  • Conditional Access : restreindre les tokens aux IPs/VNets autorisés
  • Désactiver l’héritage de rôles : éviter les permissions transitives non maîtrisées

GCP

  • Service accounts dédiés : un par workload, pas de réutilisation
  • Workload Identity : lier les pods K8s à des service accounts GCP spécifiques
  • Conditions IAM : restreindre l’usage par IP, VPC, ressource source
  • Pas de clés téléchargées : utiliser exclusivement l’authentification automatique

Kubernetes

  • Désactiver automounting des tokens : automountServiceAccountToken: false par défaut
  • RBAC strict : pas de cluster-admin sauf exceptions justifiées
  • Service accounts dédiés : un par pod/déploiement
  • Pod Security Standards : enforcer restricted profile

🛡️ Défense en profondeur

Segmentation réseau

  • Network Policies (K8s) : limiter les flux entre pods
  • Security Groups/NSG : bloquer l’accès au metadata service depuis Internet
  • Private endpoints : forcer le passage par des endpoints privés pour les services critiques
  • Firewall rules : interdire les sorties non autorisées

Détection et monitoring

  • CloudTrail/Azure Activity Logs : alertes sur appels API suspects
    • Accès à AssumeRole depuis IPs inhabituelles
    • Appels répétés à GetSecretValue
    • Modifications de permissions IAM
  • GuardDuty/Defender for Cloud : détection comportementale
  • Audit logs Kubernetes : surveiller les accès aux secrets et tokens
  • SIEM avec règles spécifiques :
    • Accès metadata service depuis conteneurs
    • Escalation de privilèges
    • Mouvement latéral inter-services

Durcissement des workloads

  • Immutable infrastructure : pas de SSH/RDP, tout via code
  • Runtime security : Falco, Sysdig pour détecter les comportements anormaux
  • Secrets externes : HashiCorp Vault, AWS Secrets Manager avec rotation automatique
  • Chiffrement : données au repos et en transit systématiquement

👁️ Surveillance et audit

Audits réguliers

  • IAM Access Analyzer (AWS) : détecter les permissions trop larges
  • Azure AD Access Reviews : valider périodiquement les accès
  • GCP Policy Analyzer : identifier les permissions non utilisées
  • CARTA (Continuous Adaptive Risk and Trust Assessment) : réévaluation permanente des risques

Détection d’anomalies

  • Baseline comportementale : alerter sur déviations
  • Machine learning : détecter les patterns d’attaque (AWS GuardDuty ML)
  • Threat hunting : recherche proactive de compromissions

Tests et validation

  • Red team exercises : simuler les attaques SSRF/metadata abuse
  • Chaos engineering : valider la résilience des contrôles
  • Penetration testing cloud : audits externes réguliers

🛠️ Outils & Solutions

Détection et prévention

  • AWS GuardDuty : détection de menaces basée sur ML
  • Azure Defender for Cloud : protection workloads cloud
  • GCP Security Command Center : visibilité et détection
  • Wiz / Orca Security / Prisma Cloud : CSPM avec détection IMDS abuse
  • Falco : runtime security Kubernetes

Audit et conformité

  • Prowler : audit de sécurité AWS automatisé
  • ScoutSuite : multi-cloud security auditing
  • CloudSploit : scans de configuration cloud
  • kube-bench / kube-hunter : audit sécurité Kubernetes

Gestion des secrets

  • HashiCorp Vault : gestion centralisée des secrets
  • AWS Secrets Manager / Azure Key Vault / GCP Secret Manager : secrets natifs cloud
  • External Secrets Operator (K8s) : synchronisation secrets externes vers K8s

📋 Checklist de sécurisation

✅ Immédiat

  • Auditer tous les rôles IAM/managed identities pour identifier les sur-privilèges
  • Forcer IMDSv2 sur toutes les instances AWS
  • Désactiver l’automounting des tokens par défaut dans Kubernetes
  • Activer CloudTrail/Activity Logs avec alertes sur actions sensibles
  • Bloquer l’accès au metadata service depuis Internet via Security Groups

✅ Court terme

  • Implémenter le principe du moindre privilège sur tous les workloads
  • Déployer GuardDuty/Defender for Cloud avec règles personnalisées
  • Migrer les secrets hardcodés vers des gestionnaires dédiés
  • Mettre en place des Network Policies restrictives (K8s)
  • Rotation automatique des secrets critiques

✅ Moyen terme

  • Implémenter Workload Identity (GCP) ou IRSA (AWS) pour Kubernetes
  • Déployer une solution de runtime security (Falco, Sysdig)
  • Audits réguliers automatisés avec Prowler/ScoutSuite
  • Red team exercises ciblés sur vol d’identité machine
  • Mise en place d’un programme de threat hunting cloud
  • Formation des équipes sur les risques spécifiques cloud
  • Documentation des procédures d’incident response cloud
  • Tests de reprise après compromission d’identité machine

🔗 Ressources complémentaires

Guides et standards

Outils open source

LinkedIn Reddit