Les attaques les plus simples sont souvent les meilleures.
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!
