Des attaquants ont accédé à un secret de production d’Amazon Web Services (AWS) malgré des centaines de requêtes API refusées lors d’une activité liée à une infrastructure hébergeant AntiFox, une plateforme de tests d’intrusion optimisée par l’IA. Arctic Wolf Labs a révélé ces informations le 10 novembre 2026, après avoir enquêté sur des intrusions impliquant des applications web et des environnements cloud.
Lors d’une intrusion, les opérateurs ont effectué des centaines de requêtes API AWS avec plusieurs identités en environ 30 minutes. La plupart ont échoué, mais une GetSecretValuerequête réussie a récupéré un secret de production dans AWS Secrets Manager. Ces résultats soulignent le risque lié à l’utilisation abusive d’identifiants et la possibilité que des opérations réussies passent inaperçues au milieu des échecs d’autorisation.
Des intrusions liées à AntiFox exposent des secrets AWS
L’enquête d’Arctic Wolf, publiée par The Hacker News, a établi un lien entre une infrastructure Alibaba Cloud hébergeant des interfaces AntiFox et une activité malveillante impliquant des applications Microsoft Internet Information Services (IIS) et des comptes AWS.
AntiFox est un framework open source dérivé d’ARTEX 0.1.1, précédemment mis en cause dans des campagnes de vol d’identifiants assistées par l’IA. Les chercheurs n’ont pas déterminé quelles actions liées à AntiFox étaient autonomes ni identifié de groupe de menaces précis.
Lors d’un incident, des attaquants ont exploité une vulnérabilité IIS non identifiée. Le w3wp.exeprocessus worker a créé un web shell ASPX, permettant l’exécution de commandes. Les attaquants ont accédé aux paramètres des applications, aux chaînes de connexion aux bases de données et aux fichiers de configuration.
Une autre activité AWS impliquait des identités valides utilisées pour énumérer des services, notamment IAM, S3 et Secrets Manager. L’enquête a identifié des milliers de clés d’accès AWS exposées qui étaient toujours actives, illustrant les risques liés aux identifiants compromis. Les méthodes précises utilisées pour obtenir les identifiants AWS lors des attaques liées à AntiFox n’ont pas été établies.
Un autre incident impliquait la lecture, la copie et la suppression non autorisées d’objets S3. Dans une déclaration du 12 novembre à BleepingComputer, AWS a affirmé que ses services n’avaient pas été compromis, attribuant l’activité à des identifiants obtenus depuis des applications clientes compromises.
Les lacunes de CloudTrail compliquent les enquêtes AWS
La détection des menaces dans AWS CloudTrail nécessite d’examiner les opérations réussies parallèlement aux requêtes refusées. La corrélation des identités, des actifs et des alertes associées aide les équipes des opérations de sécurité à gérer le volume d’alertes sans négliger les activités sensibles.
La documentation d’AWS CloudTrail confirme que l’historique des événements conserve 90 jours d’événements de gestion par région, mais exclut les événements de données. Les appels API de Secrets Manager génèrent des enregistrements CloudTrail sans exposer les valeurs des secrets.
Les opérations sur les objets S3, notammentGetObject et DeleteObject, nécessitent une journalisation des événements de données configurée séparément. Les recommandations d’AWS concernant la journalisation S3 confirment que ces événements ne sont pas enregistrés par défaut. Activer la journalisation après une intrusion ne permet pas de récupérer l’activité qui n’avait pas été collectée auparavant.
Détecter et contenir l’utilisation abusive d’identifiants AWS
Les équipes de sécurité doivent donner la priorité à la collecte de preuves, au confinement des identifiants et aux contrôles qui limitent les accès non autorisés.
- Enquêter sur l’activité AWS : Corréler les
GetSecretValuerequêtes réussies avec les opérations refusées, les adresses IP inconnues et l’énumération rapide de plusieurs identités. - Inspecter les applications IIS : Rechercher les fichiers ASPX inattendus, les activités
w3wp.exesuspectes et les accès non autorisés à la configuration. Limiter les privilèges des pools d’applications. - Contenir les identifiants compromis : Désactiver les clés exposées, révoquer les sessions concernées lorsque cela est possible, renouveler les secrets et enquêter sur les modifications IAM non autorisées.
- Renforcer les contrôles des identités : Limiter l’accès à Secrets Manager, appliquer le principe du moindre privilège, remplacer les identifiants intégrés par des identités temporaires de workloads et appliquer des restrictions réseau appropriées.
- Améliorer la journalisation et la récupération : Vérifier la couverture de CloudTrail, activer la journalisation des événements de données S3 et surveiller les résultats de GuardDuty. Protéger les objets critiques grâce à S3 Versioning et à des contrôles appropriés d’Object Lock.
- Tester les plans de réponse aux incidents : Simuler le vol d’identifiants et l’accès non autorisé à des secrets afin de valider la détection, le confinement, la préservation des preuves et la récupération.
L’analyse de la Cloud Security Alliance préconise de corréler les preuves liées aux identités, aux API et à l’infrastructure plutôt que de s’appuyer sur des indicateurs isolés. Les enquêteurs doivent vérifier les opérations API réussies avant de clore un incident reposant principalement sur des requêtes refusées.
À lire : la fuite de Zeabur impliquant des identifiants d’application exposés montre pourquoi le renouvellement des identifiants et les vérifications de récupération doivent s’étendre aux services connectés à une plateforme d’hébergement compromise.