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.

Dans cette nouvelle partie, nous partirons du principe qu’un attaquant est parvenu à compromettre un compte Zimbra et que nous avons déjà identifié son point d’entrée (accès initial). Nous allons désormais analyser comment exploiter les journaux Zimbra pour identifier les actions malveillantes que l’attaquant aurait pu réaliser à partir de ses accès. Nous verrons ensuite quelles mesures de remédiation mettre en place pour prévenir ce type d’incident et y répondre efficacement.

Installez-vous confortablement (et assurez-vous que votre café est encore chaud) : entrons sans plus attendre dans le vif du sujet !

Investiguer dans un environnement Zimbra

Maintenant que l’infrastructure et les journaux Zimbra n’ont plus de secrets pour vous, c’est le moment de passer au concret.

Imaginez que vous êtes un analyste forensique, arrivé en avance de bon matin, quand soudain : le téléphone sonne. On vous appelle car plusieurs utilisateurs signalent que des courriels qu’ils n’auraient pas envoyés apparaissent dans leur dossier «Envoyés».

C’est la panique générale !  Les utilisateurs n’osent plus se connecter à leur boîte mail et certains administrateurs commencent à se demander si l’infrastructure Zimbra elle-même ne serait pas compromise.

Puisque vous maîtrisez Zimbra comme personne, c’est naturellement vers vous que l’équipe se tourne pour élucider cet incident !

En tant qu’analyste forensique, beaucoup de questions vous viennent à l’esprit :

• Est-ce que les comptes ont réellement été compromis ? Si oui, comment et depuis quand ?
• Combien d’utilisateurs sont affectés ?
• Quel est l’objectif de l’attaquant et quelles actions malveillantes ont été menées depuis ces comptes ?
• Le serveur de messagerie ou d’autres composants Zimbra ont-ils été compromis ?
• Et, surtout : ai-je le temps de prendre un café avant que la chasse aux informations ne commence ?

Afin de vous aider dans vos investigations, nous allons voir ensemble comment apporter des éléments de réponses via l’analyse des journaux Zimbra. Mais avant cela, voici un ensemble de conseils pour vous aider dans vos investigations

Lors d’une réponse à incidents, il est facile de se sentir submergé par la quantité de journaux et d’événements à analyser. Il est donc important de garder un fil conducteur. Quelques réflexes simples permettent de ne pas perdre le cap :

• Confirmer : Vérifier les informations ayant mené à l’incident. Avant d’avancer dans les investigations, il faut s’assurer de la véracité de l’élément déclencheur. Cette base indéniable servira de pilier pour l’ensemble de l’investigation.
• Corréler : recouper les adresses IP et domaines suspectes avec d’autres sources (proxy, VPN, EDR, bases antivirales en ligne). Cela permet d’obtenir des informations complémentaires en relation avec l’indicateur identifié.
• Pivoter : exploiter les informations collectées pour élargir l’analyse. Un attaquant peut par exemple réutiliser la même adresse IP ou le même user-agent pour cibler plusieurs comptes. À l’inverse, un compte compromis peut être utilisé depuis des adresses IP ou des user-agents différents. Pivoter permet de révéler d’autres indicateurs permettant d’identifier l’attaquant.
• Comparer les motifs : même sans accéder directement au contenu des courriels ou des pièces jointes, certains éléments peuvent révéler des similitudes (taille, nom de fichier identique, séquence d’actions répétée après la compromission d’un compte). Cette approche d’analyse comportementale peut aider à identifier plusieurs utilisateurs compromis par un même attaquant. Ces hypothèses doivent être formulées et manipulées avec prudence mais elles peuvent s’avérer intéressantes pour confirmer une intuition.
• Assurer la conservation des journaux : Cela peut sembler évident, mais dès la détection de l’incident, il est important de sécuriser la conservation des journaux. Cela passe par la collecte immédiate des logs sur l’ensemble de l’infrastructure Zimbra mais aussi par l’allongement de la période rétention pour éviter toute suppression automatique. Car soyons honnêtes : les logs qui disparaissent pile au moment où l’équipe forensique arrive, c’est malheureusement un grand classique… et une mésaventure dont vous vous passerez bien.

Même si ces conseils ne sont pas exhaustifs, ils offrent une bonne base pour réaliser une analyse à la fois rapide et complète.

Activité post compromission

Analyse des actions utilisateur

Quelle maîtrise ! Vous avez réussi à remonter jusqu’au point d’entrée initial emprunté par l’attaquant pour compromettre les comptes utilisateurs. Vous avez identifié les adresses IP malveillantes, repéré l’User-Agent utilisé, et même débusqué d’autres comptes compromis grâce à ces informations. Bref, du travail propre et efficace. Impressionnant !

Mais…. nous n’avons pas encore répondu une question cruciale : « Quel était l’objectif de l’attaquant et quelles actions a-t-il menées depuis les comptes compromis ? »

Pour le découvrir, il va maintenant falloir analyser l’activité de l’attaquant à l’intérieur de l’infrastructure Zimbra. Une fois authentifié, un attaquant peut en effet :

• Lancer une campagne de phishing interne ou externe
• Envoyer des messages visant à pousser un collègue, partenaire ou client à l’action (fraude au président, demande urgente fictive, etc.)
• Exfiltrer des données sensibles depuis les boîtes mail

Dans cette section, nous examinerons quelques exemples d’activités suspectes qui peuvent être identifiées à partir des journaux Zimbra.

Envoi d’un grand nombre de courriels sur une courte période

Vous souhaitez déterminer si des comptes compromis ont été utilisés pour mener d’autres tentatives de phishing en envoyant des e-mails en masse à des destinataires internes ou externes. Malheureusement, Zimbra ne propose pas d’événement natif vous permettant de récupérer directement cette information. Cependant, une petite commande grep vous permettra de parvenir à vos fins.

La commande ci-dessous permet d’extraire le nombre de messages envoyés par chaque utilisateur sur une période précise (ici du 21 au 27 novembre 2025) :

Dans cet exemple, user25@wavestone.corp se démarque clairement avec un volume d’envoi largement supérieur à la normale. Un volume anormalement élevé de courriels émis par une boîte aux lettres sur une période courte constitue une activité suspecte.

Dans un usage légitime, les envois massifs de courriels restent relativement rares et sont généralement associés à des adresses génériques ou à des systèmes de communication interne (ex. newsletters, annonces RH). Lorsqu’un compte utilisateur classique présente ce type de comportement, il est important :

• D’identifier si c’est une activité normale et récurrente de l’utilisateur
• De vérifier la plage horaire, l’adresse IP et l’user-agent d’émission
• De vérifier si des pièces jointes suspectes ont été associées aux envois

Un envoi massif de courriels peut entraîner le déclenchement de mécanismes de protection intégrés à Zimbra, notamment les règles de quota. Ces seuils ont pour but de limiter le volume de messages émis par un compte sur une période donnée afin de prévenir l’abus, le spam ou les campagnes de phishing.

Les deux commandes ci-dessous vous permettent de récupérer les événements liés aux dépassements de quota :

L’apparition de messages d’erreur liés au dépassement de quota constitue un signal à ne pas ignorer, car :

• Soit l’utilisateur légitime a dépassé accidentellement un quota
• Soit le compte est utilisé de manière frauduleuse pour effectuer des envois massifs

Cet indicateur pouvant générer un grand nombre de faux positifs, il est recommandé de le corréler avec d’autres éléments afin d’en tirer des conclusions.

Envoi d’un courriel à un grand nombre de destinataires

Pour éviter de déclencher une alerte de dépassement de quota, un attaquant averti peut adopter une stratégie plus « subtile ». Plutôt que d’envoyer des dizaines de courriels individuels (méthode bruyante), il peut choisir d’envoyer un unique message adressé à une longue liste de destinataires. Une manière d’optimiser son phishing.

Heureusement pour vous, les journaux Zimbra permettent d’identifier le nombre de destinataires associés à chaque envoi, ce qui rend ce type de manœuvre détectable sans trop d’efforts.

Les commandes ci-dessous permettent d’identifier les e-mails envoyés à un grand nombre de destinataires :

Ici vous pouvez observer que l’utilisateur user25@wavestone.corp a envoyé un mail à 211 destinataires. Ce type de comportement est plutôt suspect.

