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.

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

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

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

Introduction aux App Registrations

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

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

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

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

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

Se connecter en tant qu’une App Registration

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

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

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

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

Les droits d’une App Registration

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

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

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

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

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

Compromission d’App Registrations en opération Red Team

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Gestion et supervision des secrets

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

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

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

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

Réduire la surface d’exposition

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

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

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

Dans ce deuxième article, nous analyserons des scénarios d’attaque pratiques qui menacent le Control Plane, et fournirons des recommandations concrètes pour atténuer ces risques. Plus précisément, nous explorerons trois scénarios d’attaque courants qui menacent significativement le Control Plane : la compromission du support IT, du poste de travail de l’administrateur du Control Plane et du CI/CD. En comprenant ces vecteurs d’attaque et en mettant en œuvre des mesures de sécurité robustes, il est possible d’améliorer considérablement la résilience de son environnement cloud contre les compromissions potentielles. 

La compromission du support IT  

Prenons un scénario où le compte d’un membre du support IT est compromis. Cela peut découler d’une attaque par hameçonnage, d’une opération d’ingénierie sociale ou même d’une tentative d’usurpation d’identité. Ces comptes peuvent souvent réinitialiser des mots de passe, y compris ceux des utilisateurs ayant des privilèges très élevés, tels que l’administrateur d’application ou le Owner Azure au niveau root, obtenant ainsi un accès non autorisé à des ressources critiques, allant de l’Entra ID au cloud, en passant par les environnements sur site et les services SaaS. 

Ce type d’attaque illustre un point crucial que nous avons abordé dans le premier article : la nécessité de délimiter et d’isoler efficacement le Control Plane. Le service d’assistance, bien qu’essentiel pour les opérations quotidiennes, doit être rigoureusement séparé des fonctions administratives à haut privilège. L’absence d’une telle séparation peut permettre à un attaquant de passer d’un compte de service d’assistance compromis à un rôle d’administrateur global. 

Pour réduire ce risque, les organisations doivent mettre en œuvre une série de défenses stratégiques :  

• Dans un premier temps, isoler les comptes du Control Plane de ceux gérés par le support IT est essentiel. De cette façon, même si un compte du service d’assistance est compromis, il ne pourra pas accéder ou manipuler des comptes à haut privilège. Ainsi, la compromission d’un compte de service d’assistance ne permettrait pas d’accéder à des comptes à privilèges élevés ou de les manipuler. 
• Dans un second temps, utiliser exclusivement des comptes cloud dédiés aux tâches du Control Plane réduit la probabilité d’exploitation des systèmes hérités comme point d’entrée.  
• Finalement, associer ces comptes à une authentification multi-facteurs (MFA) résistante au phishing, à une administration Just-In-Time (JIT), à une gouvernance d’identité robuste et à des politiques d’accès conditionnel, ainsi qu’à une conformité stricte des postes de travail, crée une défense en couches qui diminue considérablement le risque d’une telle attaque. 

Ce scénario souligne l’importance de considérer chaque compte comme un vecteur de menace potentiel. Mettre en place une isolation stricte et des contrôles rigoureux permet de garantir la sécurité de votre Control Plane en cas de compromission d’un compte de niveau inférieur. 

Compromission d’un poste administrateur du Control Plane  

