Surveiller Microsoft 365 avec Wazuh : configuration pas à pas

Dans une PME, Microsoft 365 concentre presque tout : la messagerie, les documents, les comptes et souvent les accès aux applications métier. C'est donc la première cible des attaquants. Une compromission de compte se déroule le plus souvent en silence : connexion avec un mot de passe volé, création d'une règle qui masque les réponses, puis fraude au virement depuis la vraie adresse du dirigeant ou du comptable.

Microsoft enregistre toutes ces actions dans le journal d'audit unifié, mais personne ne le consulte en temps réel. Ce tutoriel explique comment brancher ce journal sur Wazuh, étape par étape, pour recevoir une alerte dès qu'un événement suspect se produit.

Ce que Wazuh peut collecter dans Microsoft 365

Wazuh interroge l'Office 365 Management Activity API, l'interface officielle de Microsoft pour récupérer le journal d'audit. Les événements sont classés en cinq types de contenu, que vous choisissez dans la configuration :

Prérequis

• Un serveur Wazuh fonctionnel (version 4.x) et, idéalement, un agent Wazuh Linux sur lequel exécuter le module. Si vous partez de zéro, voyez d'abord comment ajouter une machine dans Wazuh.
• Un compte administrateur Microsoft 365 capable d'enregistrer une application et d'accorder le consentement administrateur (administrateur général, ou administrateur de rôle privilégié pour le consentement).
• L'audit unifié activé. Il l'est par défaut sur la plupart des tenants, mais vérifiez-le dans le portail Microsoft Purview, rubrique Audit : si un bandeau propose de démarrer l'enregistrement de l'activité, cliquez dessus. Sans cela, l'API ne renvoie rien.
• Un accès sortant HTTPS depuis la machine qui exécute le module vers login.microsoftonline.com et manage.office.com.

Étape 1 : enregistrer une application dans Microsoft Entra ID

Wazuh s'authentifie auprès de Microsoft comme une application, avec un identifiant et un secret. Dans le portail Azure (portal.azure.com) :

• 1. Ouvrez Microsoft Entra ID puis Inscriptions d'applications (App registrations) et cliquez sur Nouvelle inscription.
• 2. Donnez-lui un nom explicite, par exemple wazuh-audit-m365, laissez « Comptes dans cet annuaire organisationnel uniquement » et validez. Aucune URI de redirection n'est nécessaire.
• 3. Dans la page Vue d'ensemble de l'application, notez l'ID d'application (client) et l'ID de l'annuaire (locataire), c'est-à-dire le tenant ID.
• 4. Dans Certificats et secrets, créez un nouveau secret client. Copiez immédiatement sa valeur (pas son ID) : elle ne sera plus jamais affichée.

Étape 2 : accorder les permissions de lecture du journal d'audit

• 1. Dans l'application, ouvrez Autorisations de l'API puis Ajouter une autorisation.
• 2. Choisissez Office 365 Management APIs, puis Autorisations d'application (et non « déléguées »).
• 3. Dans le groupe ActivityFeed, cochez ActivityFeed.Read (activité générale) et ActivityFeed.ReadDlp (événements DLP), puis ajoutez-les.
• 4. Cliquez sur Accorder un consentement d'administrateur pour votre organisation. Tant que la colonne « État » n'affiche pas une coche verte, l'API refusera les requêtes de Wazuh.

Ces deux permissions sont en lecture seule : l'application peut lire le journal d'audit, mais ne peut rien modifier dans votre tenant.

Étape 3 : configurer le module Office 365 dans Wazuh

Le module peut tourner sur le serveur Wazuh ou sur un agent. Wazuh recommande l'agent, pour ne pas alourdir le serveur, et à partir de Wazuh 5.0 seul l'agent est possible. Sur un agent Linux, ajoutez ce bloc à la fin du fichier /var/ossec/etc/ossec.conf :

<ossec_config>
  <office365>
    <enabled>yes</enabled>
    <interval>1m</interval>
    <curl_max_size>1M</curl_max_size>
    <only_future_events>yes</only_future_events>
    <api_auth>
      <tenant_id>VOTRE_TENANT_ID</tenant_id>
      <client_id>VOTRE_CLIENT_ID</client_id>
      <client_secret_path>/var/ossec/etc/m365_secret</client_secret_path>
      <api_type>commercial</api_type>
    </api_auth>
    <subscriptions>
      <subscription>Audit.AzureActiveDirectory</subscription>
      <subscription>Audit.Exchange</subscription>
      <subscription>Audit.SharePoint</subscription>
      <subscription>Audit.General</subscription>
      <subscription>DLP.All</subscription>
    </subscriptions>
  </office365>
</ossec_config>

Plutôt que d'écrire le secret en clair dans ossec.conf, l'option client_secret_path le lit depuis un fichier séparé, que vous protégez ainsi :

echo -n 'VALEUR_DU_SECRET' | sudo tee /var/ossec/etc/m365_secret > /dev/null
sudo chown root:wazuh /var/ossec/etc/m365_secret
sudo chmod 640 /var/ossec/etc/m365_secret
sudo systemctl restart wazuh-agent

Quelques précisions sur les options :

• interval : fréquence d'interrogation de l'API. Le défaut est de 10 minutes ; 1 à 5 minutes est un bon compromis.
• only_future_events : avec yes, seuls les événements postérieurs au démarrage sont collectés. Passez à no si vous voulez récupérer aussi l'historique disponible.
• api_type : commercial pour un abonnement Microsoft 365 classique ; gcc et gcc-high concernent uniquement les clouds gouvernementaux américains.
• curl_max_size : taille maximale d'une réponse de l'API. Sur un tenant très actif, si des lots d'événements sont rejetés, augmentez-la (par exemple 5M).