En pratique, il est rare qu’une adresse électronique personnelle envoie des messages à plusieurs dizaines de destinataires simultanément. Ce comportement est davantage associé à des boîtes aux lettres partagées ou les adresses génériques (ex. communication interne, service RH, annonces institutionnelles). Lorsqu’un compte utilisateur classique présente ce type de comportement, il est important :

• D’identifier les pratiques de communication habituelles dans l’organisation
• D’identifier si c’est une activité normale et récurrente de l’utilisateur 
• De vérifier la plage horaire, l’adresse IP et l’user-agent d’émission
• De vérifier si des pièces jointes suspectes ont été associées aux envois

Afin de gagner du temps, il est également possible de valider directement auprès de l’utilisateur si l’envoi du courriel était légitime.

L’exemple présenté ici permet d’identifier les mails comptant plus de 100 destinataires. Toutefois, selon ce que vous considérez comme un volume légitime et en fonction de la période couverte par les journaux analysés, ce seuil doit être adapté au contexte de votre recherche.

Téléversement de pièces jointes suspectes

Contrairement à la réception, le téléversement de pièces jointes suspectes et mieux journalisé par Zimbra. Chaque fois qu’un utilisateur joint un fichier à un nouveau courriel, Zimbra note soigneusement l’opération dans ses journaux.

Grâce aux commandes ci-dessous, vous pouvez retrouver les pièces jointes attachées aux courriels par un éventuel utilisateur compromis :

De la même manière que pour la réception de pièces jointes malveillantes, vous pourrez notamment rechercher dans les journaux :

• le téléversement de pièces jointes aux extensions suspectes (ex. .htm, .html, .exe, .js, .arj, .iso, .bat, .ps1, ou encore des documents Office/PDF contenant des macros)
• les fichiers déjà observés en amont lors des premières phases de l’incident (par exemple un document téléchargé par le patient zéro)
• à corréler les activités de téléversement avec les adresses IP sources malveillantes ou les comptes identifiés comme compromis.

Cette liste n’étant pas exhaustive, il peut être pertinent de rechercher tout type de fichier qui vous semble adapté au contexte de votre investigation.

Suppression des traces

A présent que vous avez une bonne image de ce que l’attaquant a fait avec les comptes compromis. Vous êtes déçus car vous n’arrivez pas à retrouver les mails en question. Vous suspectez que l’attaquant a effacé ses traces. Mais comment le vérifier ?

En effet après avoir envoyés des mails malveillant un attaquant averti peut tenter de dissimuler les traces auprès de l’utilisateur légitime de la boîte mail en supprimant les mails envoyés ou reçus en retour.

Heureusement ces commandes permettront d’identifier les suppressions de mails effectuées dans Zimbra :

Dans un usage légitime, il n’est pas rare qu’un utilisateur supprime plusieurs courriels (ex. nettoyage de boîte de réception, gestion de newsletters). Cependant, la situation devient anormale lorsque la suppression intervient :

• Immédiatement après un envoi massif de mails
• Qu’elle cible spécifiquement les derniers messages envoyés

Dans votre investigation, il faut garder en tête qu’un attaquant pourra également chercher à supprimer :

• Les accusés de réception générés par ses envois
• Les réponses automatiques (out-of-office, NDR) qui pourraient alerter la victime

Il est donc important de ne pas négliger les suppressions et de le corréler avec d’autres indicateurs (authentifications suspectes, envoi massif, dépassement de quota, connexions depuis des IP malveillante) afin d’évaluer la légitimité de ces dernières.

Exfiltration de données

Une question vous taraude encore… parmi les comptes compromis, certains appartenaient à des utilisateurs manipulant des données sensibles pour l’entreprise. Vous souhaitez donc déterminer si l’attaquant a tenté d’exfiltrer certains messages auxquels il a eu accès.

Malheureusement pour vous, Zimbra ne journalise pas le téléchargement direct des mails. Après tout, la récupération via IMAP ou SMTP, consiste en réalité à un “téléchargement” du serveur vers le client mail. Il est donc difficile différencier un tranfert classique d’un téléchargement. Et du côté des logs Nginx (qui exposent le Webmail), même constat, impossible d’identifier précisément qu’un mail a été téléchargé.

En guise de maigre compensation, Zimbra journalise certaines opérations internes, notamment les actions de copie réalisées dans la boîte mail. Un attaquant pourrait, par exemple, créer un dossier pour stocker des mails sensibles avant extraction.

La commande suivante permet notamment de repérer une copie massive de messages dans un dossier (ici nommé « Exfiltration ») depuis le client Web :

La commande suivante permet notamment de repérer une copie massive de messages dans un dossier depuis un client lourd IMAP :

Bien qu’il existe des cas légitimes (ex : sauvegarde manuelle par l’utilisateur), ce type d’activité doit attirer l’attention, surtout lorsqu’il est corrélé avec :

• Des connexions depuis des adresses IP inhabituelles
• Des authentifications suspectes
• Des envois massifs de mails

Mais comme vous pouvez le constater, il est très difficile d’infirmer une exfiltration. Il faut donc considérer que, si une boîte est compromise, l’attaquant a potentiellement eu la possibilité de télécharger l’ensemble des courriels de l’utilisateur concerné.

Détection des solutions antivirus et antispam

On ne l’a pas trop abordé jusqu’à maintenant, mais il faut savoir que Zimbra intègre nativement Amavis, un composant « central » qui orchestre différents moteurs de sécurité. Ces moteurs permettent d’identifier des fichiers suspects, des campagnes de phishing ou encore des envois massifs de spam. Il est donc intéressant d’exploiter ces mécanismes de détection dans le cadre de l’analyse des activités d’un attaquant.

Durant vos investigations, l’examen des messages générés par Amavis permet notamment de mettre en évidence :

• Les messages bloqués avant qu’ils n’atteignent la boîte aux lettres de l’utilisateur (ex. tentatives de spoofing)
• Les pièces jointes malveillantes détectées et placées en quarantaine,
• Le non-respect de certaines politiques de sécurité définies sur la plateforme.

Amavis

Il est possible de récupérer certains événements générés par Amavis avec les commandes suivantes :

Les événements générés par Amavis étant nombreux, il peut être judicieux de concentrer vos recherches sur les détections liées au spam et au phishing. À noter que l’identification des messages de phishing a déjà été abordée dans une section précédente de cet article (« Compromission du compte par attaque de phishing »).

Spams entrants

Il peut être pertinent d’identifier les messages ayant généré des détections de spams entrants. Lorsqu’un message est classé comme spam, Zimbra génère des traces qui indiquent la raison de cette catégorisation.

Ces événements peuvent contenir plusieurs informations intéressantes :

• Le compte concerné,
• L’identifiant unique du message dans la boîte aux lettres,
• L’adresse IP d’origine du mail,
• Additionnellement dans le cas d’un SpamReport :
  • Le résultat de l’analyse (champ isSpam),
  • L’action appliquée (par exemple : déplacement du dossier Inbox vers Junk),
  • Et parfois le destinataire du rapport utilisé pour l’apprentissage ou le signalement (par ex. une adresse dédiée spam@wavestone.corp).

La commande suivante peut vous aider à identifier les événements liés au traitement des spams entrants :

Les détections de spam générant de nombreux faux positifs, il peut être pertinent de réduire au maximum le périmètre de recherche (par exemple en ciblant une période précise ou un ensemble d’utilisateurs spécifiques).

Spams sortants

Le mal ne vient pas toujours de l’extérieur. Certains mails malveillants envoyés depuis des comptes internes compromis vers des destinataires externes peuvent laisser des traces très intéressantes dans les journaux Zimbra. En effet, si le message envoyé par le compte compromis est bloqué par la solution antispam du serveur mail destinataire, ce dernier renverra une notification d’erreur au serveur Zimbra pour signaler le refus.

Analyser ces messages de non-livraison (NDR) peut alors vous mettre la puce à l’oreille :
cela peut révéler qu’un utilisateur est compromis… ou qu’un compte a été utilisé pour tenter d’envoyer des courriels malveillants.

Il est possible d’extraire ces rejets de mails grâce à la commande suivante :

