Dans cet article, je vous propose une synthèse des bonnes pratiques de sécurité pour Microsoft Exchange Server, directement inspirées des recommandations publiées par la NSA et la CISA.
Ces directives visent à renforcer la résilience des environnements Exchange hébergés en datacenter — qu’ils soient on-premise ou hybrides — face aux menaces actuelles, notamment les compromissions de messageries et l’exploitation de vulnérabilités connues.
L’objectif de ce document est d’offrir une référence claire et opérationnelle pour les administrateurs système, les équipes CERT/SOC, et les responsables de la sécurité souhaitant sécuriser durablement leurs serveurs Exchange.
Résumé exécutif
Les serveurs de messagerie Microsoft Exchange on-premises, souvent ciblés par des attaques avancées, nécessitent une protection renforcée. Un rapport conjoint de la NSA, de la CISA, de l’ASD (Australie) et du Centre pour la cybersécurité du Canada (octobre 2025) expose une série de recommandations techniques pour durcir la sécurité de ces serveurs Exchange. En synthèse, il convient de :
- Maintenir les serveurs Exchange à jour : Appliquer rapidement les mises à jour de sécurité et les mises à niveau (Cumulative Updates), car les attaquants exploitent souvent les vulnérabilités divulguées en quelques jours.
- Migrer les versions obsolètes : Passer à Exchange Server Subscription Edition ou à un autre serveur de messagerie pris en charge dès que possible pour éviter les risques accrus liés aux versions en fin de vie (EOL).
- Activer le service d’atténuation d’urgence : S’assurer que l’Exchange Emergency Mitigation (EM) service est opérationnel afin de déployer automatiquement les mesures de mitigation fournies par Microsoft en cas de vulnérabilité critique.
- Appliquer des configurations de référence sécurisées : Utiliser les référentiels de sécurité (STIG, benchmarks CIS, etc.) pour Exchange, Windows et les clients de messagerie afin de maintenir une posture de configuration cohérente et durcie.
- Exploiter les protections intégrées : Activer les fonctionnalités de sécurité natives (antivirus Microsoft Defender/AMSI, règles de réduction de surface d’attaque, AppLocker/contrôle d’applications, EDR) pour renforcer la défense en profondeur du serveur Exchange
- Authentifier les courriels sortants : Mettre en œuvre les standards SPF, DKIM et DMARC pour empêcher l’usurpation d’identité dans les emails, via des enregistrements DNS appropriés ou des solutions d’authentification tierces.
- Restreindre l’accès administrateur : Limiter l’accès à la console d’administration Exchange (EAC) et à PowerShell distant aux seuls postes de travail administratifs autorisés, en utilisant par exemple des règles de client (Client Access Rules) et des filtrages réseau.
- Renforcer l’authentification et le chiffrement : N’autoriser que des protocoles sécurisés (TLS 1.2+), activer l’Extended Protection contre les attaques de type « adversary-in-the-middle » , privilégier Kerberos à NTLM, et configurer l’authentification moderne (OAuth2/ADFS) avec multi-facteur tout en désactivant l’authentification de base.
- Sécuriser l’environnement PowerShell : Activer la signature des données de configuration PowerShell (Certificate-Based Signing) déployée par Exchange , et désactiver l’accès PowerShell à distance pour les utilisateurs non administrateurs afin de réduire la surface d’attaque.
- Protéger les accès web : Forcer les connexions HTTPS pour Outlook on the Web via HSTS (HTTP Strict Transport Security) et isoler le téléchargement des pièces jointes sur un domaine distinct afin de prévenir des attaques CSRF sur les sessions OWA.
- Adopter un modèle d’accès minimal : Utiliser le contrôle d’accès basé sur les rôles (RBAC) avec séparation des privilèges (« split permissions ») pour qu’aucun compte Exchange compromis ne puisse compromettre le domaine Active Directory dans son ensemble
Activer la détection de falsification d’expéditeur : Conserver le mécanisme de détection de l’en-tête « P2 From » introduit par Exchange (novembre 2024) qui identifie et marque automatiquement les emails usurpant l’affichage de l’expéditeur.
Introduction
La persistance de menaces actives et les vulnérabilités exploitées visant Microsoft Exchange Server on-premises ont incité plusieurs agences gouvernementales à publier des recommandations de sécurité renforcées.
En octobre 2025, la National Security Agency (NSA) américaine, la Cybersecurity and Infrastructure Security Agency (CISA), l’Australian Signals Directorate (via l’ACSC) et le Centre pour la cybersécurité du Canada ont ainsi diffusé conjointement un guide de bonnes pratiques de sécurité pour Microsoft Exchange. Ce guide s’adresse aux équipes administrant Exchange on-premises et détaille des mesures préventives pour protéger ces serveurs critiques contre des acteurs malveillants sophistiqués.
Les recommandations couvrent plusieurs axes fondamentaux : adopter une posture proactive (mises à jour rapides, réduction de la surface d’attaque), appliquer des configurations de référence éprouvées, renforcer l’authentification et le chiffrement des communications, restreindre strictement les accès administratifs, et améliorer la confiance dans les emails échangés.
La mise en œuvre rigoureuse de ces mesures vise à significativement réduire les risques de compromission des serveurs Exchange on-premises.
Maintenir un rythme de mises à jour régulier
La première mesure de défense consiste à maintenir à jour tous les serveurs Exchange avec la dernière version supportée et le dernier correctif cumulatif (Cumulative Update, CU) disponible. Microsoft publie en moyenne deux CUs par an pour Exchange, ainsi que des mises à jour de sécurité mensuelles. Il est crucial d’appliquer ces correctifs dès que possible : les acteurs malveillants développent et exploitent fréquemment des codes d’attaque quelques jours seulement après la divulgation d’une vulnérabilité corrigée. Un retard ou un défaut de patching accroît le risque d’intrusion au fil du temps, en laissant le système exposé à des failles connues.
Les administrateurs peuvent s’appuyer sur des outils fournis par Microsoft tels que l’Exchange Update Wizard, le script Health Checker ou SetupAssist pour vérifier l’état des mises à jour et faciliter la mise à niveau continue des serveurs Exchange.
Par ailleurs, Microsoft communique chaque nouvelle mise à jour (ainsi que d’éventuelles mesures de mitigation provisoires en cas de vulnérabilité critique) via le blog de l’équipe Exchange et la documentation officielle, il convient de surveiller ces annonces afin de déployer rapidement les correctifs disponibles.
Migrer les serveurs Exchange en fin de vie
Microsoft a mis fin au support des anciennes versions d’Exchange le 14 octobre 2025, faisant d’Exchange Server Subscription Edition (SE) l’unique version on-premises désormais prise en charge. Exploiter une version non supportée (EOL) d’Exchange entraîne un risque important, car aucune mise à jour de sécurité n’est fournie pour corriger les failles découvertes.
Il est donc impératif de remplacer ou migrer tout serveur Exchange arrivé en fin de vie vers Exchange SE ou vers une solution de messagerie alternative toujours supportée.
Si, par nécessité opérationnelle, un serveur EOL doit encore fonctionner temporairement, son exposition doit être réduite au maximum. En pratique, il convient de ne pas l’exposer directement à Internet, de l’isoler sur un segment réseau dédié et de limiter son usage aux communications internes strictement nécessaires. Si des échanges externes sont indispensables durant cette période transitoire, il est recommandé de les faire transiter par une passerelle de messagerie sécurisée ou un service mail intermédiaire plutôt que de connecter directement le serveur EOL au monde extérieur. (À titre d’exemple, aux États-Unis, une directive fédérale d’urgence – CISA ED 25-02 – impose aux agences civiles de déconnecter tout serveur Exchange EOL de leurs réseaux, illustrant la sévérité du risque encouru.)
Assurer le fonctionnement du service d’atténuation d’urgence
Microsoft fournit un service d’atténuation d’urgence Exchange (Exchange Emergency Mitigation service, EM) visant à appliquer automatiquement des mesures de défense temporaires en cas de vulnérabilité critique, entre deux publications de correctifs. Ce service, installé par défaut sur les serveurs Exchange Mailbox depuis les CUs de septembre 2021, communique avec le service cloud Office Config de Microsoft pour recevoir les instructions de mitigation à déployer
Le service EM peut ainsi implémenter rapidement des protections approuvées par Microsoft, par exemple en ajoutant des règles de réécriture URL dans IIS pour bloquer certains schémas d’attaque connus, ou en désactivant des fonctionnalités Exchange vulnérables le temps qu’un correctif soit disponible.
Ces actions de mitigation sont consignées dans le journal d’événements Windows ainsi que dans un journal dédié au sein du répertoire Exchange, pour visibilité et audit. Il est crucial de s’assurer que le service EM reste activé et opérationnel sur tous les serveurs Exchange, de sorte qu’en cas de vulnérabilité 0-day, les contre-mesures fournies par Microsoft puissent être appliquées sans délai pour réduire le risque d’exploitation.
À noter : les mitigations d’urgence déployées par ce service sont des mesures temporaires et ne remplacent pas l’installation des correctifs officiels dès leur disponibilité. Le service EM offre un filet de sécurité immédiat pour endiguer les attaques en cours sur les serveurs Exchange, mais les mises à jour de sécurité restent la solution pérenne pour corriger les vulnérabilités sous-jacentes.
Appliquer des référentiels de configuration sécurisée
Pour maintenir une posture de sécurité cohérente à l’échelle de l’infrastructure, il est recommandé d’adopter des configurations de sécurité standardisées (security baselines) pour les serveurs Exchange, leur système d’exploitation, et même les clients de messagerie. Un référentiel de configuration sécurisé fournit un gabarit ou un guide des réglages à appliquer pour durcir un système selon les bonnes pratiques. En définissant de tels baselines pour Exchange et Windows, les administrateurs peuvent plus aisément détecter toute dérive ou non-conformité dans la configuration d’un serveur et corriger rapidement les failles potentielles.
Plusieurs organismes publient des guides de configuration sécuritaire pour Exchange Server et son écosystème :
| Provider | Security Baseline Guide |
|--------------------------|----------------------------------------------------------|
| DISA (U.S. DoD) | Exchange Server Security Technical Implementation Guide (STIG) |
| DISA | Microsoft Office System 2016 STIG |
| DISA | Microsoft Office 365 ProPlus STIG |
| CIS (Center for Internet Security) | Exchange Server CIS Benchmark |
| CIS | Microsoft Office CIS Benchmark |
| Microsoft | Security baseline for Microsoft 365 Apps for Enterprise (Office) |
En appliquant et en maintenant à jour de tels référentiels de configuration, l’organisation se dote d’un socle éprouvé pour réduire la surface d’attaque et assurer une sécurité constante. Toute configuration d’un serveur qui s’écarterait de la baseline définie pourra être rapidement identifiée et remédiée, renforçant ainsi la résilience globale du système Exchange.
Activer les protections de sécurité intégrées
La sécurisation d’Exchange doit s’inscrire dans une défense en profondeur couvrant l’ensemble des composants du serveur. Il est recommandé d’activer les fonctionnalités de sécurité natives disponibles sur le serveur Exchange et sur Windows, surtout si aucune solution tierce équivalente n’est en place. Parmi les mécanismes clés à utiliser :
- Antivirus Microsoft Defender : Assurez-vous qu’un antivirus en temps réel protège le serveur Exchange. L’antivirus Microsoft Defender (MDAV) intégré à Windows est supporté par Exchange et peut être configuré en suivant la liste d’exclusions recommandées par Microsoft afin d’éviter d’éventuels impacts sur les performances Exchange. L’antivirus détectera les malwares ciblant le serveur et ses processus.
- Intégration AMSI : Exchange Server s’interface avec l’Antimalware Scan Interface (AMSI) de Windows, permettant à l’antivirus d’analyser le contenu des requêtes HTTP reçues par Exchange (par exemple les pièces jointes envoyées via OWA). Cette capacité offre une couche de détection supplémentaire pour bloquer des contenus malveillants transmis via le service web d’Exchange.
- Attack Surface Reduction (ASR) : Microsoft Defender comprend des règles de réduction de surface d’attaque bloquant des techniques d’intrusion courantes. Il est vivement conseillé d’activer la règle ASR « Block webshell creation for Servers » sur les serveurs Exchange : elle empêchera la création de webshells malveillants sur le serveur en cas de compromission (une méthode d’attaque fréquemment observée sur Exchange).
- Contrôle d’applications : Mettez en œuvre une stratégie de whitelist d’applications sur le serveur Exchange à l’aide d’AppLocker ou de Windows Defender Application Control. Cela garantit que seuls les programmes et scripts explicitement autorisés peuvent s’exécuter sur le serveur, bloquant proactivement l’exécution de code malveillant ou non approuvé.
- Endpoint Detection & Response (EDR) : Déployez une solution EDR sur le serveur Exchange pour bénéficier de capacités avancées de détection des menaces et de visibilité. Un EDR pourra identifier des comportements d’attaque sophistiqués (même si ceux-ci n’ont pas été bloqués par l’antivirus) et fournir des alertes ainsi que des données forensic utiles en cas d’incident.
- Antispam/antimalware Exchange : Exploitez les agents anti-spam et anti-malware intégrés à Exchange Server en les activant et en les configurant correctement, afin de filtrer les emails indésirables ou malveillants au niveau du serveur de transport. Cela réduit l’exposition des utilisateurs aux courriels de phishing ou vérolés.
En tirant parti de ces protections natives et en les ajustant au besoin, on renforce significativement la posture de sécurité du serveur Exchange dans le cadre d’une stratégie globale de défense. Il convient toutefois de noter qu’Exchange on-promises n’intègre pas en standard certains mécanismes de sécurité des emails – en particulier les standards DMARC, DKIM et SPF. L’implémentation de ces derniers requiert des mesures additionnelles décrites dans la section suivante.
Renforcer l’authenticité des courriels : SPF, DKIM et DMARC
Pour lutter contre les usurpations d’identité par email, il est indispensable de mettre en place les standards SPF, DKIM et DMARC au niveau des domaines de messagerie de l’organisation. Ces mécanismes permettent de vérifier qu’un courriel provient bien du domaine affiché et n’a pas été altéré.
Or, Exchange Server on-promises ne prend pas en charge nativement ces standards , d’où la nécessité de solutions complémentaires :
- SPF (Sender Policy Framework) : Publiez un enregistrement SPF dans le DNS de chaque domaine d’envoi de mails. L’enregistrement SPF liste les serveurs de messagerie autorisés à émettre du courrier pour le domaine. Les serveurs récepteurs consultent cette liste afin d’identifier et rejeter (ou signaler) les emails dont l’IP d’origine ne correspond pas aux serveurs autorisés, empêchant ainsi l’envoi sous une fausse identité de domaine.
- DKIM (DomainKeys Identified Mail) : Mettez en place la signature cryptographique des emails sortants. DKIM appose une signature numérique dans l’en-tête du message, permettant au serveur destinataire de vérifier via la clé publique (publiée dans le DNS) que le courriel n’a pas été modifié et qu’il provient bien du domaine revendiqué. Votre Exchange on-promise ne pouvant pas signer les emails en DKIM de lui-même, il faudra soit installer un agent tiers sur le serveur Exchange pour effectuer cette signature, soit faire transiter les mails sortants par une passerelle capable de les signer.
- DMARC (Domain-based Message Authentication, Reporting and Conformance) : Publiez une politique DMARC dans le DNS du domaine. DMARC s’appuie sur SPF et DKIM pour fournir aux destinataires des consignes sur le traitement des emails échouant aux vérifications (par exemple, rejeter ou mettre en quarantaine si SPF/DKIM invalides) et pour envoyer des rapports agrégés au domaine émetteur. En configurant DMARC, vous indiquez comment gérer les messages non authentiques prétendant provenir de votre domaine et vous recevez des rapports vous permettant de surveiller et comprendre les tentatives d’usurpation.
Dans un environnement Exchange on-promises (Dans vos DataCenters), l’organisation peut implémenter ces contrôles de plusieurs manières : en configurant manuellement les enregistrements DNS SPF et DMARC du domaine (selon sa configuration d’envoi), en déployant sur Exchange un outil ou script additionnel pour la signature DKIM des mails sortants, et/ou en utilisant un service de messagerie tiers (cloud ou passerelle dédiée) qui se chargera de vérifier SPF/DKIM à la réception et de signer les messages à l’envoi. L’adoption de SPF, DKIM et DMARC renforce grandement la confiance dans les courriels de l’organisation en rendant très difficile l’envoi d’emails de phishing usurpant vos domaines.
La sécurité de l’administration d’Exchange
La compromission d’un serveur Exchange est d’autant plus grave si l’attaquant peut exploiter ses interfaces d’administration. Deux mesures complémentaires permettent de sécuriser l’administration d’Exchange : restreindre l’accès aux consoles d’administration aux seules machines autorisées, et imposer une stricte séparation des privilèges via le modèle RBAC.
Restriction des accès administratifs (EAC et PowerShell)
Seuls des postes de travail d’administration dédiés devraient pouvoir accéder aux interfaces d’administration d’Exchange : le centre d’administration web EAC (Exchange Admin Center) et l’interface PowerShell à distance.
Étant donné que l’EAC est hébergé sur le serveur Exchange lui-même (aux côtés d’OWA), on utilisera des Client Access Rules au niveau d’Exchange pour bloquer l’accès à l’EAC depuis toute machine non autorisée. En parallèle, il est conseillé de filtrer au niveau du pare-feu (Windows Firewall ou ACL réseau) le trafic vers l’URL de l’EAC et l’endpoint PowerShell du serveur Exchange, de sorte qu’uniquement les adresses IP des stations d’administration légitimes puissent s’y connecter. Ainsi, même si un attaquant s’infiltre dans le réseau, il ne pourra pas facilement interagir avec les interfaces de gestion d’Exchange.
RBAC et séparation des privilèges (split permissions)
Exchange Server implémente un modèle RBAC (Role-Based Access Control) qui permet d’attribuer aux comptes administrateurs des rôles aux périmètres bien définis. Il est recommandé de tirer parti de RBAC pour appliquer le principe de moindre privilège : chaque compte admin Exchange ne doit disposer que des droits nécessaires à ses tâches. En particulier, il convient d’activer la configuration de séparation des privilèges (split permissions) qu’Exchange permet Celle-ci dissocie l’administration d’Exchange de l’administration Active Directory : les administrateurs Exchange gèrent l’organisation Exchange (boîtes aux lettres, bases de données, connecteurs, etc.) sans droits d’administration AD, et inversement les administrateurs du domaine AD n’ont pas de privilèges sur Exchange. Historiquement, les déploiements utilisaient souvent un même compte Domain Admin pour l’AD et pour Exchange, si bien que compromettre un serveur Exchange ouvrait la voie à une compromission complète du domaine Windows.
En déléguant distinctement les privilèges (AD vs Exchange), un compte admin Exchange compromis ne donne plus à l’attaquant un accès direct à l’annuaire Active Directory de l’entreprise. Il est donc crucial de réviser les attributions de rôles Exchange, de retirer les droits excessifs et d’appliquer le modèle de split permissions suivant les bonnes pratiques Microsoft.
Renforcer les mécanismes d’authentification
L’authentification des utilisateurs et des services Exchange doit être renforcée pour limiter les risques d’usurpation de session et de compromission de comptes. Deux axes complémentaires sont mis en avant : l’activation d’Extended Protection (protection étendue) pour contrer les attaques par relai, et la transition vers des méthodes d’authentification modernes avec facteurs multiples pour les clients.
Extended Protection et réduction de NTLM
La fonctionnalité Extended Protection (EP), lorsqu’elle est activée sur Exchange, apporte une défense supplémentaire contre les attaques de type adversary-in-the-middle (AitM) et les tentatives de relay de connexion. Elle lie l’authentification de l’utilisateur à la session TLS établie (via un Channel Binding Token unique) de sorte qu’une connexion compromise ne puisse être réutilisée par un attaquant sur une autre session En pratique, si un acteur malveillant vole les informations d’authentification d’une session et tente de les rejouer sur une nouvelle connexion, la vérification EP détectera un jeton de session incompatible et bloquera la tentative.
Tous les serveurs Exchange devraient avoir Extended Protection activé pour bénéficier de cette couche de défense.
EP nécessite une configuration cohérente sur l’ensemble de l’environnement : seuls les protocoles TLS modernes (TLS 1. 2 ou supérieur) doivent être autorisés, et les anciens protocoles d’authentification Windows NTLM faibles doivent être désactivés.
En pratique, NTLMv1 et SMBv1 sont déjà obsolètes et neutralisés sur les versions récentes de Windows Server ; l’objectif est de n’autoriser que NTLMv2 au strict minimum, voire idéalement de l’éliminer totalement à terme.
Extended Protection est activé par défaut pour les nouvelles installations d’Exchange Server 2019 à partir du CU14, ainsi que sur Exchange SE.
Dans les environnements existants, il convient d’utiliser des outils comme le Health Checker pour s’assurer que toutes les prérequis sont remplis (versions à jour, configurations TLS homogènes, etc. ) puis d’activer EP manuellement sur chaque serveur Exchange.
En parallèle, les organisations doivent préparer la suppression progressive de NTLM de leur infrastructure. NTLM est depuis longtemps ciblé par les attaquants (pass-the-hash, relai, etc.), il est donc souhaitable de réduire puis d’éteindre son usage au profit de Kerberos.
Pour cela, activez l’audit NTLM sur les contrôleurs de domaine afin d’identifier où ce protocole est encore utilisé. Analysez les équipements et applications (par ex. clients Outlook, solutions tierces) qui y recourent et mettez-les à jour pour qu’ils supportent des méthodes modernes (ex : configurer Outlook en MAPI sur HTTP pour utiliser Kerberos plutôt que RPC/NTLM).
Les évolutions de Windows 11 visent d’ailleurs à diminuer les dépendances à NTLM, et Microsoft a annoncé qu’Exchange SE (dès son CU1) remplacerait NTLMv2 par Kerberos comme protocole par défaut pour les communications entre serveurs Exchange. À terme, l’objectif est de pouvoir désactiver NTLM dans l’Active Directory sans impacter le service de messagerie, éliminant ainsi un vecteur d’attaque couramment exploité.
Authentification moderne et MFA
Il est fortement préconisé d’abandonner l’authentification basique (transmission directe du login/mot de passe) au profit de l’authentification moderne pour l’accès aux boîtes aux lettres Exchange.
L’authentification moderne utilise des jetons OAuth 2.0 émis par un fournisseur d’identité (comme Azure AD ou un service ADFS interne) et permet la mise en place de l’authentification multifacteur (MFA) pour les utilisateurs Exchange Server 2019 (depuis le CU13) et Exchange SE supportent ce mode d’authentification basé sur OAuth 2.0/OpenID Connect. Dans un environnement hybride, on peut déployer le Hybrid Modern Authentication afin que même les boîtes aux lettres on-promises s’authentifient via Azure AD (Microsoft Entra ID) avec prise en charge du MFA.
Une fois ce mode configuré et testé, il convient de désactiver tous les protocoles d’authentification basique sur le serveur Exchange (POP/IMAP/SMTP Auth en clair, MAPI RPC legacy, etc. ). La bascule vers l’OAuth2 élimine l’envoi du mot de passe en clair ou réutilisable : désormais, l’accès à une boîte mail n’est accordé que sur présentation d’un jeton d’accès valide pour l’utilisateur, délivré par l’IdP après vérification de ses identifiants et éventuellement d’un second facteur. Ce jeton a une durée de vie limitée et est spécifique à la ressource demandée, ce qui réduit drastiquement la surface d’attaque par rapport à un mot de passe statique.
En résumé, l’authentification moderne avec MFA renforce la sécurité des accès à Exchange en rendant beaucoup plus difficile l’exploitation de comptes utilisateur (un attaquant devrait compromettre le second facteur ou voler un jeton éphémère). Son déploiement s’inscrit pleinement dans une stratégie Zero Trust qui exige une vérification stricte de l’identité avant toute autorisation d’accès.
Sécuriser l’administration PowerShell
Exchange étant principalement administré via PowerShell à distance (Exchange Management Shell), il est important de sécuriser ce canal contre tout détournement. Lorsqu’une session PowerShell distante est établie, les objets et données sont sérialisés (convertis en flux de bytes) pour être échangés entre le client et le serveur, cette opération qui fut ciblée par des attaques avancées.
Pour contrer ces menaces, Microsoft a introduit la signature des données PowerShell par certificat sur Exchange. Depuis la mise à jour de sécurité de novembre 2023, les serveurs Exchange signent par défaut les données sérialisées échangées lors des sessions PowerShell à l’aide du certificat d’authentification Exchange.
Cette mesure garantit l’intégrité des commandes PowerShell à distance : si un attaquant tente d’injecter ou modifier les données en transit, la signature numérique ne correspondra plus et la modification sera détectée/refusée. Les administrateurs doivent vérifier que cette fonctionnalité est bien active sur l’ensemble des serveurs Exchange et que ceux-ci utilisent le même certificat Exchange d’authentification pour signer les données, afin de se faire mutuellement confiance. En pratique, sur les serveurs à jour, cela est le comportement par défaut, mais il convient de s’en assurer lors de la mise en place.
En parallèle, il est recommandé de désactiver l’accès PowerShell distant pour les comptes non administratifs qui n’en ont pas besoin. Par défaut, tout utilisateur authentifié peut potentiellement ouvrir une session PowerShell sur Exchange ; en restreignant cette capacité aux seuls administrateurs Exchange, on évite qu’un compte utilisateur compromis puisse servir de point d’appui à une attaque (via l’exécution de cmdlets malveillantes sur le serveur).
Sécuriser les accès web (OWA/EAC)
Les services web d’Exchange – Outlook on the Web (OWA) pour les utilisateurs et la console EAC pour les admins doivent être protégés contre l’interception et le détournement de session. Il est tout d’abord conseillé d’activer HTTP Strict Transport Security (HSTS) sur le serveur Exchange. HSTS permet d’imposer l’utilisation de HTTPS aux clients web.
Concrètement, lorsqu’un utilisateur accède une première fois à OWA/EAC en HTTPS, le serveur envoie une en-tête Strict-Transport-Security au navigateur, l’informant que le site doit être contacté en HTTPS uniquement pour une durée déterminée (par ex. 6 mois).
Le navigateur appliquera dès lors automatiquement ce passage en HTTPS : même si l’utilisateur saisit “http://” ou qu’un attaquant tente de rediriger vers du HTTP, le navigateur convertira en HTTPS, empêchant toute connexion non chiffrée vers OWA.
En activant HSTS selon les préconisations de Microsoft (par exemple « inclure les sous-domaines, durée suffisamment longue »), on supprime la possibilité d’une attaque de type « downgrade » ou d’écoute du trafic web en clair vers Exchange.
De même, toutes les communications SMTP impliquant Exchange devraient être chiffrées et authentifiées autant que possible. On veillera à activer TLS sur les connecteurs d’envoi/réception SMTP d’Exchange et, si le contexte le permet, à exiger TLS pour les échanges avec les serveurs de messagerie partenaires (via les connecteurs). Exchange on-premises ne supportant pas en natif les protocoles comme DANE (DNS Authentication of Named Entities) ou MTA-STS (SMTP Strict Transport Security), l’organisation peut envisager de les implémenter en périphérie, par exemple en publiant un enregistrement DNS TLSA (pour DANE) ou une politique MTA-STS via son DNS et en utilisant un relais SMTP tiers compatible L’objectif est d’atteindre un niveau de sécurité des emails en transit similaire à celui offert sur Office 365 : authentification du serveur destinataire et chiffrement systématique des liaisons SMTP, empêchant les attaques de type man-in-the-middle sur les emails.
Une autre bonne pratique spécifique à OWA consiste à configurer un domaine dédié pour les téléchargements de fichiers (OWA Download Domain). Cette fonctionnalité fait servir les pièces jointes ouvertes via OWA à partir d’un sous-domaine différent de celui d’OWA. Par exemple, si OWA est accessible sur mail. entreprise. fr, le téléchargement des pièces jointes pourra être redirigé vers download. entreprise. fr. Le navigateur, en traitant ce dernier comme un site distinct, n’enverra pas le cookie d’authentification OWA avec la requête de téléchargement. Ainsi, si un attaquant tente d’exploiter une vulnérabilité CSRF (Cross-Site Request Forgery) via le mécanisme de téléchargement (en forçant le navigateur de la victime à appeler une URL OWA avec son cookie), la séparation de domaine empêchera l’exploitation car le cookie de session n’est pas transmis. Configurer un download domain pour OWA permet donc de renforcer l’isolement des sessions web, ajoutant une protection contre certaines attaques web complexes visant Exchange.
Détection d’usurpation de l’expéditeur (P2 From)
Les attaquants utilisent fréquemment des astuces d’usurpation d’adresse pour faire passer leurs emails pour ceux d’expéditeurs de confiance. Outre DMARC, une nouveauté intégrée à Exchange vise à détecter ces falsifications de l’en-tête expéditeur (dite P2 From). Il s’agit des cas où le champ From: affiché peut ne pas correspondre à l’expéditeur réel (le champ d’enveloppe). À partir de la mise à jour de novembre 2024, Exchange Server détecte automatiquement ce type de fraude : s’il identifie qu’un email entrant présente une anomalie dans l’en-tête From (par ex. un nom de domaine simulé), il va ajouter un avertissement visuel de phishing dans le message et insérer une entête spéciale X-MS-Exchange-P2FromRegexMatch dans le courriel.
Cette fonctionnalité est activée par défaut et il est recommandé de ne pas la désactiver. Au contraire, les administrateurs peuvent tirer parti de cet indicateur dans leurs règles de transport : par exemple, détecter l’en-tête ajouté et marquer automatiquement le message (ajout d’un préfixe “[suspect]” à l’objet) ou le rediriger en quarantaine, afin d’automatiser la gestion des courriels d’apparence frauduleuse. Ce mécanisme renforce la sécurité anti-phishing d’Exchange en signalant immédiatement les messages dont l’expéditeur affiché pourrait être falsifié, et en permettant de prendre des mesures pour protéger les utilisateurs finaux.
La conclusion
Ces bonnes pratiques pour sécuriser Exchange Server s’inscrivent dans les principes d’un modèle Zéro Trust plus large. Zéro Trust part du postulat que des menaces existent aussi bien à l’intérieur qu’à l’extérieur du périmètre réseau traditionnel ; il ne suffit plus de protéger la frontière, il faut renforcer chaque composant critique. Dans cette optique, les mesures présentées (mises à jour proactives, authentification renforcée, chiffrement systématique, moindres privilèges, réduction de surface d’attaque, etc. ) visent toutes à élever le niveau de sécurité des serveurs Exchange face à des adversaires motivés.
Sécuriser Exchange on-promises est indispensable pour préserver l’intégrité et la confidentialité des communications de l’entreprise comme les échanges d’emails, de calendriers, de contacts – qui transitent par ce système névralgique. En suivant les recommandations décrites dans ce rapport officiel et en adoptant une posture défensive robuste, les organisations peuvent réduire significativement les risques de cyberattaques affectant leur messagerie. Il est enfin crucial de garder à l’esprit que la sécurité est un processus continu : il convient de maintenir une vigilance active, de surveiller les signes éventuels de compromission, d’adapter les configurations aux nouvelles menaces et de planifier des plans de réponse/détection en cas d’incident. Cette amélioration constante garantira que le serveur Exchange – élément central du fonctionnement de nombreuses organisations demeure correctement protégé face à l’évolution des menaces.
Enjoy et on n’oublie pas « On ne réfléchit pas, On patch ! ™
Références :
NSA ; CISA ; ASD ; Centre pour la cybersécurité du Canada (2025). Microsoft Exchange Server Security Best Practices. Fiche d’information en cybersécurité conjointe, octobre 2025.
Liens:
https://www.cisa.gov/resources-tools/resources/microsoft-exchange-server-security-best-practices
https://thehackernews.com/2025/10/cisa-and-nsa-issue-urgent-guidance-to.html
