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.

Mais comment renforcer la détection d’une intrusion dans son entreprise ? Les tests d’intrusion permettent d’évaluer le niveau de protection/durcissement sur un périmètre précis et encadré, qui ne représentent pas forcement la réalité vécue lors de nos réponses à incidents. Les exercices de gestion de crise permettent quant à eux d’améliorer la réaction… L’opération Red Team peut être un bon élément de réponse, permettant ainsi d’évaluer (et donc d’améliorer) de bout en bout le système d’informations ainsi que les capacités de détection.

Qu’est-ce qu’une opération Red Team ? C’est tout simplement une attaque réaliste mais sans les effets négatifs. L’objectif est de déterminer, aujourd’hui, quelles sont les actions malveillantes qu’un groupe d’attaquants peut réaliser sur mon entreprise et à quel moment suis-je capable de les détecter ?

Dans cet article, nous verrons quelles sont les étapes clefs d’une telle opération et comment s’assurer d’en récolter les fruits.

 

ETAPE 1 : DEFINIR L’EQUIPE CŒUR ET IDENTIFIER LE TROPHEE

Définir une équipe de contrôle restreinte est primordiale pour limiter la fuite d’informations vers la Blue Team (équipe de détection, i.e. SOC), fluidifier les communications et faciliter la prise de décision par le client. L’équipe de contrôle devra donc être séparée clairement de la Blue Team. Souvent le choix se porte vers le CISO ou un représentant du COMEX, avec qui il faudra fixer les limites du périmètre et du mode opératoire (les plus larges possibles), pour éviter tout incident malencontreux !

« That’s out of scope » – Said no attacker ever

Ensuite, une particularité d’une opération Red Team est de définir un « trophée », c’est la cible de l’opération. En effet, un attaquant est souvent motivé par un objectif (gain, destruction, espionnage, …) et il convient de calquer les objectifs de la Red Team dessus. La Red Team a en général déjà quelques bonnes idées mais les meilleurs trophées (i.e l’impact le plus fort lors de la restitution) sont étroitement liées aux enjeux business de l’entreprise ainsi que son actualité.

La cible doit être les scénarios qui font le plus froid dans le dos des dirigeants : une prise de contrôle à distance de l’infrastructure SWIFT ? Une compromission des terminaux de paiement ? La fuite de la liste des clients VIP ? Les positions prises ces derniers mois à l’étranger ? Les idées peuvent être nombreuses, mais il est nécessaire de se restreindre à une cible ou deux pour garder en visibilité ce qui est le plus critique. Il sera toujours possible d’identifier un autre trophée pour la prochaine opération : il est même conseillé de modifier les trophées d’une année sur l’autre afin de tester des pans de système d’information différents.

Lors de nos dernières interventions, des COMEX portent leur choix sur des scénarios ayant déjà eu lieu lors de réelles cyberattaques qu’ils avaient subies. Cela leur permet aussi d’évaluer l’efficacité des nouveaux moyens de sécurité mis en œuvre.

 

ETAPE 2 : PREPARER ET LANCER L’ASSAUT EN MELANT EFFICACITE ET FURTIVITE

La crédibilité de l’attaque est un des facteurs clef du succès de l’opération, notamment pour la phase de restitution. Une fois le trophée arrêté : nous construisons une démarche basée sur les techniques utilisées par les groupes d’attaquants.

C’est à ce moment que les retours terrains sont particulièrement utiles ! Chez Wavestone, nous nous appuyons fortement sur notre équipe de réponse à incident (CERT-W) et sa capacité de Threat Intelligence pour identifier les dernières tendances, sur le savoir-faire technique de notre équipe d’audit ainsi que la créativité de notre équipe CTF (Capture The Flag).