Les spams sortants sont généralement peu nombreux. Toutefois, leur analyse ne devient réellement utile qu’en cas de tentative de latéralisation de l’attaquant vers des comptes mail externes.

Mesures de remédiations

Vous avez mené votre investigation tambour battant : utilisateurs compromis identifiés, adresses IP malveillantes répertoriées, activités suspectes décortiquées… bref, vous avez déroulé le fil de l’attaque avec une précision chirurgicale. Il est maintenant temps de passer à l’étape suivante : la remédiation. 

Celle-ci vise avant tout à supprimer les accès de l’attaquant à l’infrastructure, à mettre en place des mécanismes de détection capables de prévenir de nouvelles tentatives de compromission et à renforcer la sensibilisation des utilisateurs afin de limiter l’impact des campagnes de phishing en cours et à venir.

Via la collecte les différents indicateurs liés à la campagne de phishing (comptes compromis ou suspectés de l’être, adresses e-mail, adresses IP et domaines malveillants, etc.), il est recommandé de mettre en œuvre une série d’actions correctives et préventives (non exhaustives): 

• Réinitialiser les mots de passe des comptes suspects : Pour tout utilisateur compromis ou suspecté de l’avoir été, une réinitialisation du mot de passe est nécessaire.
• Bloquer les domaines, adresses IP et adresses électroniques malveillantes : Les éléments d’infrastructure utilisés par l’attaquant (domaines, IPs, expéditeurs) doivent être bloqués via les solutions réseaux disponibles (proxy, pare-feu, filtres mail) dès leur détection. Cela limitera les risques de propagation.
• Effectuer un scan antivirus/EDR sur les postes des utilisateurs compromis : Les postes de travail des utilisateurs compromis doivent faire l’objet d’une analyse antivirus ou EDR afin de :
  • Détecter et supprimer tout fichier malveillant éventuel
  • Vérifier que les fichiers liés au phishing ne sont plus présents sur le poste
• Renforcer la sensibilisation des utilisateurs : Une communication sur les campagnes de phishing en cours doit être adressée aux utilisateurs afin de prévenir de nouvelles compromissions. Des campagnes régulières de sensibilisation au phishing sont fortement conseillées, en particulier à destination des utilisateurs ayant été compromis.
• Mettre en place l’authentification multifacteur (MFA) pour l’accès aux mails Zimbra : La mise en œuvre d’un second facteur d’authentification est fortement recommandée pour sécuriser l’accès aux boîtes mail. Une telle mesure peut être perçu comme contraignant, l’usage d’un SSO (Single Sign-On) avec MFA unique permet de limiter cette friction tout en renforçant la sécurité globale des authentifications.
• Déployer une solution spécialisée de filtrage et de détection de phishing : il est recommandé de mettre en place une solution spécialisée dans la détection d’activités malveillantes dans les environnements de messagerie. La solution mise en place doit permettre d’identifier :
  • Les connexions depuis des IPs inhabituelles
  • Les tentatives de bruteforce sur les comptes utilisateurs
  • L’envoi massif de mails à de nombreux destinataires
  • L’usage de pièces jointes ou de liens suspects vers des domaines non fiables
  • Les campagnes de phishing actives (identifiées par un service CTI par exemple)

• Assurer la conservation des journaux Zimbra : Il est important de sécuriser la collecte et la conservation des journaux. Pour cela, il est recommandé de centraliser les logs de l’ensemble de l’infrastructure Zimbra sur un serveur externe à cette infrastructure. Cette approche garantit que, même en cas de compromission, de modification ou de chiffrement des serveurs Zimbra, les journaux restent intacts et consultables, permettant ainsi de mener des investigations forensiques fiables.

Bien que non exhaustives, ces mesures de remédiation vous permettront de restaurer la confiance dans votre infrastructure Zimbra et dans les comptes utilisateurs. Il sera toutefois nécessaire de maintenir un effort continu de surveillance et d’amélioration de la posture de sécurité afin de s’adapter aux menaces futures.

Au terme de cette petite enquête, une chose est sûre : si l’attaquant lui peut faire le choix de la facilité, l’analyste forensique, lui, n’a pas cette chance. Entre les journaux éparpillés (ou parfois manquants), les témoignages discordants des utilisateurs ou encore le manque de visibilité sur certains événements Zimbra : mener l’investigation revient parfois à résoudre un Rubik’s Cube… dans le noir… avec des moufles.

Mais avec une bonne méthodologie et quelques réflexes, Zimbra vous révèlera bien plus d’informations qu’on ne pourrait le croire au premier abord. Ses journaux constituent une véritable mine d’or, à condition de ne pas s’y perdre.

In fine, cet article n’a pas la prétention de transformer chaque lecteur en maître Jedi du forensique Zimbra… mais s’il peut vous éviter de passer deux jours à tenter de décoder les journaux Zimbra ou à chercher où dénicher la bonne information, alors l’objectif est atteint !

Et comme on le dit assez souvent, dans la cybersécurité comme ailleurs, mieux vaut prévenir que guérir. Alors durcissez votre infrastructure Zimbra, sauvegardez vos journaux, sensibilisez vos utilisateurs… et surtout, ne négligez pas la réserve de café !

Références

• https://wiki.zimbra.com/wiki/Log_Files
• https://wiki.zimbra.com/wiki/Troubleshooting_Course_Content_Rough_Drafts-Zimbra_Architecture_Component_Overview
• https://wiki.zimbra.com/wiki/Trouble_Shooting_Spam_Score_Changes

Cet article Compromission de boîte mail Zimbra : de l’analyse à la remédiation (Partie 2) est apparu en premier sur RiskInsight.

Dans la majorité des entreprises, les portails d’accès aux messageries sont exposés sur internet et ne bénéficient pas toujours de mécanismes de contrôle d’accès suffisants. De plus, certains services de messagerie proposent des fonctionnalités étendues dépassant la simple consultation des courriels, telles que le partage de fichiers ou l’accès à des applications collaboratives.

Les services de messagerie peu sécurisés représentent donc une cible de premier choix pour les attaquants. En effet, la compromission d’une boîte mail permet par la suite de lancer des campagnes de phishing, d’accéder à des données sensibles, de réaliser des actions de fraude ou encore d’obtenir l’accès à d’autres services.

Au CERT-W, nous intervenons régulièrement sur ce type de compromissions. En particulier, plusieurs de nos investigations en 2025 ont impliqué la compromission de comptes de messagerie Zimbra, une solution utilisée dans de nombreuses organisations publiques et privées. Face à ces incidents, nous nous sommes aperçus d’un manque criant de documentation forensique spécifique aux infrastructures Zimbra.

Cet article est donc notre humble contribution visant à combler ce vide. Nous y partageons une approche pragmatique et quelques astuces pour gagner du temps dans vos analyses sur ce type d’environnement, ainsi que quelques actions de remédiation.

L’infrastructure Zimbra

Si vous n’êtes pas encore familier avec les infrastructures Zimbra, pas de panique : cette section est là pour vous ! Pour les plus initiés, vous pouvez directement filer à la section investigation (on ne vous en voudra pas).

L’architecture

Zimbra, ce n’est pas juste « un serveur mail de plus ». C’est toute une suite collaborative open source assez complète, qui réunit plusieurs briques bien pratiques :

• Un serveur de messagerie : le cœur du système.
• Un gestionnaire de calendriers, contacts et tâches : pour ne jamais oublier la réunion de 9h.
• Un client web : accessible depuis n’importe quel navigateur.
• Des services complémentaires : antispam, antivirus, synchronisation mobile, etc.

Mais comme toute infrastructure utilisée par des centaines (voire des milliers) d’utilisateurs en simultané, le dimensionnement et la performance deviennent vite des sujets importants. C’est pourquoi Zimbra peut être déployé de deux façons :

• En mode monolithique : tout sur un seul serveur (simple, efficace… jusqu’à un certain point).
• En mode distribué : plusieurs serveurs, chacun avec un rôle précis, pour mieux gérer la charge, la disponibilité et la maintenance.

Schématiquement, une infrastructure Zimbra distribuée ressemble à ceci :

Bien que l’architecture puisse varier, on retrouve généralement les composants suivants :

