Datadog Security Labs a observé des tentatives de password spraying contre le flux de connexion console des comptes root AWS du 24 juillet au 23 août 2026, dans plus de 150 organisations. Aucune authentification réussie n’a été observée. Le rapport ne confirme donc pas une compromission de ces organisations et ne détermine pas l’intention des auteurs.
Le password spraying consiste à essayer un petit nombre de mots de passe sur de nombreux comptes, plutôt qu’à répéter les essais sur une seule identité. Datadog indique une médiane de deux tentatives par organisation, certaines en ayant reçu jusqu’à huit pendant la période observée.
Pourquoi le compte root est une cible sensible
Le compte root AWS dispose d’un accès complet aux ressources, aux paramètres du compte et à la facturation. AWS recommande de ne l’utiliser que pour les tâches qui l’exigent et de créer des identités administratives distinctes pour les opérations courantes. Il recommande aussi de ne pas créer de clés d’accès permanentes pour le compte root.
Ce que Datadog a observé
Datadog note qu’une tentative de connexion root à la console nécessite l’adresse e-mail associée au compte. Le rapport ne permet pas de savoir si les auteurs avaient une liste préalable ou ont testé des adresses. AWS exige que la MFA soit configurée pour tous les comptes root, avec un délai de 35 jours après la première tentative de connexion pour terminer l’inscription si elle ne l’est pas déjà. Datadog n’indique pas si les tentatives observées ont atteint l’étape MFA ni si celle-ci en a bloqué certaines.
Datadog a également observé des connexions échouées via des proxys et deux chaînes User-Agent récurrentes; ces chaînes peuvent être usurpées et ne doivent pas servir seules à bloquer une connexion.
Cinq vérifications pour les équipes AWS
- Confirmer que la MFA du compte root est activée et que ses moyens de récupération sont accessibles selon une procédure documentée. AWS recommande une passkey ou une clé de sécurité FIDO2 lorsque c’est possible.
- Rechercher les clés d’accès root à longue durée et les supprimer si elles existent; AWS recommande de ne pas en créer.
- Réserver root aux opérations rares, puis utiliser des identités administratives nominatives et limitées pour le travail quotidien.
- Examiner les événements
ConsoleLogindu compte root dans CloudTrail et alerter sur les connexions, les changements d’identifiants et les opérations root. - Avec AWS Organizations, envisager la suppression des identifiants root des comptes membres et l’accès root centralisé temporaire; protéger séparément le compte de gestion.
Pour renouveler un mot de passe root, créez un secret unique avec le guide de génération de mots de passe sécurisés. Protégez aussi l’adresse e-mail de récupération : elle fait partie du chemin d’accès au compte.
Soclyde et les accès privilégiés
Soclyde peut aider à conserver les identifiants des administrateurs et d’autres secrets humains nécessaires à l’exploitation. Les contrôles propres à AWS, comme la MFA, les politiques IAM et la journalisation CloudTrail, restent indispensables et ne sont pas remplacés par un coffre de mots de passe. Pour un secret root, suivez les recommandations AWS : besoin professionnel strict, autorisations à plusieurs personnes lorsque possible et journalisation de l’accès au stockage.
Le guide Soclyde sur la politique de mots de passe en PME aide à séparer les comptes et documenter les responsabilités. Pour organiser des accès partagés, consultez le guide de partage sécurisé des mots de passe en équipe.
À retenir
Cette campagne documente des tentatives, pas des compromissions confirmées. Vérifiez les journaux, maintenez la MFA et les autres contrôles AWS, et limitez l’usage de root aux opérations nécessaires. Pour structurer les responsabilités de l’équipe, consultez le guide Soclyde sur la politique de mots de passe en PME.