Considérons maintenant une situation où un attaquant parvient à compromettre le compte administrateur de l’Intune Mobile Device Manager (MDM). Avec cet accès, l’attaquant obtient le contrôle du portail d’administration d’Intune, lui permettant de manipuler le poste de travail d’un administrateur du Control Plane. Il peut déployer des configurations malveillantes, installer des portes dérobées ou se connecter directement à l’ordinateur de l’administrateur (Remote help. Cet accès transforme le poste de l’administrateur en un outil puissant pour une exploitation ultérieure, offrant à l’attaquant la capacité d’exécuter des commandes, d’exfiltrer des données sensibles et de manipuler des ressources cloud sans recourir à des techniques de piratage supplémentaires. 

Ce scénario nous rappelle un principe clé du premier article : la sécurité du cloud doit être abordée de manière holistique. Il ne s’agit pas seulement de sécuriser les identités, mais aussi de garantir que les appareils utilisés pour accéder au Control Plane sont sécurisés. Dans ce cas, le poste de l’administrateur du Control Plane devient un atout critique qui, s’il est compromis, pourrait compromettre les défenses cloud les plus sophistiquées. 

Compromission du CI/CD 

Les environnements Cloud reposant fortement sur l’automatisation, les pipelines CI/CD pour la gestion de l’infrastructure deviennent des cibles privilégiées pour les attaquants. Imaginons un scénario où un attaquant parvient à accéder au compte d’un ingénieur DevOps par le biais d’une attaque de phishing ou d’un vol d’identifiants. Avec cet accès, il introduit un changement malveillant d’Infrastructure as Code (IaC) dans un dépôt Git, sachant que cela déclenchera un pipeline Azure automatisé. Le pipeline valide, planifie et déploie l’infrastructure sur Azure, entraînant la destruction ou l’altération de ressources clés d’Azure, c’est-à-dire les fondations de la Landing Zone. De plus, l’attaquant modifie la configuration YAML du pipeline Azure. Ce faisant, il provoque la fuite d’un secret Service Principal dans les journaux ou la console de débogage, qui est ensuite utilisé pour effectuer des appels non autorisés à l’API Graph. En exploitant cette identité sur-privilégiée, l’attaquant peut escalader ses privilèges, compromettant ainsi les identités Entra ID ou les comptes Office 365. 

Les runners jouent également un rôle crucial dans le pipeline CI/CD. Ces agents sont responsables de l’exécution des tâches dans le pipeline et peuvent être hébergés et maintenus par le fournisseur cloud ou sur site. Comme pour tout serveur, leur compromission peut être utilisée comme point de pivot pour rebondir vers la Landing Zone (par exemple : vol de token) ou d’autres services associés. 

Ce scénario illustre l’interconnexion de la sécurité du cloud. Le pipeline CI/CD, souvent perçu comme une fonction de back-office, est en réalité profondément intégré au Control Plane. Sa compromission peut entraîner des conséquences dévastatrices et généralisées pour les fondations mêmes de vos opérations cloud. 

Pour se protéger contre une telle menace, il est crucial d’isoler le pipeline du Control Plane, dont le but est de construire la Landing Zone, des pipelines de projet. Ensuite, il convient d’appliquer le principe du moindre privilège, en veillant à ce que les comptes et les runners au sein du pipeline n’aient que les permissions nécessaires pour accomplir leurs tâches. Par exemple, pour limiter les permissions des runners, nous pouvons utiliser l’identité fédérée et demander des token OpenID Connect (OIDC), qui fournissent un accès limité et temporaire aux services cloud comme Azure. De plus, l’adoption de pratiques de sécurité automatisées telles que Configuration as Code (CaC) ou Policy as Code (PaC) peut aider à réduire les erreurs humaines et à garantir une sécurité cohérente dans vos déploiements. 

En matière de sécurité cloud, chaque processus et chaque outil doit être considéré sous l’angle du risque. Le pipeline CI/CD ne fait pas exception. En sécurisant ce composant critique, vous protégez non seulement votre Control Plane, mais vous assurez également la stabilité et la sécurité de l’ensemble de votre infrastructure cloud. Cette approche holistique de la sécurité du cloud est ce qui permettra finalement à vos opérations de fonctionner correctement, même face à des attaques sophistiquées. 

Synthèse

Dans cet article, nous avons examiné trois scénarios d’attaque qui menacent la sécurité du Control Plane dans les environnements cloud : la compromission du support IT, la compromission du poste de travail de l’administrateur du Control Plane et la compromission du pipeline CI/CD. 

Chacun de ces scénarios met en évidence l’importance d’une approche de sécurité à plusieurs niveaux, incluant des mesures techniques et organisationnelles. Nous proposons une stratégie en quatre étapes pour concevoir votre Control Plane et le sécuriser contre les attaques potentielles : 

• Étape 1 : Définir ce qui est systémique pour votre infrastructure : identifier les composants et comptes critiques au sein de votre Control Plane qui, s’ils sont compromis, pourraient entraîner une perturbation globale. 
• Étape 2 : Evaluer votre risque actuel avec un audit de sécurité : réaliser des audits de sécurité réguliers pour évaluer l’état actuel de la sécurité de votre Control Plane. Cela vous aidera à identifier les vulnérabilités et à prioriser les efforts de remédiation. 
• Étape 3 : Définir une feuille de route pour isoler et sécuriser les actifs les plus à risque : sur la base des résultats de votre audit, élaborer une feuille de route claire pour sécuriser les actifs les plus critiques. Cela devrait inclure des échéanciers, l’allocation des ressources et des actions spécifiques pour atténuer les risques identifiés. 
• Étape 4 : Se préparer aux scénarios de suppression du cloud : envisager les pires scénarios où des sections entières de votre infrastructure cloud pourraient être compromises ou désactivées. Élaborer des plans de contingence et s’assurer que les processus de sauvegarde et de reprise après sinistre sont en place. 

En suivant ces recommandations, vous pouvez construire une défense robuste contre les menaces potentielles à votre Control Plane, garantissant que votre environnement cloud reste sécurisé et résilient. 

Merci à Louis CLAVERO pour sa contribution à cet article.

Cet article Enterprise Access Model (2/2) : Quelles solutions pour sécuriser un Control Plane ?  est apparu en premier sur RiskInsight.