• Serveur Proxy : il constitue le point d’entrée pour les clients Web, IMAP/POP et ActiveSync. Les journaux générés à ce niveau fournissent une visibilité sur les connexions utilisateurs (adresses IP, user agent, dates, etc.).
• Serveur Web Client (Mailboxd UI) : il héberge l’interface Webmail utilisée par les utilisateurs pour accéder à leur messagerie via un navigateur.
• Serveur de messagerie (Mailboxd) : il héberge les boîtes aux lettres des utilisateurs et assurent la gestion des messages, dossiers et calendriers. Ce composant génère les journaux les plus riches (par ex. mailbox.log, audit.log, sync.log).
• Serveur MTA (Message Transfer Agent): il reçoit les courriels via SMTP et acheminent les messages, à l’aide du protocole LMTP (Local Mail Transfer Protocol) vers le serveur de messagerie Zimbra approprié.
  Le rôle du MTA Zimbra repose sur plusieurs services complémentaires :
  • Postfix MTA : routage, relais et filtrage des messages (y compris des pièces jointes).
  • ClamAV : moteur antivirus chargé d’analyser les messages et leurs pièces jointes.
  • SpamAssassin et DSPAM : filtres de spam exploitant divers mécanismes pour identifier les courriels indésirables.
  • Amavis : orchestrateur qui exécute les moteurs antivirus et antispam configurés, puis applique les politiques de traitement sur les messages entrants.

Le serveur MTA occupe une place particulière dans l’infrastructure Zimbra. C’est à ce niveau que s’effectue la majorité des contrôles de sécurité appliqués aux courriels entrants. Le schéma ci-dessous présente les principales étapes de ce parcours d’analyse :

Dans le processus de réception d’un courriel entrant, le message est d’abord pris en charge par Postfix. Celui-ci le transfère ensuite à Amavis pour analyse.
Amavis va ensuite récupérer les différents moteurs d’analyse configurés et va soumettre le courriel à chacun d’eux afin d’obtenir leurs résultats.
En fonction des politiques définies, Amavis rend un verdict à Postfix : délivrer le message, le bloquer ou le déplacer vers un dossier spécifique.

Les journaux

À présent que vous êtes un expert en architecture Zimbra (ou presque ), vous avez sans doute remarqué que de nombreux services sont nécessaires pour assurer l’envoi et la réception des courriels des utilisateurs. La bonne nouvelle c’est que chacun de ces services génère ses propres journaux, offrant ainsi une visibilité non négligeable sur l’activité de l’infrastructure de messagerie. Et pour nous, analystes forensiques, c’est une excellente nouvelle ! Car on adore les journaux !

L’étude des logs générés par Zimbra nous permettra en effet de reconstituer la chronologie d’une compromission, identifier les boîtes compromises, repérer des pièces jointes malveillantes ou encore détecter d’éventuels rebonds internes.

Cette richesse d’informations est rendue possible grâce aux journaux principalement localisés dans :

• /opt/zimbra/log/mailbox.log : journal principal des activités utilisateurs (authentifications, envois/réceptions, manipulations de mails, dossiers, contacts, calendriers, etc.).
• /opt/zimbra/log/access_log : journal des accès Webmail (adresses IP, user-agents, URLs consultées).
• /opt/zimbra/log/audit.log : traces d’authentification (succès, échecs, mécanismes utilisés).
• /opt/zimbra/log/sync.log : traces des synchronisations mobiles (ActiveSync/EAS).
• /opt/zimbra/log/convertd.log : traces de conversion de fichiers (aperçus webmail, indexation).
• /opt/zimbra/log/clamd.log| /opt/zimbra/log/freshclam.log : activité de l’antivirus ClamAV.
• /opt/zimbra/log/spamtrain.log : traces de l’entraînement antispam initié par les utilisateurs.
• /opt/zimbra/log/cbpolicyd.log : application des politiques Postfix (quotas, anti-relay, restrictions).
• /var/log/mail.log : logs système Postfix (SMTP, LMTP, Amavis).
• /var/log/nginx.access.log | /var/log/nginx.log : journaux du serveur web nginx (utiles pour contextualiser les sessions web).

Malheureusement, dans une architecture Zimbra distribuée, les journaux ne sont pas centralisés. Autrement dit, pour obtenir une vision complète d’un incident, l’analyste devra souvent collecter les logs sur chaque nœud : proxy, mailstore, MTA ou tout autre serveur périphérique. Oui, cela demande un peu de gymnastique (et de patience).

Nous l’avons dit : la richesse des journaux Zimbra est une véritable mine d’or pour les investigations… mais… comme toute mine, il faut savoir creuser avec méthode, sans quoi on se retrouve vite enseveli sous des tonnes de lignes de logs. Un effort de tri et de corrélation est donc nécessaire pour extraire les informations pertinentes.

Et malgré leur utilité indéniable, les journaux Zimbra présentent quelques limites notables :

• Une impossibilité d’accès au contenu complet des courriels ni à leurs pièces jointes.
• Des sujets des courriels rarement disponibles, sauf lorsqu’ils sont interceptés par les modules antispam ou antivirus.
• Un manque de visibilité native sur la création de règles de redirections.
• La rotation rapide des journaux verbeux (comme mailbox.log), ce qui limite la fenêtre temporelle d’analyse en absence de centralisation des journaux.

Investiguer dans un environnement Zimbra

Maintenant que l’infrastructure et les journaux Zimbra n’ont plus de secrets pour vous, c’est le moment de passer au concret.

Imaginez que vous êtes un analyste forensique, arrivé en avance de bon matin, quand soudain : le téléphone sonne. On vous appelle car plusieurs utilisateurs signalent que des courriels qu’ils n’auraient pas envoyés apparaissent dans leur dossier «Envoyés».

C’est la panique générale !  Les utilisateurs n’osent plus se connecter à leur boîte mail et certains administrateurs commencent à se demander si l’infrastructure Zimbra elle-même ne serait pas compromise.

Puisque vous maîtrisez Zimbra comme personne, c’est naturellement vers vous que l’équipe se tourne pour élucider cet incident !

En tant qu’analyste forensique, beaucoup de questions vous viennent à l’esprit :

• Est-ce que les comptes ont réellement été compromis ? Si oui, comment et depuis quand ?
• Combien d’utilisateurs sont affectés ?
• Quel est l’objectif de l’attaquant et quelles actions malveillantes ont été menées depuis ces comptes ?
• Le serveur de messagerie ou d’autres composants Zimbra ont-ils été compromis ?
• Et, surtout : ai-je le temps de prendre un café avant que la chasse aux informations ne commence ?

Afin de vous aider dans vos investigations, nous allons voir ensemble comment apporter des éléments de réponses via l’analyse des journaux Zimbra. Mais avant cela, voici un ensemble de conseils pour vous aider dans vos investigations

Lors d’une réponse à incidents, il est facile de se sentir submergé par la quantité de journaux et d’événements à analyser. Il est donc important de garder un fil conducteur. Quelques réflexes simples permettent de ne pas perdre le cap :

• Confirmer : Vérifier les informations ayant mené à l’incident. Avant d’avancer dans les investigations, il faut s’assurer de la véracité de l’élément déclencheur. Cette base indéniable servira de pilier pour l’ensemble de l’investigation.
• Corréler : recouper les adresses IP et domaines suspectes avec d’autres sources (proxy, VPN, EDR, bases antivirales en ligne). Cela permet d’obtenir des informations complémentaires en relation avec l’indicateur identifié.
• Pivoter : exploiter les informations collectées pour élargir l’analyse. Un attaquant peut par exemple réutiliser la même adresse IP ou le même user-agent pour cibler plusieurs comptes. À l’inverse, un compte compromis peut être utilisé depuis des adresses IP ou des user-agents différents. Pivoter permet de révéler d’autres indicateurs permettant d’identifier l’attaquant.
• Comparer les motifs : même sans accéder directement au contenu des courriels ou des pièces jointes, certains éléments peuvent révéler des similitudes (taille, nom de fichier identique, séquence d’actions répétée après la compromission d’un compte). Cette approche d’analyse comportementale peut aider à identifier plusieurs utilisateurs compromis par un même attaquant. Ces hypothèses doivent être formulées et manipulées avec prudence mais elles peuvent s’avérer intéressantes pour confirmer une intuition.
• Assurer la conservation des journaux : Cela peut sembler évident, mais dès la détection de l’incident, il est important de sécuriser la conservation des journaux. Cela passe par la collecte immédiate des logs sur l’ensemble de l’infrastructure Zimbra mais aussi par l’allongement de la période rétention pour éviter toute suppression automatique. Car soyons honnêtes : les logs qui disparaissent pile au moment où l’équipe forensique arrive, c’est malheureusement un grand classique… et une mésaventure dont vous vous passerez bien.

