Détection des menaces sur AWS : comment identifier le comportement des attaquants

La détection des menaces sur AWS consiste à identifier et à hiérarchiser les activités malveillantes ou suspectes au sein d’AWS en analysant cloud à la recherche d’indices de comportement malveillant. Plutôt que d’évaluer des événements isolés, cette approche examine les actions d’un acteur à travers ses identités, ses rôles et les services qu’il utilise. Alors que 80 % des entreprises ont subi au moins une faille cloud au cours de l’année écoulée et que le coût moyen cloud public s’élève à 5,17 millions de dollars par faille, l’enjeu d’une détection efficace des menaces sur AWS ne cesse de croître.

Les environnements AWS génèrent d'importants volumes de journaux et de métadonnées qui sont difficiles à interpréter isolément. En associant ces données de télémétrie à des indicateurs comportementaux, il est possible de mettre en évidence les mouvements des attaquants tout au long du cycle de vie cloud , ce qui est essentiel car des activités non mises en corrélation peuvent retarder l'enquête et la réponse.

Ce que signifie concrètement la détection des menaces AWS

En pratique, la détection des menaces AWS relie les actions connexes à des modèles comportementaux qui peuvent être examinés et classés par ordre de priorité. Plutôt que de traiter cloud comme un ensemble d'alertes sans rapport entre elles, elle interprète l'activité comme la preuve d'une possible séquence d'attaques. Cette distinction est importante, car de nombreuses actions AWS sont techniquement légitimes tout en représentant un abus d'accès, de rôles ou de services.

Types d'activités qui révèlent les intentions au fil du temps et sur l'ensemble des services :

• Utilisation d'identités compromises pour obtenir un accès initial aux ressources AWS.
• Se faire passer pour d'autres personnes et utiliser des identifiants temporaires afin de dissimuler l'identité de l'auteur initial.
• Enchaîner ou « passer » d'un rôle à l'autre pour échapper à l'attribution sur plusieurs comptes ou services.
• Contourner les mesures de sécurité en tentant de désactiver, de bloquer ou de contourner la journalisation.
• Exfiltrer des données ou mener des actions destructrices après avoir étendu ses privilèges.

Fonctionnement de la détection des menaces sur AWS

La détection des menaces AWS transforme cloud en une vue factuelle du comportement potentiel d'un attaquant. Un processus de détection type comprend six étapes :

1. Collecter cloud . Les données pertinentes peuvent inclure les événements AWS CloudTrail, les journaux de flux Amazon VPC, les journaux de requêtes DNS, l'activité Amazon S3, les journaux d'audit Amazon EKS et les données de télémétrie d'exécution provenant des charges de travail prises en charge.
2. Définir les comportements attendus. Les systèmes de détection évaluent la manière dont les utilisateurs, les rôles, les charges de travail et les services interagissent habituellement. Ce contexte permet de distinguer les comportements inhabituels des activités administratives courantes.
3. Identifiez les activités suspectes. Des anomalies telles que des appels API inattendus, un accès depuis un nouvel emplacement, la prise en charge inhabituelle de rôles ou des contacts avec une infrastructure malveillante connue peuvent indiquer une compromission potentielle.
4. Mettre en corrélation les actions liées. Les événements pris isolément prennent tout leur sens lorsqu'ils sont mis en relation entre eux, qu'il s'agisse d'une perspective temporelle, de comptes, de régions ou de services. Par exemple, une phase de reconnaissance suivie d'une opération « AssumeRole », d'un accès à des secrets et d'une extraction massive de données peut constituer une séquence d'attaque.
5. Hiérarchiser les entités à risque. Une hiérarchisation fondée sur les risques permet aux analystes de se concentrer sur les identités, les rôles, les comptes et les ressources associés aux comportements les plus urgents, plutôt que d'examiner toutes les alertes de la même manière.
6. Enquêter et réagir. Les analystes vérifient l'activité, en déterminent l'ampleur et prennent des mesures de confinement, telles que la révocation de sessions, la désactivation d'identifiants, l'isolation de charges de travail ou la restriction des rôles concernés.

Ce processus diffère de la collecte de journaux classique. Les journaux fournissent des enregistrements des événements survenus, tandis que la détection des menaces ajoute un contexte comportemental, une corrélation et une hiérarchisation afin de déterminer si l'activité correspond à la progression d'un attaquant.

Outils et services AWS de détection des menaces

AWS propose plusieurs services de sécurité natifs qui constituent la base d'une stratégie de détection cloud . Comprendre le rôle de chaque outil — et identifier les lacunes qui subsistent — aide les équipes à mettre en place une couverture de détection efficace.

Amazon GuardDuty