Si vous préférez exécuter le module sur le serveur Wazuh (version 4.x uniquement), placez le même bloc dans l'ossec.conf du serveur et redémarrez wazuh-manager au lieu de wazuh-agent.

Étape 4 : vérifier que les événements arrivent

Commencez par le journal local de la machine qui exécute le module :

sudo grep -i office365 /var/ossec/logs/ossec.log | tail -20

Des erreurs d'authentification à ce stade viennent presque toujours d'un ID mal copié, de l'ID du secret utilisé à la place de sa valeur, ou d'un consentement administrateur manquant.

Générez ensuite un événement : déconnectez-vous puis reconnectez-vous à Microsoft 365 avec un compte de test. Dans le dashboard Wazuh, ouvrez Cloud security puis Office 365. La connexion doit apparaître dans l'onglet Events, typiquement sous la règle 91545 (événement de connexion Secure Token Service dans Entra ID).

Les règles natives à surveiller en priorité

Wazuh embarque plus de 120 règles dédiées à Microsoft 365 (plage d'ID 91531 à 91725). Voici celles qui méritent votre attention dès le premier jour :

Trois règles personnalisées contre la compromission de messagerie

Les règles natives ne couvrent pas certains signaux typiques de la fraude au président et de la compromission de messagerie (BEC). Ajoutez ces trois règles dans /var/ossec/etc/rules/local_rules.xml sur le serveur Wazuh :

<group name="office365,onyx_m365,">

  <!-- Échec de connexion Entra ID (base de la règle suivante) -->
  <rule id="100500" level="3">
    <if_sid>91532</if_sid>
    <field name="office365.Operation">^UserLoginFailed$</field>
    <description>Office 365 : échec de connexion pour $(office365.UserId)</description>
    <options>no_full_log</options>
  </rule>

  <!-- 1. Force brute : 10 échecs en 5 minutes sur le même compte -->
  <rule id="100501" level="10" frequency="10" timeframe="300">
    <if_matched_sid>100500</if_matched_sid>
    <same_field>office365.UserId</same_field>
    <description>Office 365 : possible attaque par force brute sur $(office365.UserId)</description>
    <mitre><id>T1110</id></mitre>
  </rule>

  <!-- 2. Règle de boîte de réception créée ou modifiée -->
  <rule id="100502" level="10">
    <if_sid>91532</if_sid>
    <field name="office365.Operation">^New-InboxRule$|^Set-InboxRule$|^UpdateInboxRules$</field>
    <description>Office 365 : règle de boîte de réception créée ou modifiée par $(office365.UserId)</description>
    <mitre><id>T1564.008</id></mitre>
  </rule>

  <!-- 3. Transfert automatique configuré sur une boîte -->
  <rule id="100503" level="12">
    <if_sid>91532</if_sid>
    <field name="office365.Operation">^Set-Mailbox$</field>
    <match>ForwardingSmtpAddress|ForwardingAddress|DeliverToMailboxAndForward</match>
    <description>Office 365 : transfert automatique configuré sur une boîte par $(office365.UserId)</description>
    <mitre><id>T1114.003</id></mitre>
  </rule>

</group>

sudo systemctl restart wazuh-manager

• Force brute (100501) : dix échecs de connexion en cinq minutes sur le même compte. Ajustez le seuil à la taille de votre organisation ; un pic d'échecs répartis sur de nombreux comptes trahit plutôt une attaque par pulvérisation de mots de passe (password spraying).
• Règles de boîte de réception (100502) : après avoir pris le contrôle d'une boîte, l'attaquant crée presque toujours une règle qui déplace ou supprime les réponses pour que la victime ne voie rien. Chez une PME, la création d'une règle est rare : chaque alerte mérite un coup d'œil.
• Transfert automatique (100503) : un transfert de tous les mails vers une adresse externe est l'un des signes les plus fiables d'une compromission. Vérifiez l'adresse cible dans le détail de l'alerte.

Dépannage des problèmes les plus fréquents

Questions fréquentes

Faut-il une licence Microsoft 365 particulière pour utiliser ce module ?
Non. Le journal d'audit standard est inclus dans les abonnements Microsoft 365 Business et Entreprise, et l'API de gestion d'activité est accessible sans surcoût. Les licences Premium ou E5 ajoutent des événements plus détaillés et une conservation plus longue, mais ne sont pas nécessaires pour démarrer.

Wazuh remplace-t-il Microsoft Defender ou Microsoft Sentinel ?
Non, il les complète. Defender protège les boîtes et les postes ; Wazuh centralise le journal d'audit Microsoft 365 avec les journaux de vos serveurs, postes et pare-feu, et permet de corréler un événement Microsoft 365 avec ce qui se passe ailleurs sur votre système d'information, sans le coût d'ingestion de Sentinel.

Peut-on surveiller plusieurs tenants Microsoft 365 avec un seul Wazuh ?
Oui. Il suffit d'ajouter un bloc <api_auth> par tenant dans la configuration du module, chacun avec son propre tenant ID, client ID et secret. C'est la configuration que nous utilisons pour superviser plusieurs clients.

Combien de temps faut-il pour voir une alerte après l'événement ?
Le délai dépend surtout de Microsoft, qui publie les événements dans l'API avec un retard de 30 à 90 minutes en général. L'intervalle d'interrogation de Wazuh ajoute au maximum quelques minutes.

Une alerte qui arrive un vendredi soir n'a de valeur que si quelqu'un la traite. Notre service MDR 24/7 s'appuie sur Wazuh et sur ces détections Microsoft 365 pour réagir à une compromission de messagerie avant le virement frauduleux. Pour comprendre les autres modules du dashboard, voyez notre tour d'horizon du tableau de bord Wazuh.