Même si ces conseils ne sont pas exhaustifs, ils offrent une bonne base pour réaliser une analyse à la fois rapide et complète.

Compromission et accès initial

Le piège du spoofing

Vous n’êtes pas dupe ! Vous savez que parfois, l’on peut croire que l’attaquant est déjà à l’intérieur du système alors qu’en réalité, il est toujours à l’extérieur (fake it until you make it ). Surtout lorsque plusieurs utilisateurs commencent à signaler des incidents préoccupants, tels que :

• « J’ai reçu un e-mail de telle personne, pourtant elle m’affirme ne jamais l’avoir envoyé »
• « J’ai reçu un e-mail venant de ma propre adresse, ce qui n’a aucun sens ! »

Mais votre expérience vous pousse à vérifier que la confusion actuelle n’est pas le fruit d’une simple attaque… de spoofing.

En effet, le spoofing est une technique d’usurpation d’identité assez simple utilisée par des acteurs malveillants pour falsifier des informations d’en-tête ou d’origine d’un mail afin de tromper une victime. Le spoofing permet d’envoyer un courriel en se faisant passer pour un expéditeur légitime (par exemple un utilisateur interne de l’entreprise ou le destinataire lui-même), alors que le mail provient en réalité d’une infrastructure qui n’a aucune autorisation pour utiliser cette adresse électronique.

L’objectif est de gagner la confiance du destinataire pour l’inciter à réaliser une action (cliquer sur un lien, ouvrir une pièce jointe, fournir des identifiants, etc.) ou de contourner les mécanismes de filtrage.

Les mécanismes tels que SPF, DKIM et DMARC ont été conçus pour limiter les risques liés au spoofing en permettant de vérifier l’authenticité du domaine et du serveur expéditeur.

Plus particulièrement, le Sender Policy Framework (SPF) est un mécanisme de sécurité des courriels qui permet de vérifier que le serveur expéditeur d’un message est bien autorisé à envoyer des courriels pour le domaine indiqué dans l’adresse de l’expéditeur. Les étapes d’un contrôle SPF sont illustrées ci-dessous :

Concrètement, le propriétaire du domaine publie dans les enregistrements DNS une liste des adresses IP autorisées à envoyer des mails pour son domaine. Lorsqu’un serveur de mail reçoit un courriel, il peut comparer l’adresse IP de l’expéditeur à cette liste et déterminer si le message est légitime ou potentiellement frauduleux.

Un échec du contrôle SPF indique que le courriel a été envoyé depuis un serveur non autorisé par le domaine de l’expéditeur. C’est un indicateur qui permet de d’identifier de potentielles tentatives d’usurpation d’identité.

Dans les journaux Zimbra, il est possible d’identifier les échecs de contrôle SPF à l’aide de la commande suivante :

Dans cet exemple, on constate que le message en provenance de attacker@microsoft.com vers user25@wavestone.corp ne valide pas le SPF (SPF_FAIL). Le champ « Yes » indique qu’il est classé comme spam. Son score (9.172) dépassant le seuil requis (4), ce message ne sera donc pas délivré à son destinataire.

Il ne faut cependant pas donner une confiance aveugle au moteur antispam ! Certains courriels échouant le contrôle SPF peuvent malgré tout être délivrés. Pour extraire exclusivement ces messages, vous pouvez utiliser la commande suivante :

Dans l’exemple ci-dessous, le message échoue le contrôle SPF, mais son score est négatif (-2.06) et inférieur au seuil de spam (4). Il est donc considéré comme légitime et délivré au destinataire, malgré l’échec SPF.

Comme vous pouvez le constater, grâce aux journaux Zimbra, il est possible d’identifier rapidement les expéditeurs à l’origine d’attaques de spoofing. Détecter un cas de spoofing dès le début de l’investigation permet de réduire rapidement les inquiétudes et de restaurer un certain niveau de confiance dans l’infrastructure Zimbra.

Analyse de l’accès initial de l’attaquant

Une fois que vous avez confirmé que vous n’êtes pas face à une attaque de spoofing, c’est que l’attaquant a réussi, d’une manière ou d’une autre, à compromettre un compte ou un composant de l’infrastructure. La première étape de votre investigation va consister à identifier le point d’entrée initial de l’attaquant. C’est trouver la réponse aux questions «Où ?», «Quand ?» et «Comment ?». Mais pour compromettre une boîte mail, plusieurs approches sont possibles…

Compromission de compte via brute force du mot de passe

Une première piste que vous pouvez explorer est la possibilité que l’attaquant ait tenté de compromettre certains comptes au moyen d’une attaque par force brute.

Pour cela, il suffit d’examiner dans les journaux Zimbra les échecs d’authentification :

Sur les événements ci-dessus, on observe des tentatives d’authentification provenant de l’adresse IP 100.100.4.111 qui ont échouées pour le compte user25@wavestone.corp.

Un nombre important de tentatives de connexion infructueuses, sur une courte période, depuis une même adresse IP ou envers un même compte, est révélateur d’une tentative de brute force.

Un trop grand nombre d’échecs d’authentification peut également entraîner le verrouillage automatique d’un compte par Zimbra :

Du point de vue forensique, l’apparition d’un tel événement dans les journaux peut suggérer qu’un compte à potentiellement été ciblé.

Une fois la tentative de brute force identifiée. Il est possible de vérifier à quels moments l’attaquant aurait utilisé le compte compromis en analysant les connexions réussies associées à cet utilisateur :

Additionnellement, si vous avez identifié l’IP de l’attaquant, vous pouvez retrouver l’ensemble des connexions réussies depuis cette adresse avec les commandes suivantes :

Une fois les connexions réussies malveillantes identifiées, il est nécessaire d’analyser l’activité du compte postérieure à ces accès afin d’identifier les actions effectuées par l’attaquant.

Compromission de compte par attaque de phishing

Si aucun brute force n’a été identifié. Une autre piste fréquente de compromission initiale est le bien regretté phishing. Ici, l’attaque ne se déroule pas directement « sur » l’infrastructure Zimbra : l’utilisateur a d’abord reçu un courriel l’incitant à visiter une page frauduleuse ou à ouvrir un fichier malveillant. Et ce n’est qu’après avoir cliqué que le mal sera fait (récupération des identifiants de connexion ou jetons de session).

Dans ce scénario, il faudra, si possible, récupérer le courriel malveillant dans la boîte mail de l’utilisateur pour analyse. Si vous arrivez à mettre la main dessus, voici les informations intéressantes à collecter :

• Date et heure de réception
• Objet du message
• Expéditeur (From)
• Destinataires (To, Cc)
• Adresses de réponse (Reply-To, Return-Path)
• Adresse IP du serveur d’envoi d’origine
• Noms des fichiers joints (le cas échéant)
• Résultats des contrôles SPF, DKIM et DMARC
• URL de phishing identifiées (si présentes)

Ces éléments vous permettront de reconstituer la méthodologie de l’attaquant, d’orienter vos investigations et de définir les premières mesures de remédiation.

Malheureusement, dans le scénario où vous n’avez pas directement accès à la boîte mail de l’utilisateur, il faudra essentiellement se reposer sur les journaux Zimbra, et plus précisément, les événements générés par Amavis lors de l’analyse des courriels entrants.

Supposons que vous souhaitez identifier des pièces jointes malveillantes envoyées par un attaquant aux utilisateurs. Pour cela, les journaux générés par Zimbra sont très utiles car ils permettent d’identifier les fichiers qui ont été analysés et d’en extraire des informations comme leur nom, leur taille, leur type ou encore leur empreinte (SHA1).

La commande suivante permet d’identifier les pièces jointes traitées par Amavis lors de l’analyse des messages entrants :

