L’une des sessions les plus marquantes à laquelle j’ai assisté lors du Re:Invent 2024 portait sur la gestion des menaces liées aux ransomwares (rançongiciel, dans la langue de Molière 😉) sur AWS. Animée par Kyle Dickinson, Senior Security SA spécialisé en Threat Detection and Incident Response, cette session a traité de stratégies concrètes et efficaces pour faire face à ces attaques.
Dans cet article, je vous propose un tour d’horizon des principales recommandations pour détecter, prévenir et réagir aux attaques de ransomwares sur AWS, en abordant les meilleures pratiques pour protéger vos environnements sur AWS.
Si ce sujet vous intéresse, je vous recommande vivement de poursuivre la lecture avec les quelques ressources mentionnées en fin d’article.
Comprendre la menace
Les ransomwares exploitent des vulnérabilités pour chiffrer ou supprimer des données, ou encore exfiltrer des informations sensibles afin de les monnayer.
Sur AWS, l’exploitation de credentials IAM compromis (comme des Access Keys / Secret Keys) est l’un des vecteurs d’attaque les plus fréquents.
Les buckets S3 sont particulièrement vulnérables à ce type d’attaques, car une fois qu’une AK/SK a été compromise, il ne faut pas plus de quelques secondes pour effacer complètement un bucket S3.
Cependant, les ransomwares peuvent aussi cibler plus classiquement les EC2, EBS, RDS ou les différents systèmes de fichiers. Sur EC2, le principal vecteur d’attaque est l’exploitation de vulnérabilités dans les applications hébergées pour obtenir des credentials temporaires ou effectuer des actions grâce à l’instance profile du serveur.
Se prémunir de l’attaque
Pour réduire le risque d’attaque et en limiter les potentiels impacts, les recommandations et bonnes pratiques de sécurités ci-dessous sont une première base
IAM
- Mettre en place une fédération d’identités avec MFA.
- Éviter autant que possible les credentials statiques comme les Access Keys et Secret Keys.
- Si leur utilisation est indispensable :
- Appliquer le principe du moindre privilège : le service IAM Access Analyzer aide à créer des politiques restrictives.
- Effectuer des rotations régulières.
- Ajouter une certaine friction au processus d’obtention d’une Secret Key (justification obligatoire, processus volontairement lourd).
- Documenter les usages d’access key et les justifications
- Utiliser des tags pour tracer les propriétaires, les justifications, les éventuelles expirations.
- Auditer régulièrement les clés et supprimer celles inutilisées.
S3
- Activer le MFA Delete.
- Bloquer l’accès public (comportement par défaut)
- Empêcher les suppressions et se reposer uniquement sur des lifecycle policies pour temporiser les actions de suppression.
- Activer les logs S3 Access et utiliser CloudTrail.
- Configurer des bucket policies restrictives (ex. source VPC ou filtres CIDR).
- Pour les objets en lecture seule (ex: backups) activer les locks
RDS
- Activer le Point-In-Time Recovery (PITR) pour restaurer les bases en cas d’incident.
- Protéger autant les backups que les bases de données: les attaquant vont souvent chercher à récupérer les données depuis un backup (en créant une nouvelle base ou en le partageant vers leur propre compte), car ils sont moins protégés.
EC2
- Pas d’instance profiles sur des EC2 publiques pour prévenir l’escalade de permissions.
- Interdire IMDSv1 et utiliser uniquement IMDSv2 si nécessaire.
Global
- Activer GuardDuty pour détecter les activités suspectes
- Mettre en place un plan de réponse à incident en s’appuyant sur les guides AWS.
- Utiliser des SCPs pour limiter globalement les permissions.
- Sauvegarder toutes les données sensibles (possiblement avec AWS Backups avec des locks), tester les restaurations.
- Configurer des alarmes CloudTrail pour surveiller les activités critiques.
- Segmenter les comptes AWS pour limiter le blast radius.
Détecter et analyser une attaque
La détection est la première ligne de défense. Une détection précoce peut permettre de limiter l’impact d’une attaque. Quelques indicateurs clés à surveiller :
- Diminution anormale du nombre d’objets dans S3.
- Augmentation des API calls de type découverte (ListBuckets, ListObjects).
- Partage de snapshots EC2 ou RDS.
- Chiffrement d’objets avec une clé KMS non autorisée.
- Transferts de données massifs ou inattendus.
- Augmentation des Access Denied dans CloudTrail
Réagir face à l'attaque
En cas d’attaque, il est fortement déconseillé de payer une rançon, car, au delà des aspects réglementaires et éthiques, il n’y a aucune garantie de récupérer ses données. Dans les faits, sur S3, dans 98% des cas étudiés par AWS, les données sont simplement supprimées, car c’est ce qu’il y a de plus simple pour l’attaquant, rendant leur récupération impossible sans sauvegardes.
L’analyse de métriques et de la facturation peut donner une indication sur une potentielle exfiltration des données.
Les premières actions à entreprendre en réaction sont:
- Vérifier sur nomoreransom.org s’il est possible de déchiffrer les fichiers.
- En cas de compromission d’une clé, créer une nouvelle paire, désactiver la clé compromise.
- Supprimer les utilisateurs IAM, rôles et policies non autorisés.
- Révoquer les sessions actives des rôles IAM (non applicable aux utilisateurs IAM).
- Sur S3, supprimer des potentiels marqueurs de suppression sur les objets versionnés.
- Recréer les buckets supprimés et restaurer les données depuis une sauvegarde si elle existe.
- Appliquer le plan de réponse à incident.
Pour aller plus loin
Pour approfondir le sujet, je recommande les ressources suivantes qui traitent du sujet avec plus de profondeur:
- Focus sur RDS: Anatomy of a ransomware event targeting data residing in Amazon RDS
- Focus sur S3: The anatomy of ransomware event targeting data residing in Amazon S3 sur le blog AWS
- Article de Anthony Freyermuth sur le blog Ippon: Sauvegarder vos nuages AWS en quelques minutes
- Les vidéos de Kyle Dickinson sur Youtube
- AWS Incident Response Playbooks sur GitHub
- Focus sur AWS Backups et les bonnes pratiques de l’équipe de réponse à incident d’AWS, par Tristan Miche et moi-même sur le blog Ippon.
