Anomalie CloudTrail : corréler une chaîne de compromission d'identifiants
Le défi
Voici des événements CloudTrail de votre compte AWS. Une clé d'accès échoue à se connecter quelques fois, puis assume soudain un rôle privilégié et commence à lire des objets du bucket finance depuis une région que vous n'utilisez jamais. Les autres clés font leur travail normal. Corrélez la chaîne - connexions échouées, puis AssumeRole, puis GetObject - et soumettez l'identifiant de la clé d'accès compromise.
Ce que tu vas apprendre
- Lire les événements CloudTrail comme une chronologie par identifiant plutôt qu'une liste plate
- Corréler les échecs de ConsoleLogin, AssumeRole et GetObject en une seule chaîne d'attaque
- Utiliser la région comme signal d'anomalie pour détecter un usage abusif d'identifiants
- Distinguer une clé compromise des clés effectuant un travail normal et à but unique
- Attribuer une intrusion cloud à un identifiant de clé d'accès précis
Compétences testées
Prérequis
- Notions de base d'AWS IAM (clés d'accès, rôles, AssumeRole)
- Familiarité avec S3 et les noms d'événements CloudTrail
- Compréhension des régions AWS
Comment ça marche
Dans le cloud, une attaque se manifeste rarement par un seul événement suspect. Un identifiant volé est utilisé selon une séquence : entrer, escalader, puis atteindre les données. CloudTrail enregistre chacune de ces étapes comme un événement distinct, donc la compétence consiste à arrêter de lire les lignes individuellement et à commencer à lire la chronologie d'un seul principal, ici une seule accessKey, à travers plusieurs types d'événements et plusieurs champs.
Suivez AKIA9XPLOIT77 dans l'ordre chronologique et toute l'intrusion s'aligne : trois échecs de ConsoleLogin (devinette de mot de passe), puis un succès de ConsoleLogin, puis un AssumeRole immédiat sur role/FinanceAdmin (élévation de privilèges), puis une série soutenue d'appels GetObject extrayant des fichiers de s3://finance-bucket : paie, comptes bancaires, virements, dossiers fiscaux. Deux signaux supplémentaires le confirment : la cible est un bucket sensible, et chaque événement de cette clé provient de ap-south-1, une région que le compte ne touche jamais autrement. Les clés inoffensives font chacune une tâche cohérente unique dans eu-west-1.
C'est à cela que ressemble une corrélation d4 : aucune colonne seule ne donne la réponse. event:AssumeRole seul montre une escalade, event:GetObject seul montre des lectures, et la région seule montre une anomalie, mais ce n'est qu'en reliant la même clé d'accès à travers tous ces éléments que la compromission devient indéniable.
Erreurs fréquentes
- Juger un seul événement. Un échec de connexion ou un GetObject isolé est normal ; la réponse est la clé dont toute la séquence forme une chaîne d'attaque.
- Ignorer la colonne région. La région anormale
ap-south-1est une confirmation forte qui manque aux clés inoffensives eneu-west-1. - Choisir le rôle plutôt que la clé.
role/FinanceAdmina été détourné, mais la question demande l'identifiant de la clé d'accès qui l'a assumé. - Blâmer AKIA4FINANCE01 pour avoir touché S3. Cette clé lit son propre bucket de rapports dans la région normale, elle n'escalade jamais et ne touche jamais finance-bucket depuis une région étrangère.
Comment s'en protéger
La compromission d'identifiants cloud est détectable car la chaîne d'attaque est bruyante dans CloudTrail. Construisez des détections sur la même corrélation que vous venez de faire à la main.
- Alertez sur des échecs répétés de
ConsoleLoginsuivis d'un succès pour le même principal. - Alertez lorsqu'une clé appelle
AssumeRolesur un rôle privilégié qu'elle n'a jamais utilisé, en particulier depuis une nouvelle région. - Imposez le MFA sur les connexions console et faites tourner ou restreignez la portée des clés d'accès de longue durée.
- Signalez l'accès à des buckets sensibles comme
finance-bucketdepuis toute région hors de votre région d'exploitation habituelle.