Le résultat ci-dessus montre que le fichier Evil.htm a été analysé par Amavis. On y retrouve plusieurs informations plutôt intéressantes :

• La date et l’heure : 12 novembre à 11h15
• La signature SHA-1 du fichier : 9d57b71f9f758a27ccd680f701317574174e82d8
• La taille : 22111 octets
• Le Content-Type : text/html
• L’ID de session Amavis associé à cette analyse : 4384125-19

Cependant, à eux seuls, ces éléments ne permettent pas de déterminer quels utilisateurs ont reçu cette pièce jointe ni qui en était l’expéditeur. Pour obtenir ces informations, il est nécessaire d’exécuter une seconde commande afin de récupérer l’ensemble des traces associées à cette session Amavis :

De ces informations vous pouvez à présent en déduire que attacker@example.com a envoyé le fichier Evil.htm de 22111 octets à user25@wavestone.corp le 12 novembre à 11h15, dont la signature SHA-1 est 9d57b71f9f758a27ccd680f701317574174e82d8. Pas si mal, non ?

Au cours de vos investigations, vous pourrez filtrer davantage les résultats de ces commandes afin d’identifier :

• Les pièces jointes avec des extensions suspectes (ex. .htm, .html, .exe, .js, .arj, .iso, .bat, .ps1, ou encore des documents Office/PDF contenant des macros)
• Les fichiers déjà observés en amont lors des premières phases de l’incident (par exemple un fichier téléchargé par le patient zéro)

Lors d’une campagne de phishing impliquant l’envoi d’un fichier malveillant, un attaquant a souvent tendance à diffuser le même fichier à plusieurs utilisateurs. Il est donc possible de s’appuyer sur une analyse statistique pour faire ressortir des valeurs anormales.

La commande suivante permet d’identifier des fichiers identiques présents dans différents mails entrants :

La commande ci‑dessus permet de récupérer, pour chaque pièce jointe des messages reçus par Zimbra, le nombre de fois où elle a été observée dans d’autres mails, en se basant sur son nom et sa signature (SHA‑1).

Dans cet exemple, le fichier Evil.htm apparaît dans 40 courriels, ce qui, combiné à son extension .htm, le rend particulièrement suspect. Il serait donc pertinent de tenter de récupérer ce fichier auprès des utilisateurs concernés afin d’en vérifier la légitimité.

Si l’analyse des pièces jointes ne vous a pas permis de dénicher le coupable, il reste une dernière piste à explorer : la récupération des détections de phishing par SpamAssassin (un moteur antispam exécuté par Amavis).

La commande suivante permet de repérer les messages suspectés de phishing par SpamAssassin :

Cependant, cette commande ne fournit que des informations limitées : l’expéditeur, le destinataire et les règles de détection qui ont été déclenchées. Pour obtenir davantage de détails sur l’analyse complète, il faut récupérer l’ID de session Amavis associé au message (ici 765283-08), puis exécuter la commande suivante :

Cette seconde commande permet d’accéder à des informations supplémentaires générées lors de l’analyse du message par Amavis.

Il faut toutefois interpréter les résultats de SpamAssassin avec prudence car ses règles de détection peuvent générer un nombre important de faux positifs.

Exploitation d’une vulnérabilité sur le serveur web Zimbra

Votre expérience d’investigateur forensique vous l’a appris : ce n’est ni la première, ni la dernière fois qu’une vulnérabilité applicative permet à un attaquant de détourner des sessions utilisateur. Zimbra n’échappe pas à cette règle et son serveur web, qui expose l’accès aux boîtes mail, peut très bien être vulnérable à ce type d’attaque.

La compromission du serveur web Zimbra pourrait, en théorie, permettre à un attaquant de capturer des identifiants des utilisateurs qui se connectent. « Mais comment vérifier si Zimbra a subi des tentatives d’intrusion Web ? » me direz-vous ?

Un premier réflexe consiste à inspecter les journaux du proxy (nginx) afin d’identifier des requêtes HTTP malveillantes ou suspectes dirigées vers l’interface web :

Parmi les indicateurs à rechercher dans les journaux, on retrouve notamment :

• Requêtes POST ou PUT inhabituelles ou vers des endpoints inattendus
• Tentatives d’injection (SQLi, LFI, RCE visibles dans les URI ou paramètres)
• Accès répétés à des ressources non publiques ou à des scripts atypiques
• User-Agents étranges ou une forte concentration de requêtes depuis une même IP
• Nombreuses erreurs 4xx/5xx sur des chemins sensibles (détection de scanner/scan d’énumération)
• Indices d’upload de fichiers (tentatives d’accès à /tmp, /uploads, etc.) ou hits sur des web shells connus.

Si vous observez des requêtes malveillantes ayant abouti (par exemple avec un code HTTP 200), il est recommandé de mener des investigations plus approfondies sur le serveur afin de déterminer si l’exploitation a réellement réussi ou non.

Compromission du poste de travail de l’utilisateur

Si aucun des scénarios précédents ne semble correspondre à ce que vous observez et que le point d’entrée initial reste introuvable, il est possible que l’attaquant ait récupéré les identifiants d’accès directement sur le poste de travail de l’utilisateur.

Ce type de compromission peut survenir, par exemple :

• À la suite d’une campagne de phishing antérieure
• Parce-que l’utilisateur a exécuté un programme malveillant sur sa machine (crack, logiciel téléchargé sur un site douteux, branchement d’une clé USB infectée, etc.).

Une fois en mesure d’exécuter du code sur le poste, l’attaquant peut facilement extraire les identifiants stockés dans le navigateur, récupérer des cookies de session, ou même installer un keylogger pour intercepter les frappes clavier.

La détection de ce type de compromission dépasse le cadre de cet article. Mais gardez cette hypothèse en tête : si aucune trace d’intrusion n’apparaît dans Zimbra, le problème vient peut-être d’ailleurs .

Oui ! L’investigation est loin d’être terminée ! Mais cette première partie vous a permis de maîtriser l’architecture de Zimbra, de comprendre les différentes sources d’éléments de preuve et d’observer qu’à travers les journaux Zimbra, il est possible d’identifier plusieurs techniques de compromission. Cependant, l’accès initial ne constitue que le point de départ de nos recherches. Dans une seconde partie, nous poursuivrons l’analyse post–accès initial. Dans un premier temps, nous tenterons d’identifier les actions malveillantes effectuées par l’attaquant après la compromission d’un compte. Dans un second temps, nous passerons en revue les différentes mesures de remédiation à mettre en œuvre. La suite arrive bientôt: un article complémentaire sera publié pour approfondir ces étapes!

Références

• https://wiki.zimbra.com/wiki/Log_Files
• https://wiki.zimbra.com/wiki/Troubleshooting_Course_Content_Rough_Drafts-Zimbra_Architecture_Component_Overview
• https://wiki.zimbra.com/wiki/Trouble_Shooting_Spam_Score_Changes

Cet article Compromission de boîte mail Zimbra : de l’analyse à la remédiation (Partie 1) est apparu en premier sur RiskInsight.

A l’occasion du lancement du mois européen de la cybersécurité et pour les Assises de la Sécurité (du 13 au 16 octobre 2021), le cabinet Wavestone dévoile la nouvelle édition de son benchmark des incidents de cybersécurité. Pour cela, le cabinet a passé en revue les interventions de son équipe de gestion de crise le CERT-Wavestone entre septembre 2020 et octobre 2021.

Cela représente 60 incidents de sécurité majeurs ayant mené à l’interruption d’activités ou à une compromission avancée du SI et ce, dans des secteurs diversifiés : industrie, secteur public, agroalimentaire, technologies de l’information, finance, etc. L’objectif de ce benchmark est d’éclairer et de montrer l’évolution de l’état de la menace cyber en France, tout en partageant les clés pour une meilleure anticipation et réaction.

« Les groupes de cybercriminels ont réussi leur transformation numérique et leur organisation en plateforme a permis de massifier et rendre plus efficace et rapide leur attaque » Gérôme Billois, Partner Cybersécurité

Au-delà du simple blocage du SI, la combinaison avec un vol de données devient de plus en plus présente. En effet, 30% des attaques ransomwares observées combinent le blocage du SI et le vol de données, ce dernier constituant un levier supplémentaire pour obtenir des gains financiers.

