CVE-2026-124194 : Zero-Day de Microsoft Outlook exploité pour voler les hachages NTLM

Microsoft a corrigé CVE-2026-124194, une vulnérabilité zero-day activement exploitée dans Microsoft Outlook qui peut exposer les informations d’authentification NTLMv2 d’un utilisateur lorsqu’un fichier de message spécialement conçu est ouvert. Microsoft classe le problème comme une vulnérabilité de falsification et le qualifie de Modéré avec un score CVSS 3.1 de 6,5.

La vulnérabilité permet à un attaquant distant non authentifié d’envoyer un fichier de message malveillant et de convaincre une victime de l’ouvrir dans une version affectée d’Outlook. Outlook peut ensuite se connecter à un emplacement réseau contrôlé par l’attaquant sans afficher l’avertissement de contenu externe que les utilisateurs attendraient normalement. Pendant cette connexion, Windows peut exposer les informations d’authentification NTLMv2 qui peuvent potentiellement être exploitées pour usurper l’identité de la victime.

Contacter le service commercial

Microsoft a confirmé que CVE-2026-124194 a déjà été exploité lors d’attaques. Cependant, l’entreprise n’a pas divulgué les acteurs de la menace impliqués, l’échelle de la campagne, les organisations victimes, l’infrastructure de livraison, ni si le matériel d’authentification volé a été utilisé pour des mouvements latéraux ultérieurs ou des compromissions de compte.

La faille a été corrigée dans le cadre de la vague de correctifs Patch Tuesday de novembre 2026 de Microsoft, publiée le 10 novembre. Les produits affectés incluent Microsoft 365 Apps for Enterprise, Microsoft Office LTSC 2021 et Microsoft Office LTSC 2024 sur les systèmes 32 bits et x64.

La CISA a ajouté la vulnérabilité à son catalogue de vulnérabilités exploitées connues le 10 novembre, confirmant des preuves d’exploitation active et établissant le 24 novembre 2026 comme date limite de remédiation pour les agences fédérales américaines concernées.

Les équipes de sécurité peuvent utiliser la plateforme d’intelligence de détection native de l’IA de SOC Prime pour opérationnaliser le renseignement sur les menaces, identifier les activités suspectes d’Outlook et NTLM, et accélérer l’ingénierie de détection et la chasse aux menaces dans les environnements SIEM, EDR, XDR et Data Lake.

Détecter CVE-2026-124194 en corrélant l’activité Outlook avec des connexions SMB sortantes inattendues, des tentatives d’authentification NTLM vers des systèmes externes, l’exécution suspecte de fichiers de message et un abus subséquent des identifiants ou de l’identité.

Le contenu de détection peut ne pas être disponible pour chaque CVE. Vérifiez la plateforme SOC Prime pour la couverture actuelle. Si des détections pertinentes ne sont pas encore disponibles, vérifiez à nouveau car de nouveaux renseignements sur les menaces et du contenu de détection sont continuellement ajoutés.

Analyse de CVE-2026-124194

CVE-2026-124194 affecte Microsoft 365 Apps for Enterprise, Microsoft Office LTSC 2021 et Microsoft Office LTSC 2024. Microsoft attribue à la faille un score CVSS 3.1 de 6,5 avec le vecteur AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N, reflétant une accessibilité à distance, une complexité d’attaque faible, aucune autorisation d’attaque requise, une interaction utilisateur nécessaire, et un impact de confidentialité élevé.

La vulnérabilité est classée sous CWE-356, Produit UI Ne Prévenant Pas l’Utilisateur d’Actions Dangereuses. En termes pratiques, Outlook n’affiche pas l’avertissement qui devrait normalement alerter un utilisateur avant que l’application n’accède à un contenu externe potentiellement dangereux.

L’exploitation commence par un fichier de message Outlook spécialement conçu livré à la cible. L’attaquant n’a pas besoin d’un compte sur le système de la victime ou le locataire Microsoft 365, mais la victime doit ouvrir le fichier malveillant. Microsoft précise que le tableau de prévisualisation n’est pas un vecteur d’attaque, ce qui signifie que simplement afficher le message dans l’interface de prévisualisation d’Outlook n’est pas suffisant.

Une fois le fichier ouvert, Outlook peut initier une connexion à un emplacement réseau contrôlé par l’attaquant sans présenter l’avertissement de contenu externe habituel.

C’est significatif car les environnements Windows peuvent automatiquement tenter l’authentification NTLM lors de l’accès à des ressources distantes. L’échange défi-réponse résultant peut exposer le hachage d’authentification NTLMv2 de l’utilisateur au serveur distant.

