Un compte compromis après une panne AWS

 (news.ycombinator.com)
1 points par GN⁺ 2025-10-22 | 1 commentaires | Partager sur WhatsApp

Après une panne de service sur AWS récente, un utilisateur a signalé qu’un attaquant externe avait compromis son compte AWS.

Vecteur d’intrusion et situation détectée

  • Il a été mentionné que, durant la période de panne, certaines politiques de sécurité peuvent ne pas fonctionner correctement.
  • Après l’incident, l’attaquant a laissé des traces d’accès anormaux dans les journaux de compte, et certains éléments ont été créés/supprimés de manière inattendue.
  • L’utilisateur a exprimé des inquiétudes quant à une éventuelle modification des permissions ou une exposition des informations d’authentification.

Impact et réponse

  • Une augmentation des coûts, des fuites de données, entre autres, ont causé des dommages concrets.
  • Un contact a été pris avec le support AWS pour demander les détails de l’incident et les méthodes de réponse.
  • La communauté a souligné l’importance de la prévention proactive, notamment l’activation de la double authentification, la minimisation des accès basés sur les rôles, etc.

À lire aussi

1 commentaires

 
GN⁺ 2025-10-22
Commentaires Hacker News

  • J'aurais tendance à penser que ce type d'incident relève du hasard, mais j'ai aussi eu un cas de compte client compromis. Le client était une petite organisation, et deux anciens comptes IAM inutilisés depuis plus de 5 ans ont soudain présenté des traces de connexion à la console et de changement de mot de passe. Après enquête, ce qui était établi jusqu'ici, c'était uniquement l'activation d'un accès production AWS SES et un ticket de support pour augmenter le quota quotidien d'e-mails à 50000. Le fait qu'un compte inactif depuis plus de 5 ans se soit activé précisément à ce moment là est très étrange.

    • Ça sent clairement le phishing. Par exemple, recevoir un e-mail se faisant passer pour une annonce de panne AWS puis être incité à se connecter à la console et compromettre le compte via un wrapper malveillant.
    • J'ai vécu exactement la même chose il y a un an. Connexion avec un compte très ancien, accès SES, puis demande d'augmentation du quota d'e-mails. Nous avons pu réagir rapidement parce que le ticket d'augmentation de quota était obligatoire. Si ce n'est pas encore vérifié, il faut aussi vérifier les nouveaux roles créés. Nous avons immédiatement nettoyé le compte compromis, et en passant en revue les roles, j'ai supprimé tous ceux dont l'ancienneté était inférieure à un mois ou qui disposaient de droits admin. Par ailleurs, nous avons aussi confirmé que la compromission venait bien de ma propre clé : le premier utilisateur avait été créé presque un mois avant la vraie demande SES, et il est possible que l'attaquant ait déjà compromis notre infra, puis ait profité de la panne AWS pour en tirer parti. Ça se voyait moins bien avec d'autres incidents AWS mélangés.

  • Quelqu'un qui a déjà obtenu un accès peut attendre qu'un incident perturbant comme une panne d'infrastructure AWS se produise, puis lancer l'attaque à ce moment-là pour se cacher dans le chaos. Même si un token est exposé depuis des semaines ou des mois, il peut choisir d'attendre qu'un grand événement se produise avant d'agir. Si j'étais attaquant, j'aurais bien envie d'essayer cette méthode.

    • C'est tout à fait possible. En tant que responsable due diligence, j'ai aussi vu de vrais cas de ce type. Les attaquants préparent tout à l'avance et attendent parfois des événements importants comme une cession d'entreprise pour se lancer. Plus l'attaquant est sophistiqué, plus il guette ces opportunités de manière proactive.
    • Pour dire que je viens de la même équipe, j'ai effectivement reçu il y a 2 ans un e-mail d'alerte lié à la clé exploitée aujourd'hui, envoyé par une personne au hasard. Mais jusqu'à hier, il n'y avait aucun usage malveillant.
    • À l'inverse, je pense que c'est un mauvais timing pour attaquer. Tout le monde porte désormais son attention sur AWS et se connecte beaucoup, donc toute anomalie sera vue plus vite. Si notre société utilise AWS, on surveillerait encore plus attentivement absolument tout dans ce contexte.

  • Si j'étais attaquant, je choisirais à quel moment frapper, et une grande panne où l'agrégation des logs ne fonctionne pas correctement peut être une bonne opportunité. Il se peut qu'ils aient exploité le moment-là une compromission déjà existante, ou qu'ils se soient appuyés sur la panne AWS pour lancer d'autres attaques avec mes ressources.

  • Dans un environnement cloud, si une ressource suspecte (EC2, etc.) apparaît, il est possible de vérifier par CloudTrail quel événement l'a créée; notamment, l'événement RunInstances permet souvent de confirmer.

    • Je ne suis plus très à jour sur AWS en ce moment, donc je ne peux pas vérifier directement la console, mais si vous vivez une situation similaire, je recommande à peu près les étapes suivantes:
      1. Identifier le compte/l'entité qui a créé l'EC2 (eventSource:ec2.amazonaws.com, eventName:RunInstances)
      2. Suivre les actions suivantes via userIdentity
      3. Vérifier l'historique des connexions directes à la console (eventSource:signin.amazonaws.com, userIdentity.type:[Root/IAMUser/AssumedRole/FederatedUser/AWSLambda], eventName:ConsoleLogin)
      4. Vérifier l'historique des demandes d'authentification via Security Token Service (eventSource:sts.amazonaws.com, eventName:GetSessionToken)
      5. Vérifier si AssumeRole est utilisé via une session STS (eventSource:sts.amazonaws.com, eventName:AssumeRole)
      6. Vérifier les tentatives de persistance (création de nouveaux IAM Role/Account, etc.) (eventSource:iam.amazonaws.com, eventName:CreateUser/ DeleteUser)
      7. Vérifier si un Role/Account existant a été modifié vers des droits plus élevés (eventSource:iam.amazonaws.com, eventName:CreateRole/DeleteRole/AttachRolePolicy/DetachRolePolicy)
      8. Vérifier l'historique de création/suppression des Access Key (eventSource:iam.amazonaws.com, eventName:CreateAccessKey/DeleteAccessKey)
      9. Vérifier la possibilité d'une backdoor via modification de l'IAMInstanceProfile sur un EC2 de production (voir l'exemple AWS Docs https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-log-file-examples.html#cloudtrail-log-file-examples-ec2) Si une compromission plus profonde est suspectée, je recommande un contrôle de l'environnement et un audit par des professionnels.
    • C'est une bonne info donc je vais consulter les logs. Pour compléter, voici les points observés :
      1. Une vingtaine d'organisations ont été créées sous le root et utilisaient toutes des adresses e-mail avec le même domaine (co.jp)
      2. L'attaquant a préparé plusieurs templates Fargate
      3. Des ressources ont été créées dans 16~17 régions AWS
      4. Des demandes inutiles sont apparues, notamment augmentation de quota SES, augmentation de ressources AWS Fargate, demande de maintenance de notebooks SageMaker (plusieurs e-mails d'alerte reçus à ce sujet)
      5. J'ai découvert que de nouveaux noms (random name@outlook.com) étaient ajoutés sur certains e-mails
    • L'événement RunInstances est précisément cet événement.

  • Certains utilisateurs de Reddit ont dit avoir été brièvement connectés en tant qu'un autre utilisateur en rafraîchissant pendant la panne AWS.

    • J'ai aussi déjà connu un cas similaire dans une entreprise où j'ai travaillé. Des clients accédaient à des données client différentes, et la cause était un employé ayant tenté de faire du live debugging en production en temps réel (j'avais d'ailleurs recommandé contre son embauche à l'entretien, au fait). C'était vraiment difficile à tracer et corriger.
    • Je me demande si, pendant la panne, DynamoDB n'a pas connu un état d'incohérence temporaire entraînant aussi une casse des identifiants IAM. Si c'est vrai, c'est un vrai problème. Je me demande s'il existe un lien de référence pertinent.
    • Si vous disposez d'indices, merci de les partager. C'est vraiment choquant.
    • J'ai pensé récemment à ChatGPT et à un éventuel problème similaire. Ça donne une impression très proche.
    • Un incident de sécurité de ce genre est bien plus grave qu'un simple problème de panne temporaire de service.

  • Dans la routine, ce genre de cas est probablement dû au hasard, mais c'est généralement une access key exposée qui en est la cause. Il y a aussi des cas de fuite de mot de passe de compte console sans MFA, mais c'est un peu plus rare.

  • En situation de panique, les gens sont les plus vulnérables au phishing. Il faut réinitialiser largement les mots de passe et informer AWS de la situation. En général, ça se résout bien via un modèle de confiance.

  • La région us-east-1 est plus grande qu'imaginé. Selon les informations publiées récemment, il y aurait 159 data centers. Plusieurs millions de comptes pourraient y être concentrés. Ce phénomène pourrait être lié à la panne AWS, mais personnellement je pense qu'il est plus probable que ce soit une coïncidence.

    • 159, ça surprend. Si vous avez une source valable, merci de la partager.

  • Cela peut sembler étrange, mais si vous m'envoyez une API key, je pourrais vérifier si elle figure dans une liste de fuites.

    • Je sais que c'est une blague, mais je voulais quand même signaler une chose importante avec prudence. Même s'il s'agit d'une plaisanterie, évitez de mentionner le partage d'une API key ou de credentials. Quelqu'un pourrait l'entendre au sérieux, donc soyez prudent.