Amazon GuardDuty est le principal service de détection des menaces d'AWS. Il analyse en continu les événements de gestion CloudTrail, les journaux de flux VPC, les journaux de requêtes DNS et les données de télémétrie d'exécution à l'aide de l'apprentissage automatique, de la détection des anomalies et de renseignements intégrés sur les menaces. En décembre 2025, AWS a lancé Extended Threat Detection pour EC2 et ECS, qui utilise l'IA et l'apprentissage automatique pour corréler les signaux provenant de multiples sources de données et cartographier les séquences d'attaques en plusieurs étapes vers MITRE ATT&CK .

AWS Security Hub

Security Hub regroupe les résultats de GuardDuty, d'Amazon Inspector, d'AWS Config et d'outils tiers au sein d'un tableau de bord unifié. Il permet de vérifier la conformité à des normes telles que CIS AWS Foundations et prend en charge la correction automatisée grâce à des intégrations avec AWS Lambda et Amazon EventBridge.

Amazon Detective

Detective complète GuardDuty en fournissant une analyse investigative plus approfondie. Lorsque GuardDuty identifie un résultat de gravité élevée, Detective permet de retracer l'origine, l'étendue et les liens de l'activité suspecte à travers les différentes ressources.

Tableau : Comparaison des services de détection des menaces natifs d'AWS

Ces outils natifs offrent une couverture essentielle, mais ils se concentrent sur l'activité au sein d'AWS. Les attaques qui prennent leur source en dehors d'AWS — via des fournisseurs d'identité compromis, des réseaux sur site ou des applications SaaS — nécessitent une corrélation supplémentaire entre les environnements hybrides afin de détecter l'intégralité de la chaîne d'attaque.

Pourquoi la surveillance AWS centrée sur les journaux passe à côté du comportement des attaquants

La surveillance centrée sur les journaux dans AWS ne parvient souvent pas à mettre en évidence le comportement des attaquants, car les événements sont analysés comme des enregistrements isolés. L'attribution s'arrête fréquemment au dernier rôle ou aux derniers identifiants temporaires, ce qui conduit les enquêtes à se concentrer sur une abstraction erronée. En conséquence, les défenseurs risquent de ne pas identifier l'acteur initial à temps pour contenir l'activité avant qu'elle n'ait un impact.

Modes de défaillance lorsque l'activité AWS est évaluée comme des événements isolés :

• Des alertes au cas par cas qui ne permettent pas de relier les actions entre les services ou dans le temps
• Une attribution incomplète qui s'arrête à un rôle supposé au lieu de remonter jusqu'à l'acteur d'origine
• Des visions cloisonnées entre les comptes, les régions et les domaines qui empêchent une vision d'ensemble cohérente
• La charge liée à la corrélation manuelle, qui ralentit la réponse et alourdit la charge cognitive
• Un volume élevé d'alertes qui ne permet pas de déterminer quelle identité ou quel compte présente le risque le plus élevé

Les comportements des attaquants que la détection des menaces aide à mettre en évidence

Pour comprendre comment les attaquants évoluent au sein d'AWS, il faut aller au-delà des actions menées sur chaque service pris individuellement. La détection axée sur le comportement met en évidence des schémas d'évolution, tels que l'enchaînement de rôles, le contournement de la journalisation et l'accès latéral aux services, qui peuvent sembler légitimes lorsqu'ils sont considérés isolément.

Modèles de progression :

• Infiltration par le biais de l'ingénierie sociale et de l'abus de relations d'identité de confiance
• Utilisation de rôles supposés pour abstraire l'identité et échapper à l'attribution directe
• Enchaînement de rôles en plusieurs étapes qui masque l'identité compromise d'origine

Signaux et indicateurs utilisés dans la détection des menaces AWS

Tous les signaux dans AWS n'ont pas la même valeur pour l'enquête. Les efforts de détection donnent la priorité aux indicateurs qui reflètent un comportement anormal ou en plusieurs étapes lié à un acteur spécifique. Les indicateurs précoces peuvent être subtils et dispersés, tandis que les signaux tardifs n'apparaissent souvent qu'après que des dommages importants se sont produits.

Signaux clés :

• Écarts par rapport à la base de référence, tels que des appels API inhabituels ou des modèles d'utilisation des identifiants
• Comportements de reconnaissance précoces qui laissent supposer une exploration des autorisations ou des ressources
• Chaînes d'attribution de rôles et séquences d'informations d'identification indiquant l'activité de chaînage des rôles
• Tentatives visant à désactiver, réduire ou contourner la couverture de la journalisation et de la surveillance
• Comportement corrélé entre l'identité, le réseau et cloud qui désigne un seul acteur
• Indicateurs avancés tels que les communications de type « commande et contrôle » ou l'exfiltration de données

Meilleures pratiques en matière de détection des menaces sur AWS