Des attaques ransomwares plus rapides et plus ciblées

Nous constatons une réduction du temps moyen entre l’accès initial et le déploiement du ransomware dans le système avec un minimum de 3 jours pour l’attaque la plus rapide et une moyenne de 25 jours sur les cas gérés. Les attaquants sont de plus en plus déterminés à nuire à leurs victimes. En effet, ils vont maintenant jusqu’à cibler et détruire les mécanismes de sauvegarde pour forcer le paiement de la rançon (21% des cas).

Nous constatons également que dans 90% des cas des données ont été perdues irrémédiablement. A noter, nous observons une baisse significative du paiement des rançons cette année (de 20% l’année précédente à 5% des cas). De multiples facteurs peuvent expliquer cette baisse, entre la meilleure compréhension du faible intérêt à payer (le paiement de la rançon n’accélérant en rien le temps de résolution de la crise), les actions de sensibilisation et de pression sur les intermédiaires de paiements par les différentes autorités.

D’autres types d’attaques sévissent toujours en toile de fond

La menace ransomware ne doit pas faire oublier les attaques de vols de données, de fraude et le gain de capacité d’attaques qui restent bien présentes (25%) même si celles-ci sont moins fréquentes.

En ce qui concerne les canaux d’accès pour s’introduire dans les systèmes, les principales portes d’entrée restent l’utilisation de comptes valides (23%), les emails frauduleux, phishing pour obtenir des informations (20%) et les services d’accès distants en utilisant des failles de sécurité ou des défauts de configuration (18%).

Comment ne pas être une cible facile ? Quelques conseils du CERT-W

56% des victimes n’avaient pas anticipé être la cible potentielle d’une cyberattaque. Elles n’étaient ni dotées d’un contrat de réponse à incident ni d’une cyber assurance et 42% des victimes n’avaient pas réfléchi à leur résilience en cas d’attaque.

« Même si des actions diplomatiques et judiciaires ont permis d’affaiblir l’écosystème cybercriminels, il ne s’agit pas de stopper les efforts, il faut se préparer dès maintenant grâce à des actions simples à mettre en place. » Nicolas Gauchard, Responsable du CERT Wavestone

Les actions les plus importantes sont connues :

• Identifier et protéger les systèmes et les données les plus critiques sans oublier les systèmes techniques comme l’Active Directory
• Améliorer l’efficacité de la détection des attaques avec un service spécialisé 24/7
• Savoir gérer une crise majeure en s’entrainant grâce à des exercices de gestion de crise
• Renforcer la sécurité des sauvegardes et s’entrainer à reconstruire en urgence
• Souscrire à une cyberassurance et un contrat auprès de service spécialisé en cas de crise

Cet article Cyberattaques en France : le ransomware, menace numéro 1 est apparu en premier sur RiskInsight.

Cet article CERT-W Newsletter Février 2021 est apparu en premier sur RiskInsight.

Cet article CERT-W Newsletter Janvier 2021 est apparu en premier sur RiskInsight.

Cet article CERT-W Newsletter Décembre 2020 est apparu en premier sur RiskInsight.

Cet article CERT-W Newsletter Novembre 2020 est apparu en premier sur RiskInsight.

Cet article CERT-W Newsletter Octobre 2020 est apparu en premier sur RiskInsight.

Les indicateurs du mois

Top attack – La compagnie française d’affraitement CMA CGM frappée par une attaque ransomware

Le transporteur français CMA CGM annonce avoir été touché par une attaque de type ransomware, qui a désactivé son système de réservation et affecté un certain nombre de ses bureaux chinois. Le groupe de cybercriminels RagnarLocker leur aurait demandé de les contacter dans les deux jours « via un chat en direct et de payer la clé de déchiffrement ». CMA CGM avait interrompu, par mesure de précaution, les accès externes à son réseau et à ses applications informatiques afin d’éviter la propagation du logiciel malveillant. Les opérations maritimes et portuaires, quant à elles, se sont poursuivies.

Top exploit – Zerologon: Microsoft signale des attaques

Microsoft annonce avoir détecté des attaques exploitant la faille Zerologon. Plusieurs Proof of Concept ont été publiés en ligne au cours des derniers jours. Le patch corrigeant cette importante vulnérabilité dans NetLogon est disponible depuis le mois d’août. La faille Zerologon, évaluée à une criticité de 10 sur 10 par le CVSS, permet de compromettre les contrôleurs de domaines Windows des entreprises comme Active Directory.

Top leak – Microsoft Bing subit une énorme fuite de 6.5TB de données utilisateur

La société WizCase a découvert un serveur non sécurisé contenant une vaste base de données de journaux de recherches effectuées via l’application officielle Bing. Ce serveur contenait 6,5 To de données, en hausse de 200 Go chaque jour, et était protégé par mot de passe dans le passé, mais ce dernier fut retiré durant la première semaine de septembre, laissant la possibilité à des pirates d’effectuer plusieurs attaques de type Meow.

Veille sur la cybercriminalité

Un rapport du CISA américain dévoile des détails sur les webshells utilisés par les pirates iraniens

L’Agence de Cybersécurité et Sécurité des Infrastructures américaine (CISA) a publié un MAR (Malware Analysis Report) divulguant des détails techniques sur les webshells utilisés par des cybercriminels iraniens. Selon ce rapport, ces pirates, d’un groupe APT encore non nommé, attaquent, à l’aide de plusieurs webshells connus, des entreprises gouvernementales, financières, d’assurance, d’IT et du domaine médical à travers les Etats Unis. Parmi ces malwares, on peut retrouver le ChunkyTuna, Tiny, et China Chopper.

Deux russes inculpés pour avoir dérobé 17 millions de dollars par attaque de phishing

Les autorités américaines ont annoncé des accusations criminelles et des sanctions financières contre deux hommes russes accusés d’avoir volé près de 17 millions de dollars de devises virtuelles lors d’une série d’attaques de phishing en 2017 et 2018 qui ont usurpé des sites Web pour certains des échanges de crypto-monnaie les plus populaires.

Des failles de Google Chrome ouvrent la porte aux attaques

La version 85.0.4183.121 de Google Chrome sur Windows, Mac et Linux corrige 10 vulnérabilités. Selon Google, on retrouve parmi les exploitations les plus graves, le fait qu’un attaquant pourrait exécuter du code arbitraire dans le contexte du navigateur. Les versions de Google Chrome antérieures à 85.0.4183.121 sont concernées par ces failles de sécurité.

Veille sur les vulnérabilités

CVE – 2020 – 1472 – Vulnérabilté dans Microsoft Netlogon

Score CVSS : 10.0 CRITICAL

L’exploitation de cette vulnérabilité peut entraîner une élévation de privilèges sur les contrôleurs de domaine ayant pour conséquence l’accès à l’ensemble des ressources gérées par les domaines Active Directory.

CVE – 2020 – 0922 – Vulnérabilité d’exécution de code a distance dans Microsoft COM pour Windows

Score CVSS : 8.8 HIGH

Il existe une vulnérabilité permettant l’exécution de code à distance quant à la manière dont Microsoft COM pour Windows traite les objets en mémoire. Un attaquant qui parviendrait à exploiter cette vulnérabilité pourrait exécuter du code arbitraire sur un système cible.

* Component Object Model (COM) est une technique de composants logiciels développée par Microsoft et DEC, Utilisée pour mettre en œuvre OLE et ActiveX, COM est dépassé depuis 2009 par le Framework .NET de Microsoft.

CVE – 2020 – 1380 – Vulnérabilité d’altération de mémoire dans le moteur de script

Score CVSS : 7.5 HIGH

Il existe une vulnérabilité permettant l’exécution de code à distance quant à la manière dont le moteur de script traite les objets en mémoire dans Internet Explorer. Cette vulnérabilité pourrait altérer la mémoire et permettre à un attaquant d’exécuter du code arbitraire dans le contexte de l’utilisateur actuel.

Cet article Revue de l’actualité par le CERT-W – Septembre 2020 est apparu en premier sur RiskInsight.

Veille sur la cybercriminalité

Le « Patch Tuesday » de Microsoft le plus conséquent depuis sa création