Un hachage NTLMv2 n’est pas le mot de passe en texte clair de l’utilisateur. Cependant, la possession de matériel d’authentification peut créer plusieurs risques subséquents selon l’environnement et les capacités de l’attaquant. BleepingComputer note que les hachages capturés peuvent être soumis à un craquage de mot de passe hors ligne, tandis que l’avis de Microsoft avertit que les informations d’authentification divulguées peuvent potentiellement être utilisées pour s’authentifier en tant que victime.

Cela rend la vulnérabilité particulièrement pertinente pour les environnements d’entreprise qui reposent encore largement sur NTLM pour les partages de fichiers, les applications héritées, les ressources distantes ou les workflows d’authentification internes.

Le score CVSS de 6,5 peut initialement sembler relativement modeste pour une zero-day sous exploitation active. Le score reflète le fait que l’exploitation nécessite une interaction utilisateur et affecte principalement la confidentialité plutôt que de livrer directement une exécution de code, une perte d’intégrité ou une interruption de service.

Le risque opérationnel est néanmoins considérablement plus élevé car Microsoft a déjà observé des exploitations et la CISA a indépendamment ajouté la faille à KEV. Les équipes de sécurité devraient donc prioriser le statut d’exploitation par rapport au seul CVSS lors de la détermination de l’urgence de la remédiation.

L’enregistrement CVE identifie les versions affectées et corrigées suivantes :

Les installations 32 bits et x64 sont affectées. Les organisations utilisant Microsoft 365 Apps devraient se fonder sur les informations des publications de sécurité Office de Microsoft car les numéros de build diffèrent selon les canaux de maintenance.

Microsoft a publié CVE-2026-124194 le 10 novembre 2026 et publié les mises à jour de sécurité correspondantes via Patch Tuesday. La vulnérabilité n’a pas été rendue publique avant qu’un correctif ne soit disponible.

Microsoft crédite un chercheur utilisant le pseudonyme « nono » et le chercheur en sécurité Benoît Sevens pour avoir découvert ou signalé le problème. SecurityWeek note que la reconnaissance de Microsoft pour Sevens fait référence à l’utilisation du modèle Claude AI d’Anthropic lors de la recherche. Les sources disponibles ne fournissent pas la date exacte de la découverte privée de la vulnérabilité ou de son rapport initial à Microsoft.

Le paysage PoC de CVE-2026-124194 reste moins important que le statut d’exploitation confirmé. Microsoft et les deux rapports fournis ne donnent pas de code d’exploitation public ou d’instructions de reproduction détaillées. Certains agrégateurs d’exploit tiers ont produit des signaux contradictoires concernant le nouveau matériel de preuve de concept publié, donc les défenseurs ne doivent pas se fier à la disponibilité publique de PoC lors de l’évaluation des risques. L’exploitation active a déjà été établie de manière indépendante par Microsoft et la CISA.

Pour la détection de CVE-2026-124194, les défenseurs devraient surveiller l’activité des points d’extrémité et du réseau ensemble. Un signal particulièrement précieux est OUTLOOK.EXE initiant du trafic SMB vers une destination externe ou précédemment inconnue peu de temps après l’ouverture d’un fichier de message Outlook par un utilisateur.

Le trafic sortant sur le port TCP 445 mérite une attention particulière. Microsoft recommande de bloquer le trafic SMB sortant vers Internet comme un contrôle général de défense en profondeur car cela peut empêcher les dispositifs internes d’envoyer des données SMB directement à des hôtes externes.

Les équipes de sécurité peuvent également examiner le journal opérationnel NTLM de Microsoft sous Applications et Journaux des services/Microsoft/Windows/NTLM et auditer l’authentification NTLM sortante. Microsoft fournit une politique spécifiquement conçue pour auditer ou refuser le trafic NTLM sortant vers des serveurs distants.

Les pivots de chasse comportementale utiles incluent :

• Outlook initiant des connexions SMB externes inattendues.
• Tentatives d’authentification NTLM vers des destinations Internet.
• Authentification réussie à des services internes peu après une activité suspecte d’Outlook.
• Activité de fichier de message associée à des connexions réseau externes inhabituelles.
• Tentatives d’authentification répétées impliquant la même identité compromise.
• Nouveaux accès depuis des systèmes ou adresses IP incohérents avec l’activité normale de l’utilisateur.

Les défenseurs devraient éviter de traiter chaque connexion SMB ou NTLM sortante comme preuve d’exploitation. Les deux technologies peuvent encore exister légitimement dans des environnements d’entreprise. Les détections les plus efficaces corréleront l’activité d’Outlook, la réputation de destination, l’interaction utilisateur, la télémétrie NTLM et le comportement d’authentification subséquent.

