Ce qui s’est passé
Le 10 novembre 2026, Microsoft a publié son lot mensuel de correctifs de sécurité (le « Patch Tuesday »). Selon le décompte rapporté, ce lot corrige 1 259 failles. C’est un volume exceptionnel. Il faut donc trier, car on ne peut pas tout traiter avec la même urgence.
Les faits importants à retenir :
- Une faille d’Outlook est déjà exploitée par des attaquants. Selon Microsoft, elle peut exposer des hachages NTLMv2. NTLM est un ancien protocole d’authentification de Windows. Un hachage est une empreinte chiffrée du mot de passe. Un attaquant qui la récupère peut tenter de la casser hors ligne pour retrouver le mot de passe, ou la réutiliser pour se faire passer pour l’utilisateur auprès d’autres serveurs (attaque par relais).
- Des règles de détection sont disponibles. Cisco Talos a publié des règles Snort (signatures pour les systèmes de détection d’intrusion) qui couvrent plusieurs failles de ce mois.
- Des installations échouent. Microsoft a confirmé que la mise à jour de sécurité Windows KB5132061 peut échouer avec les codes d’erreur
0x80070306,0x800f0989et0x800f0993. - Les mises à jour récentes ont déjà causé des régressions (une fonction qui marchait cesse de marcher après un correctif). Microsoft a corrigé des problèmes d’audio USB causés par les mises à jour de sécurité de septembre. L’éditeur a aussi corrigé des échecs de connexion à Exchange causés par les mises à jour Windows Server d’octobre.
Pourquoi ça compte pour une PME
Ce mois-ci, la PME est prise entre deux risques. Si elle tarde à installer les correctifs, elle reste exposée à une faille déjà exploitée. Si elle installe tout d’un coup sans test, elle risque de bloquer la messagerie, des postes ou des équipements.
Le risque Outlook / NTLMv2 : élevé
- Outlook est présent sur presque tous les postes. La surface d’attaque est donc très large.
- Le vecteur est le courriel, la porte d’entrée la plus utilisée contre les PME.
- Un hachage volé peut ouvrir d’autres portes. S’il appartient à un compte administrateur, ou si le mot de passe est faible, l’attaquant peut se déplacer dans le réseau. C’est souvent une étape avant un rançongiciel (logiciel qui chiffre vos fichiers pour exiger une rançon).
Le risque opérationnel : réel
- Avec des installations qui échouent (KB5132061), des postes peuvent rester non corrigés sans que personne ne s’en aperçoive.
- Les régressions récentes (Exchange, audio USB) montrent qu’un correctif peut couper un service essentiel. Pour une PME qui héberge son propre serveur Exchange, une panne de connexion signifie souvent une journée sans courriel.
| Élément | Niveau de risque | Qui est concerné |
|---|---|---|
| Faille Outlook exploitée (NTLMv2) | Élevé – exploitation active | Tous les postes avec Outlook |
| Failles critiques sur des services exposés à Internet | Élevé | Serveurs accessibles de l’extérieur (Exchange sur site, RDP, VPN, serveurs web) |
| Échecs d’installation KB5132061 | Moyen – risque de faux sentiment de sécurité | Postes et serveurs Windows visés par cette mise à jour |
| Régressions après mise à jour | Moyen – risque d’interruption de service | Exchange sur site, périphériques audio USB, applications métier |
Comment se protéger
Priorité 1 – Corriger la faille Outlook exploitée (sous 72 heures)
- Ouvrez un changement urgent (cadre ITIL : changement d’urgence, approuvé rapidement par la personne responsable des TI).
- Déployez en priorité les mises à jour Office/Outlook de novembre sur tous les postes, en commençant par les comptes à privilèges : direction, finances, administrateurs TI.
- Vérifiez la version d’Outlook installée dans votre console de gestion (Intune, WSUS, outil de votre infogérant). Ne vous fiez pas seulement au statut « déployé ».
Priorité 2 – Bloquer les fuites de hachages NTLM vers Internet
Cette mesure réduit le risque même si un poste n’est pas encore corrigé.
- Au pare-feu périmétrique (celui qui sépare votre réseau d’Internet) : bloquez le trafic sortant SMB (port TCP 445) vers Internet. Ne bloquez pas ce port à l’interne, car vos partages de fichiers l’utilisent.
- Par stratégie de groupe (GPO) : passez d’abord la règle « Sécurité réseau : Restreindre NTLM : trafic NTLM sortant vers des serveurs distants » en mode Audit. Analysez les journaux, puis passez au blocage avec des exceptions pour les serveurs légitimes.
- Ajoutez les comptes administrateurs au groupe Protected Users d’Active Directory. Ce groupe empêche ces comptes d’utiliser NTLM. Testez avant de généraliser.
# Équivalent registre de la GPO (1 = audit, 2 = blocage). Commencer par l'audit.
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" /v RestrictSendingNTLMTraffic /t REG_DWORD /d 1 /f
# Consulter les authentifications NTLM sortantes auditées (événement 8001)
Get-WinEvent -LogName "Microsoft-Windows-NTLM/Operational" |
Where-Object Id -eq 8001 | Select-Object TimeCreated, Message -First 20
Priorité 3 – Détecter
- Si vous disposez d’un IDS/IPS (système de détection/prévention d’intrusion) basé sur Snort, mettez à jour ses règles : Cisco Talos a publié des signatures pour ce Patch Tuesday.
- Surveillez dans les journaux du pare-feu les connexions SMB sortantes vers Internet. Sur un poste de travail, elles sont presque toujours anormales.
- Toute alerte doit ouvrir un incident (gestion des incidents ITIL). Si un vol de hachage est suspecté, réinitialisez le mot de passe du compte concerné.
Priorité 4 – Corriger les failles critiques exposées à Internet (sous 7 jours)
- Dressez la liste de vos services accessibles depuis l’extérieur : Exchange sur site, passerelle RDP, VPN, serveurs web.
- Appliquez sur ces systèmes les correctifs classés « critiques » de novembre. Le reste du lot suit le cycle normal de la gestion des vulnérabilités, sous 30 jours.
Priorité 5 – Déployer par vagues pour ne rien casser
| Vague | Périmètre | Délai indicatif |
|---|---|---|
| Pilote | 5 à 10 % des postes, profils variés (TI, comptabilité, postes avec périphériques USB audio), un serveur non critique | Jour 0 à 2 |
| Vague 1 | Reste des postes de travail | Jour 3 à 5 |
| Vague 2 | Serveurs, Exchange en dernier, avec sauvegarde vérifiée avant l’installation | Jour 5 à 10, en fenêtre de maintenance |
Exception : le correctif Outlook exploité suit un calendrier accéléré. Un pilote de 24 heures suffit.
Priorité 6 – Prévoir la procédure en cas d’échec ou de régression
- Repérer les échecs KB5132061 : recherchez les codes
0x80070306,0x800f0989et0x800f0993dans les rapports de déploiement. Suivez le tableau de bord d’état de Windows (Windows release health), où Microsoft publie ses solutions de contournement. - Vérifiez la présence réelle du correctif sur chaque machine :
Get-HotFix -Id KB5132061 -ErrorAction SilentlyContinue
- Sur un poste en échec, avant une nouvelle tentative, réparez l’image système :
DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow
- Régression (connexion Exchange impossible, audio muet, application métier en panne) : ouvrez un incident, suspendez la vague suivante et vérifiez si Microsoft a déjà publié un correctif. C’est ce qui s’est produit pour les problèmes Exchange et audio USB des derniers mois. Ne désinstallez un correctif de sécurité qu’en dernier recours, de manière documentée et temporaire.
- Désignez à l’avance qui alerter : la personne responsable des TI ou votre infogérant, puis la direction si un service essentiel est touché plus de quelques heures.
En résumé
- Corrigez d’abord ce qui est exploité, ensuite ce qui est exposé à Internet, puis tout le reste.
- Bloquez le NTLM sortant vers Internet.
- Déployez par vagues et vérifiez que chaque correctif est réellement installé.
- Gardez une procédure prête pour les échecs d’installation et les régressions.