Ainsi, la Red Team utilisera l’ensemble des moyens possibles et nécessaires afin de pénétrer sur le SI (campagne de phishing, phishing téléphonique, intrusion physique, compromission de composants exposés sur internet…) et ensuite rebondir vers le trophée. Cette phase est la plus créative et passionnante pour les auditeurs (comme pour les attaquants), et peut potentiellement durer plusieurs semaines, à l’image des cyberattaques les plus médiatisées.

Toutefois, le maître-mot doit rester : « furtivité » ! En effet, la moindre détection par la Blue Team peut totalement faire échouer ou reculer l’opération. Une attention particulière doit être portée sur des outils et infrastructures d’attaque sur mesure pour ne pas affoler les systèmes de détection. Pour le premier point, nous avons développé en interne l’outil Abaddon, désormais open-source, et permettant de construire et déployer en quelques clics les infrastructures nécessaires.

 

Deux questions reviennent systématiquement concernant le déroulement d’une opération Red Team.

La première « Que faire en cas de détection ? ». Qu’une action se fasse détecter peut arriver au cours d’une opération Red Team : une bonne règle de corrélation du SIEM, un utilisateur averti qui partage un comportement anormal, etc.. Tout d’abord, dans l’organisation de base l’équipe de contrôle doit superviser les incidents au sein du SOC afin d’éviter une « sur-escalade » en crise d’un incident en relation avec le Red Team. La cellule de contrôle pourra ainsi demander un rapport à la Blue Team (résumé, comportement détecté, timeline des actions, actions de remédiation, …) et définir ensuite le scénario de reprise avec la Red Team : ne pas tenir compte de la détection car elle est trop ancienne, repartir de l’avant dernier asset compromis qui n’a pas été détecté, etc. De plus, le travail deviendra plus compliqué pour la Red Team qui devra par exemple changer totalement son infrastructure C2 et dorénavant réussir à tromper une Blue Team en alerte.

La seconde « Si les le(s) trophée(s) sont obtenues très rapidement, que faire ?». Imaginons le pire des scénarios : l’administrateur applicatif du trophée se fait piégé par un mail de phishing et nous permet de prendre le contrôle complet de l’application dès le début de l’opération (Tout le monde peut faire une erreur). Le point sera partagé avec l’équipe de contrôle et la marche à suivre sera définie conjointement : ajouter des trophées pour tester la robustesse d’un autre périmètre, repartir de zéro et identifier un autre chemin de compromission, … Cet exemple un peu caricatural est là pour rappeler que l’objectif d’une opération Red Team est d’améliorer durablement le niveau de sécurité via l’entrainement de la Blue Team et non juste l’obtention d’un trophée.

 

ETAPE 3 : RESTITUER UNE REPONSE CLAIRE SUR UN RISQUE METIER CRITIQUE

L’objectif reste d’apporter aux commanditaires une vision claire sur l’état de sécurité réel de leur SI, sur les scénarios d’attaque permettant d’accéder à leurs ressources critiques (identifiées comme « trophées » de l’opération), ainsi que sur leurs capacités de détection. Tout simplement, l’opération Red Team doit permettre de répondre à la question « Le trophée est-il accessible et avec quel niveau d’expertise ? ». Il faut cependant retenir que l’opération Red Team va mettre en valeur un chemin exploitable qui ne sera peut-être pas le seul, ni le plus simple.

Dès lors, nous restituons aux parties prenantes (CISO, SOC, COMEX…) avec une synthèse haut-niveau afin de présenter les conclusions de l’opération Red Team, le scénario d’attaque suivi et les chantiers les plus prioritaires. Les résultats sont généralement comparés à des profils type d’attaquants (Maze, REvil/Sodinoki…) sur le référentiel MITRE ATT&CK pour être plus parlants.

 

Dans un second temps, il faudra évidemment restituer en détails à la Blue Team les étapes techniques de l’opération, en vue de définir des axes de progrès sur la détection.

“If we win, we lose » Said a good red teamer

Cet article Comment tirer parti d’une opération Red Team ? est apparu en premier sur RiskInsight.