Microsoft n’a pas publié de composants indicateurs de compromission spécifique à la campagne CVE-2026-124194 tels que des adresses IP malveillantes, des domaines, des hachages de fichiers joints, des adresses d’expéditeurs ou des noms de fichiers associés aux attaques observées. L’identité des attaquants et leur ciblage restent non divulgués.

Cela signifie que les organisations doivent actuellement prioriser la chasse comportementale plutôt que la correspondance statique des indicateurs de compromission (IOC).

Mitigation de CVE-2026-124194

La principale remédiation est d’installer immédiatement les mises à jour de sécurité Office de novembre 2026 de Microsoft.

Les installations Office LTSC 2021 doivent être mises à jour vers la version 16.0.14334.21048 ou ultérieure, tandis que les installations Office LTSC 2024 doivent utiliser la version 16.0.17932.21140 ou ultérieure. Les utilisateurs de Microsoft 365 Apps for Enterprise doivent vérifier que leur canal de maintenance a reçu la version actuelle de sécurité correspondante.

Étant donné que l’exploitation est déjà en cours, les organisations doivent vérifier le déploiement réussi plutôt que de supposer que les mises à jour automatisées d’Office ont atteint chaque appareil.

Les administrateurs doivent prendre les actions suivantes :

1. Inventorier les installations de Microsoft Outlook sur les points d’extrémité gérés.
2. Identifier les systèmes Microsoft 365 Apps, Office LTSC 2021 et Office LTSC 2024 qui n’ont pas reçu la mise à jour de sécurité de novembre.
3. Déployer immédiatement les versions corrigées et vérifier l’installation.
4. Examiner les points d’extrémité qui sont restés vulnérables pendant que l’exploitation était active.
5. Bloquer le trafic SMB sortant non nécessaire vers l’internet.
6. Auditer l’authentification NTLM sortante et réduire l’utilisation de NTLM partout où c’est possible opérationnellement.
7. Enquêter sur une activité inhabituelle d’Outlook vers le réseau et des tentatives d’authentification inattendues.
8. Éduquer les utilisateurs à ne pas ouvrir des fichiers de message ou des pièces jointes Outlook non sollicités d’unersources non fiables.

Bloquer la sortie SMB sur le port TCP 445 fournit une couche de protection additionnelle importante. Microsoft recommande explicitement d’empêcher le trafic SMB de quitter le réseau d’entreprise sauf s’il existe une exigence opérationnelle spécifique pour des services SMB hébergés sur internet.

Les organisations devraient également envisager de restreindre NTLM. Windows fournit la Sécurité réseau : Restreindre NTLM : Trafic NTLM sortant vers des serveurs distants politique, qui peut d’abord être configurée en mode audit pour identifier les dépendances avant que les administrateurs ne commencent à bloquer l’authentification.

Désactiver brusquement NTLM dans une entreprise peut perturber les applications héritées et les workflows. Les organisations devraient donc auditer l’utilisation, identifier les dépendances légitimes, mettre en œuvre les exceptions requises et progressivement déplacer l’authentification vers Kerberos ou d’autres mécanismes plus robustes.

Si une exploitation suspecte est identifiée, simplement installer la mise à jour ne suffit pas à clore l’incident.

Les équipes de sécurité devraient identifier l’identité affectée et examiner l’activité d’authentification se produisant après l’ouverture du fichier de message suspecté. Rechercher les connexions SMB inhabituelles, les logons distants, les mouvements latéraux, l’accès aux partages de fichiers, l’authentification VPN, les connexions cloud et d’autres services qui acceptent les identifiants affectés.

Lorsque des preuves suggèrent que des informations d’authentification ont été exposées ou abusées avec succès, réinitialiser le mot de passe pertinent et révoquer les sessions actives selon les procédures de réponse à l’identité de l’organisation. Les autres identifiants privilégiés accessibles au compte affecté devraient également être examinés.

Les journaux des points d’extrémité, du proxy, du pare-feu, des emails, de l’EDR et de l’identité devraient être conservés avant la remédiation lorsqu’une compromission est suspectée. La corrélation de ces sources peut aider à reconstruire la séquence depuis la livraison du phishing jusqu’à la divulgation de NTLM et une éventuelle authentification subséquente.

La CISA a ajouté la vulnérabilité à KEV le 10 novembre et exige que les agences fédérales concernées la remédient avant le 24 novembre 2026. La CISA énumère l’utilisation dans les campagnes de rançongiciels connues comme inconnue.