Une détection efficace des menaces sur AWS repose à la fois sur une couverture étendue des données télémétriques et sur un contexte d'identité suffisamment riche pour relier les actions suspectes à l'acteur ou à la charge de travail responsable.

Centraliser la visibilité sur l'ensemble des comptes et des régions

Utilisez AWS Organizations et l'administration déléguée pour appliquer les services de sécurité de manière cohérente dans l'ensemble de l'environnement. Activez la journalisation et la couverture de détection appropriées dans chaque compte et chaque région actifs, puis centralisez les résultats afin que les analystes n'aient pas à consulter plusieurs consoles et bases de données distinctes.

Protéger les identités et les identifiants temporaires

Exiger une authentification multifactorielle pour les accès privilégiés, limiter l'utilisation de l'utilisateur « root » et appliquer des politiques de « privilèges minimaux » aux utilisateurs, aux rôles et aux charges de travail. Surveiller l'activité du service AWS Security Token Service, y compris toute activité inhabituelle Assumer un rôle les séquences, l'accès inter-comptes et l'enchaînement de rôles susceptibles de dissimuler l'identité d'origine.

Enregistrer à la fois l'activité du plan de contrôle et celle des données concernées

Les événements de gestion CloudTrail mettent en évidence les modifications apportées aux ressources et aux autorisations AWS, tandis que les événements liés aux données permettent de visualiser l'activité associée à des services tels qu'Amazon S3 et AWS Lambda. Les entreprises doivent choisir la couverture des événements liés aux données en fonction des ressources sensibles, des besoins en matière d'investigation et du coût.

Surveiller l'activité des API à haut risque

Privilégiez les activités susceptibles de modifier les contrôles de sécurité, d'assurer la persistance ou d'exposer des données. Parmi les exemples, on peut citer les appels inattendus vers Créer une clé d'accès, associer une politique de rôle, définir une politique de rôle, mettre à jour une politique d'assomption de rôle, arrêter la journalisation, supprimer une trace, définir une politique de compartiment et les API de récupération de secrets.,

Un appel isolé peut être légitime. Son intérêt pour l'enquête s'accroît lorsqu'il s'accompagne d'un comportement inhabituel au niveau de l'identité, du réseau ou des ressources.

Appliquer le principe du « privilège minimal » aux rôles liés aux charges de travail

Vérifiez les profils d'instance EC2, les rôles d'exécution Lambda, les rôles de tâche Amazon ECS et les identités de charge de travail Amazon EKS. Des autorisations excessives peuvent transformer la compromission d'une application en une cloud plus large cloud , impliquant l'accès aux identifiants, l'escalade de privilèges ou l'exfiltration de données.

Mettre en corrélation cloud avec les signaux liés à l'identité et au réseau

La télémétrie native d'AWS peut révéler ce qui s'est passé au sein d'un compte sans pour autant mettre au jour la compromission antérieure endpoint, du fournisseur d'identité ou du service SaaS qui a permis cette intrusion. La corrélation des comportements cloud, des identités et du réseau permet de reconstituer les chemins d'attaque hybrides et d'identifier l'acteur à l'origine de l'attaque.

Préparer les mesures d'intervention avant qu'un incident ne se produise

Définissez dans quelles circonstances les intervenants peuvent révoquer des sessions, désactiver des clés d'accès, mettre des charges de travail en quarantaine, restreindre des rôles ou isoler des comptes. Amazon EventBridge, AWS Lambda et les workflows d'orchestration de la sécurité existants peuvent prendre en charge l'automatisation, mais les actions destructrices doivent inclure des tests, des règles d'approbation et des procédures de restauration.

‍

Incidents réels liés à la détection des menaces sur AWS

Des incidents récents montrent pourquoi la détection comportementale revêt une importance plus grande que la simple surveillance des journaux.

Ransomware Codefinger (janvier 2025)

Le groupe de ransomware Codefinger a exploité des identifiants AWS compromis pour chiffrer des données S3 à l'aide du chiffrement côté serveur avec des clés fournies par le client (SSE-C). Les attaquants ayant utilisé des fonctionnalités de chiffrement AWS légitimes plutôt malware, les outils de détection traditionnels basés sur les signatures n'ont pas détecté cette activité. Seule la surveillance comportementale — qui a permis de détecter des opérations de chiffrement en masse inhabituelles liées à une chaîne d'identifiants suspecte — a pu mettre au jour l'attaque avant que les données ne deviennent irrécupérables.

Exploitation de FortiGate optimisée par l'IA (janvier-février 2026)

Amazon Threat Intelligence a recensé une campagne au cours de laquelle un acteur malveillant russophone, animé par des motivations financières, a utilisé des services commerciaux d'IA générative pour compromettre plus de 600 appareils FortiGate dans plus de 55 pays entre le 11 janvier et le 18 février 2026. Les attaquants ont exploité l'IA pour étendre leurs opérations, démontrant ainsi que les menaces renforcées par l'IA entraînent une augmentation du volume des attaques, tant pour les adversaires expérimentés que pour les novices.

