Comment savoir si un compte AWS a été compromis ?
Presque toute compromission AWS laisse une trace dans CloudTrail : l’appel d’API qui a confirmé qu’une clé volée fonctionne, la rafale d’appels List et Describe qui cartographie le compte, l’utilisateur IAM créé comme backdoor, le détecteur GuardDuty supprimé, les instances GPU lancées dans une région que personne n’utilise. Le plus difficile est de retrouver ces quelques événements parmi des millions.
Cet outil lit vos exports dans le navigateur, exécute un ensemble de détections écrites sous forme de règles vérifiables (correspondances de champs, seuils, techniques MITRE ATT&CK) et rend un verdict — Sain, Suspect ou Compromis — avec les lignes de preuve derrière chaque détection, une chronologie de l’incident, un pivot sur chaque principal, clé, IP et ressource, et une checklist de remédiation.
Ce qu’il détecte
- Accès initial : clés d’accès à long terme soudainement utilisées depuis une nouvelle adresse IP, utilisation du compte root, connexions à la console sans MFA, rafales d’échecs de connexion.
- Reconnaissance : GetCallerIdentity avec une clé à long terme, rafales d’énumération (des dizaines d’appels List/Describe/Get différents en quelques minutes), avalanches d’AccessDenied, user agents Kali / Pacu / CloudFox.
- Persistance et élévation de privilèges : CreateUser, clés d’accès créées pour un autre utilisateur, politiques AdministratorAccess ou *:*, mots de passe console, modifications de relations d’approbation de rôles, nouveaux fournisseurs SAML / OIDC, fonctions Lambda publiques, user data EC2 et paires de clés.
- Contournement des défenses : CloudTrail arrêté ou supprimé, GuardDuty, Config, Security Hub désactivés, journalisation des accès S3 et VPC Flow Logs supprimés, groupes de sécurité ouverts sur Internet.
- Vol de données : buckets rendus publics, snapshots partagés avec d’autres comptes, téléchargements S3 massifs (événements de données CloudTrail ou journaux d’accès S3), transferts sortants volumineux dans les VPC Flow Logs, lecture massive de secrets.
- Impact et abus de coûts : instances GPU lancées, demandes d’augmentation de quota, activité dans des régions jusque-là inutilisées, connexions à des pools de minage, suppressions massives, clés KMS programmées pour suppression.
Limites
- Les détections orientent, elles ne prouvent pas : chaque détection affiche ses preuves pour que vous puissiez la confirmer. Une administration légitime peut ressembler à une attaque, et un attaquant prudent peut rester sous les seuils.
- Sans événements de données S3 ni journaux d’accès S3, la lecture de données dans les buckets est invisible ; sans VPC Flow Logs, l’exfiltration réseau l’est aussi.
- Les détections « nouvelle IP » et « nouvelle région » comparent avec le premier jour des logs fournis : incluez quelques jours calmes avant l’incident.
- Pas de géolocalisation IP ni de recherche d’ASN (cela nécessiterait une base de données ou un service en ligne) : les nouveaux pays ne sont pas encore détectés.
- Les logs ALB, CloudFront et Parquet sont reconnus mais pas encore analysés.
FAQ
Mes logs sont-ils envoyés quelque part ?
Non. L’analyseur est écrit en Rust compilé en WebAssembly et s’exécute dans un Web Worker de votre navigateur. Les fichiers sont lus en flux depuis votre disque et décompressés localement ; il n’existe aucun point d’envoi.
Comment enquêter sur une clé d’accès AWS divulguée ?
Désactivez d’abord la clé, puis déposez les logs CloudTrail couvrant toute sa durée de vie. Pivotez sur la clé dans l’onglet Entités : l’outil signale sa première utilisation depuis une nouvelle adresse IP, les appels effectués depuis celle-ci (reconnaissance, modifications IAM, accès aux données) et tout ce que la clé a créé — utilisateurs, clés, instances — pour que vous puissiez tout nettoyer, pas seulement la clé.
Peut-il traiter un export CloudTrail de plusieurs gigaoctets ?
Oui. Les fichiers sont lus par blocs et le gzip est décompressé en flux, la mémoire reste donc bornée. Chaque enregistrement passe par les détections ; pour les très gros volumes, l’explorateur d’événements conserve les événements notables et toutes les preuves.
Quelles règles utilise-t-il ?
Une cinquantaine de détections écrites sous forme de données (correspondances de champs, seuils sur fenêtre glissante, agrégats) avec les identifiants de techniques MITRE ATT&CK, dans l’esprit des règles Sigma. Elles sont consultables dans le fichier de règles open source et couvrent les scénarios d’attaque AWS courants : clés divulguées, persistance IAM, contournement des défenses, vol de données et minage de cryptomonnaie.
Le verdict indique une compromission — que faire ?
Confinez d’abord : désactivez les clés divulguées, supprimez les utilisateurs et clés backdoor, arrêtez les instances de l’attaquant — la checklist de remédiation les liste à partir des détections. Préservez les logs avant toute autre modification, puis délimitez le périmètre de l’incident. Le guide AWS Security Incident Response Guide décrit l’ensemble du processus.
Est-ce un produit Amazon ?
Non. C’est un outil indépendant, ni affilié à Amazon Web Services, ni approuvé ou sponsorisé par celui-ci.