~10 minutes
Cet article fait partie de la série MITRE ATT&CK en pratique. Retrouvez la vue d’ensemble et le sommaire complet sur la page d’entrée de la série.
On constate que la plupart des équipes cloud appliquent la matrice Enterprise à leurs environnements Kubernetes. C’est mieux que rien, mais c’est incomplet : les techniques de compromission d’un cluster Kubernetes, d’une fonction Lambda ou d’une identité IAM n’ont pas d’équivalent dans un SI Windows classique. La matrice Cloud d’ATT&CK (et sa sous-matrice Containers) adresse précisément ces angles morts.
Un attaquant qui compromet un pod Kubernetes n’a pas besoin de Pass-the-Hash. Il lui faut un token de service account, un rôle RBAC mal configuré, et l’accès au metadata endpoint de l’instance cloud. La matrice Enterprise ne parle pas de tout ça.
Note du PandaRedacteur: et puis il faudrait être fou pour faire tourner du Windows dans des Kubes…
Les spécificités de la surface d’attaque cloud
L’architecture cloud change fondamentalement le modèle de menace. Voic quatre différences majeures par rapport à un SI Windows :
L’identité remplace le périmètre. Dans un SI classique, être dans le réseau interne donne un avantage énorme. Dans le cloud, chaque service a une identité (IAM role, service account, workload identity) ; c’est cette identité qui donne accès aux ressources. Compromettre une identité privilégiée depuis Internet est souvent aussi efficace que d’être dans le réseau.
La chaîne d’approvisionnement est une surface d’attaque majeure. Un pipeline CI/CD qui déploie en production depuis un dépôt git compromis, une image de base avec une backdoor, un package npm malveillant : les vecteurs supply chain sont omniprésents dans le cloud native.
Les APIs sont partout. Kubernetes expose une API. AWS expose des APIs. Chaque microservice expose une API. La découverte et l’exploitation de ces APIs sont des tactiques documentées dans ATT&CK Cloud.
L’éphémérité complique la forensique. Un conteneur qui vit 10 secondes ne laisse pas de trace dans les logs système. Sans instrumentation spécifique (eBPF, audit logs Kubernetes), les artefacts forensics sont perdus dès la fin du pod.
La matrice Cloud ATT&CK : techniques clés
Quelques Vecteurs d’attaque cloud naive
T1552.005 : Instance Metadata API, le secret le mieux gardé de AWS
Je detaille cette technique parce qu’elle est systématiquement sous-estimée. Chaque instance EC2, chaque pod EKS, chaque Cloud Run instance peut accéder au service de metadata interne via l’adresse 169.254.169.254. Ce service expose les credentials IAM temporaires associés au rôle de l’instance.
Scénario d’attaque :
- L’attaquant identifie une SSRF (Server-Side Request Forgery) dans un microservice exposé sur Internet
- Il forge une requête vers
http://169.254.169.254/latest/meta-data/iam/security-credentials/ - Le service metadata répond avec les credentials temporaires du rôle IAM de l’instance :
AccessKeyId,SecretAccessKey,Token - L’attaquant exporte ces credentials et les utilise depuis son infrastructure pour accéder à S3, DynamoDB, Secrets Manager ; tout ce que le rôle autorise
- Le rôle d’un nœud EKS avec accès aux secrets du cluster permet d’extraire tous les Kubernetes Secrets du cluster
La mitigation principale est IMDSv2 (Instance Metadata Service version 2) sur AWS : chaque requête au service metadata doit inclure un token généré par une requête PUT préalable. Une SSRF classique ne peut pas effectuer cette requête PUT ; le vecteur est fermé.
IMDSv2 doit être imposé par policy AWS Organizations. Sur les comptes sans cette policy, une seule instance avec IMDSv1 et une SSRF dans un de ses services suffit à compromettre le rôle IAM complet.
+Note du PandaRedacteur: et c’est pour cela qu’il faut se prémunir des attaques SSRF qui sont sinon devastatrices !
T1610 : Deploy Container, la persistance invisible dans Kubernetes
Un attaquant qui a compromis un nœud Kubernetes ou un token de service account avec les permissions adéquates peut créer un pod directement via l’API Kubernetes. Ce pod peut monter le système de fichiers hôte, utiliser un service account privilégié, ou désactiver tous les security contexts.
Ce pod a accès complet au système de fichiers de l’hôte, aux processus de l’hôte, et au réseau de l’hôte. La détection passe par les admission controllers Kubernetes (OPA Gatekeeper, Kyverno) qui bloquent à l’admission les pods avec privileged: true ou hostPID: true.
Note du PandaRedacteur: je vous invite a aller faire un tour sur la mini-série sur kubernetes que j’ai publié pour bien comprendre la sécurité autour des environnements Kubes
T1190 + T1525 : Supply Chain via le pipeline CI/CD, la bombe à retardement
Ce vecteur est l’un des plus sophistiqué et l’un des plus difficile à détecter en environnement cloud .
Scénario de supply chain compromise :
- L’attaquant compromet un compte GitHub d’un développeur (credential stuffing sur un leak précédent)
- Ce compte a accès au dépôt d’une image de base utilisée dans plusieurs projets
- Une backdoor est injectée dans le Dockerfile ; un curl vers un serveur C2 lors du démarrage du conteneur
- Le pipeline CI/CD rebuild automatiquement l’image et la pousse dans le registry interne
- Les prochains déploiements de production incluent l’image compromise
- Chaque pod démarré établit un reverse shell vers le serveur C2 de l’attaquant
Mitigation : signature d’images avec Sigstore/Cosign, vérification des signatures à l’admission Kubernetes, scan systématique des images avant push (Trivy dans le pipeline), et politique de registry qui n’accepte que des images signées depuis le CI interne.
Mapping ATT&CK pour une architecture cloud type
graph TD
A["🌐 Internet\nUtilisateur"] --> B["API Gateway\n(Load Balancer)"]
B --> C["Service A\n(pod Kubernetes)"]
B --> D["Service B\n(Lambda)"]
C --> E["Base de données\n(RDS)"]
C --> F["Storage\n(S3)"]
D --> G["Queue\n(SQS)"]
subgraph ATT["Vecteurs ATT&CK Cloud"]
T1["T1190\nSSRF → RCE\nsur Service A"]
T2["T1552.005\nMetadata API\n→ vol IAM role"]
T3["T1078.004\nCompromission\ncredentials IAM"]
T4["T1610\nDéploiement\npod hostile"]
end
T1 -.->|"compromet"| C
T2 -.->|"depuis"| C
T3 -.->|"accès direct"| F
T4 -.->|"propagation"| E
style ATT fill:#fff3cd,stroke:#ffc107
style T1 fill:#f8d7da,stroke:#dc3545
style T2 fill:#f8d7da,stroke:#dc3545
style T3 fill:#f8d7da,stroke:#dc3545
style T4 fill:#fff3e0,stroke:#fd7e14
- ✓ IMDSv2 obligatoire sur toutes les instances : une SSRF + IMDSv1 = compromission du rôle IAM de l'instance, game over.
- ✓ La chaîne CI/CD est une surface d'attaque (T1525) : signature Cosign + vérification à l'admission sont les contrôles minimaux.
- ✓ Les pods privilégiés doivent être bloqués à l'admission (T1610) : Kyverno ou OPA Gatekeeper en mode Enforce, pas Audit.
- ✓ Falco couvre le runtime (T1609) : détection comportementale dans les pods sans modification des images ; voir l'article Falco de cette série.
- ✓ L'identité remplace le périmètre en cloud native ; auditer les permissions IAM régulièrement est aussi important que patcher les CVE.