Microsoft a publié le 10/03/2020 des mises à jour afin de corriger pas moins de 115 failles de sécurité affectant ses différents systèmes d’exploitation Windows et logiciels associés. Parmi ces failles, 26 sont considérées comme « critiques », le niveau de sévérité le plus élevé, et l’exploitation de certaines d’entre elles permettent d’effectuer de l’exécution de code à distance et de prendre le contrôle d’ordinateurs vulnérables sans aucune action nécessaire de la part des utilisateurs.

Mukashi : la nouvelle variante du tristement célèbre botnet Mirai cible les NAS Zyxel

Le botnet Mukashi effectue des attaques de type brute-force sur des hôtes aléatoires en utilisant différentes combinaisons d’identifiants par défaut afin de tenter de s’y connecter et d’en prendre le contrôle. Or, il cible dorénavant les dispositifs de stockage en réseau (NAS) de Zyxel en exploitant la CVE critique récemment publiée « CVE-2020-9054 » permettant de réaliser de l’exécution de code à distance sur la version 5.21 du micrologiciel.

Le coronavirus : le leurre le plus utilisé de tous les temps

Durant la crise sanitaire due au COVID-19, le coronavirus devient le leurre le plus utilisé au sein d’innombrables attaques de type phishing. En effet, parmi celle-ci, le Internet Crime Complaint Center (IC3) du FBI indique qu’il peut s’agir de courriels prétendant offrir des informations sur le virus, des kits de test et des potentiels vaccins, ou encore ceux se faisant passer pour des associations caritatives encourageant à faire des dons pour la recherche.

Veille sur les vulnérabilités

CVE-2020-0684 – Vulnérabilité d’exécution de code à distance dans Microsoft Windows

Il existe une vulnérabilité d’exécution de code à distance dans Microsoft Windows lorsqu’un fichier de format .LNK est traité (analysé ou exécuté par exemple). Un attaquant qui exploiterait avec succès cette vulnérabilité pourrait obtenir les mêmes droits que l’utilisateur local.

CVE-2020-3947 – Vulnérabilité de déni de service dans VMware Workstation

Certaines versions de VMware Workstation et Fusion contiennent une vulnérabilité de type « use-after-free » dans le service vmnetdhcp. L’exploitation réussie de la vulnérabilité peut conduire à réaliser un déni de service du service vmnetdhcp s’exécutant sur la machine hôte ou encore exécuter du code sur l’hôte.

CVE-2020-10887 – Vulnérabilité de contournement du pare-feu d’un routeur TP-Link

Une version du micrologiciel du routeur TP-Link Archer est vulnérable à un contournement sur son pare-feu. Cette vulnérabilité découle d’une implémentation insuffisante de filtrage approprié des connexions SSH IPv6, au niveau de la gestion des connexions IPv6. Elle peut être exploitée sans authentification au préalable et permet d’effectuer une escalade de privilège avec la possibilité d’exécuter du code en tant que « root ».

Les indicateurs du mois

Top leak – Fuite d’informations de plus de 5 millions de clients chez Marriott

Les cybercriminels ont réussi à obtenir les identifiants de connexion de deux employés sur un logiciel tiers que les propriétés hôtelières du Marriott utilisent pour fournir des services aux clients. Ainsi, ils ont eu accès à de nombreuses informations sur les clients (noms, prénoms, adresses mails, numéros de téléphone, etc.). C’est la seconde grosse fuite constatée pour Marriott depuis 24 mois !

Top exploit – CVE-2020-0796 – Vulnérabilité d’exécution de code à distance dans le protocole SMB

Il existe une faille dans la manière dont le protocole Microsoft Server Message Block 3.1.1 (SMBv3) traite certaines requêtes, SMB étant un protocole réseau de partage de fichiers, d’imprimantes et d’autres ressources réseau. En effet, sans authentification au préalable, un attaquant exploitant cette vulnérabilité lui permettrait d’exécuter du code à distance non seulement côté serveur mais également côté client.

Top attack – Un des plus grands hôpitaux tchèques neutralisé par une cyberattaque

L’hôpital universitaire de Brno, en République tchèque, a été frappé par une cyberattaque majeure en plein milieu d’une épidémie de COVID-19 forçant l’hôpital à arrêter ses ordinateurs et à neutraliser son réseau informatique. Par conséquent, des interventions chirurgicales urgentes ont dû être reportées et des nouveaux patients en phase aigüe transférés vers d’autres hôpitaux.

Veille sur les versions des logiciels

Cet article Revue de l’actualité par le CERT-W – Mars 2020 est apparu en premier sur RiskInsight.

Veille sur la cybercriminalité

La mise à jour de Google Chrome lutte contre la cybercriminalité

Google Chrome version 80 prend désormais en charge AES-256 pour les données utilisateur stockées localement. Le changement a eu un impact sur la capacité d’AZORult à voler les informations des utilisateurs. AZORult est un malware de profil utilisateur qui est apparu en 2016 en volant de grandes quantités d’informations, y compris les mots de passe, l’historique de navigation Web, les cookies, etc.

Bouygues Construction, victime d’un autre ransomware

Bouygues Construction a été victime d’une attaque de ransomware. Détectée pour la première fois le 30 janvier, la société a annoncé l’attaque sur Twitter quelques jours seulement avant que le groupe MAZE ne se déclare être derrière l’attaque.

Internet Complain Center reporting (FBI IC3 report)

Le Federal Bureau of Investigation (FBI) a publié le Internet Complaint Center (IC3) signalant une augmentation de 1 300 plaintes par jour. Le rapport montre comment le Business email compromise (BEC) a coûté 1,7 milliard de dollars aux entreprises en 2019. Depuis que les entreprises ont mis en œuvre des campagnes de «volume spam», les attaques deviennent plus sophistiquées et ciblent des individus de grande valeur tels que les PDG et les employés de la finance.

Veille sur les vulnérabilités

CVE-2020-0688 – Vulnérabilité d’exécution de code à distance dans Microsoft Exchange

Il existe une vulnérabilité d’exécution de code à distance dans Microsoft Exchange lorsque le logiciel ne parvient pas à gérer correctement les objets en mémoire («Vulnérabilité de corruption de mémoire dans Microsoft Exchange»).

CVE-2019-15126 – Clé de chiffrement nulle pour chiffrer une partie de la communication de l’utilisateur

Un problème a été découvert sur les appareils clients Wi-Fi Broadcom. Plus précisément, un trafic chronométré et artisanal peut provoquer des erreurs internes (liées aux transitions d’état) dans un appareil WLAN qui conduisent à un chiffrement Wi-Fi de couche 2 inapproprié avec une possibilité conséquente de divulgation d’informations par voie aérienne pour un ensemble discret de trafic.

CVE-2020-0022 – Vulnérabilité Bluetooth critique dans Android

La pile Bluetooth Android permet aux attaquants de diffuser silencieusement des logiciels malveillants et de voler des données sur les téléphones à proximité en connaissant simplement l’adresse MAC Bluetooth de la cible. En conséquence, possibilité de déni de service (DoS), si l’appareil fonctionne sous Android 8.0, 8.1 ou 9.0, puis exécution de code à distance (RCE).

Les indicateurs du mois

Top leak : fuite de 123 millions d’enregistrements chez Decathlon

Une mauvaise configuration de la base de données a permis à une équipe de vpnMentor de révéler 123 millions d’enregistrements comprenant des informations sur les clients et les employés. Une base de données de plus de 9 Go a été trouvée sur un serveur Elasticsearch non sécurisé, exposant des informations provenant de Decathlon – Espagne.

Top exploit: CVE-2020-6418 – Faille de confusion dans V8, Google Chrome

Faille de confusion dans V8 (moteur JavaScript utilisé par Google Chrome) permettant l’exécution de code arbitraire dans le sandbox du navigateur.

Top attack: une cyberattaque paralyse les ventes de laine en Australie

Une attaque de type ransomware a touché plus de 75% de l’industrie de la laine en Australie. Le secrétaire du Comité national de vente aux enchères (NASC) a confirmé la compromission de Talman. Talman est le principal fournisseur de logiciels de l’industrie.

Cet article Revue de l’actualité par le CERT-W – Février 2020 est apparu en premier sur RiskInsight.