Abus de prérogatives chez LexisNexis ECS (février 2026)

En février 2026, un acteur malveillant a exploité une application frontale React non mise à jour fonctionnant sur AWS pour obtenir un accès initial, puis a abusé d'un rôle de tâche ECS trop permissif disposant d'un large accès en lecture à AWS Secrets Manager. Cela a permis l'exfiltration d'identifiants Redshift, de cartes VPC et de millions d'enregistrements de base de données. L'incident correspondait à MITRE ATT&CK , notamment T1190 (exploitation d'une application accessible au public), T1078 (comptes valides) et T1530 (données provenant d'un objet cloud ), ce qui souligne pourquoi la surveillance du comportement des identités et des rôles est essentielle pour la détection des menaces sur AWS.

Ces incidents présentent une caractéristique commune : les attaquants ont utilisé des mécanismes AWS légitimes (fonctions de chiffrement, rôles valides, identifiants temporaires) pour mener des activités malveillantes qui semblaient normales au niveau des événements, mais qui ont été mises au jour grâce à une analyse comportementale.

Limites et idées fausses concernant la détection des menaces AWS

La détection des menaces dans AWS a encore ses limites. Bien qu'elle permette d'identifier les comportements suspects, la détection des menaces n'empêche pas automatiquement les risques cloud et n'y remédie pas. Cela signifie que les équipes doivent toujours s'appuyer sur des workflows de réponse et le jugement des analystes. Confondre détection et prévention peut créer des angles morts qui retardent la maîtrise des menaces.

Tableau : Idées reçues vs. rectifications

L'avenir de la détection des menaces sur AWS

Plusieurs tendances sont en train de redéfinir la manière dont les entreprises abordent la détection des menaces dans les environnements AWS.

• Les attaques assistées par l'IA se multiplient. Comme l'a démontré la campagne FortiGate 2026, cybercriminels recours à l'IA générative pour intensifier leurs attaques. La détection des menaces sur AWS doit suivre le rythme en corrélant les signaux plus rapidement que les attaquants ne parviennent à les générer.
• L'identité est le nouveau périmètre. Étant donné que plus de 70 % des cloud trouvent leur origine dans des identités compromises et que 61 % des entreprises continuent d'utiliser des comptes root sans authentification multifactorielle (MFA), la détection centrée sur l'identité restera prioritaire par rapport aux approches centrées sur le réseau.
• La détection des attaques en plusieurs étapes devient désormais la norme. La fonctionnalité « Extended Threat Detection » de GuardDuty marque un tournant : il s'agit désormais de mettre en corrélation les actions entre les différents services et dans le temps, plutôt que d'évaluer les événements individuellement. Cette approche va s'étendre pour couvrir davantage de services AWS etcloud .
• Les voies d'attaque hybrides nécessitent une visibilité unifiée. Alors que les entreprises opèrent à la fois sur AWS, Azure, en local et dans des environnements SaaS, les stratégies de détection des menaces qui traitent chaque domaine de manière isolée passeront à côté des attaques les plus dangereuses : celles qui se propagent latéralement au-delà des frontières.

Comment la plateforme Vectra AI prend en charge la détection des menaces AWS grâce à la corrélation des comportements des attaquants

Pour assurer efficacement la détection des menaces sur AWS, il est nécessaire d'appréhender le comportement des attaquants comme un continuum unique, englobant à la fois les identités, le réseau et cloud . La Vectra AI aborde ce problème en établissant des corrélations entre les actions, plutôt qu'en traitant les événements AWS comme des alertes isolées, ce qui réduit l'incertitude lorsque les rôles, les identifiants temporaires et l'activité multi-services compliquent l'attribution des menaces. Vectra AI Cloud and Response (CDR)Vectra AI pour AWS étend la détection au-delà des outils natifs en analysant les comportements sur l'ensemble des surfaces d'attaque hybrides.

Fonctionnalités de la plateforme :

• Observer le comportement corrélé des attaquants à travers les identités, les rôles et cloud plutôt que des événements AWS isolés.
• Déterminer quelle identité ou quel compte présente le risque le plus élevé en mettant l'accent sur l'urgence et le contexte plutôt que sur le volume.
• Réduire le risque d'attribution erronée dans la chaîne des rôles en reliant les activités suspectes à leur auteur initial lorsque cela est possible.
• Détecter les séquences suspectes d'activités d'exploration qui indiquent une phase de reconnaissance préliminaire avant le début du déplacement latéral

Découvrez le comportement des pirates sur AWS grâce à une visite guidée des attaques