Vue normale

Reçu aujourd’hui — 11 février 2026

Certificats Secure Boot - 15 ans plus tard, Microsoft change enfin les clés

Par :Korben
11 février 2026 à 09:12

Quinze ans que les mêmes certificats Secure Boot tournent sur tous les PC Windows de la planète. Et Microsoft n'en avait jamais changé les clés depuis 2011. Alors là on est donc sur un moment historique puisque c'est la première rotation de l'histoire. Autant dire que ça va piquer un peu pour ceux qui n'ont pas fait leurs mises à jour.

Ces certificats UEFI, ce sont eux qui vérifient que votre machine démarre bien avec un système d'exploitation légitime et pas un malware planqué dans le firmware.

Microsoft a donc commencé à déployer de nouveaux certificats via Windows Update, avec sa mise à jour KB5074109 de janvier. Si vous êtes sous Windows 11, normalement c'est transparent, ça va se faire tout seul en arrière-plan. Les constructeurs comme Dell, HP et Lenovo ont également bossé de leur côté pour mettre à jour le firmware de leurs machines.

Après le hic, c'est la deadline qui est pour fin juin 2026. C'est à cette date que les anciens certificats expirent. Et là, les machines qui n'auront pas reçu les nouveaux vont se retrouver dans ce que Microsoft appelle un "état de sécurité dégradé". En gros, le démarrage sécurisé continuera de fonctionner, mais avec des clés périmées...

Pour ceux qui ont acheté un PC en 2024 ou après, pas de panique, les nouveaux certificats "Windows UEFI CA 2023" sont déjà intégrés dans le firmware. Mais si vous avez une machine plus ancienne, là faudra aller dans Paramètres > Windows Update et vérifier manuellement que tout est bien passé.

Et pour les amateurs de bootkits en tout genre , bonne nouvelle... la base de données DBX (celle qui blackliste les signatures compromises) est aussi mise à jour dans la foulée.

Mais attention, si vous êtes encore sous Windows 10, c'est là que ça se corse. En effet, Microsoft ne fournira les nouveaux certificats qu'aux utilisateurs qui ont souscrit le programme ESU (Extended Security Updates)... qui est payant. Du coup, tous les PC sous Windows 10 sans ESU vont rester avec les vieilles clés.

Je sens que vous êtes content ^^.

Pour vérifier votre situation, ouvrez donc PowerShell en admin et tapez Confirm-SecureBootUEFI. Si ça renvoie "True", c'est bon. Si ça renvoie "False" ou que ça ne marche pas, c'est que votre BIOS n'a peut-être jamais activé le Secure Boot. Ensuite, vérifiez dans Windows Update que la KB5074109 est bien installée. Après sur du matériel d'entreprise, votre admin sys a probablement déjà géré le truc (enfin j'espère).

Si KB5074109 est bien passée vous pouvez dormir tranquille.

Enfin... jusqu'à la prochaine faille. Niark niark !

Source

Reçu avant avant-hier

Pourquoi votre vieux serveur Windows est une bombe à retardement, et comment la désamorcer

Par :Korben
16 janvier 2026 à 05:52

Les amis, si vous administrez encore des serveurs Windows avec des configurations "d'époque" (qui sentent la naphtaline quoi...), il faut qu'on parle.

Google Cloud (via son équipe Mandiant) vient de sortir un papier assez creepy sur Net-NTLMv1, ce vieux protocole d'authentification qu'on croyait enterré mais qui survit encore dans pas mal d'infrastructures. Verdict implacable : c'est une véritable bombe à retardement !!

BOOM 💥 !

En gros, si vous avez encore du NTLMv1 activé quelque part sur votre réseau, un attaquant positionné sur votre réseau peut récupérer le matériel cryptographique nécessaire pour casser vos comptes. Le problème avec Net-NTLMv1, c'est qu'il s'agit d'un protocole d'authentification challenge-response qui date des années 90. C'était l'époque de Windows NT, de 2Pac et des modems 56k sauf que contrairement à la musique, la sécurité a un peu évolué depuis.

Le souci, c'est que ce protocole utilise l'algorithme DES (Data Encryption Standard) pour chiffrer ses challenges. Et le DES, aujourd'hui, c'est aussi solide qu'une porte en papier mâché.

Concrètement, un attaquant peut donc forcer un échange d'authentification (via des outils comme Responder) et, grâce à des Rainbow Tables (des tables arc-en-ciel), retrouver la clé de chiffrement. Une fois qu'il a cette clé, il peut reconstruire le hash NTLM et s'authentifier sur vos serveurs comme s'il était vous (attaque Pass-the-Hash).

Maintenant, la nouveauté qui va vous faire mal, c'est que Mandiant vient de publier un jeu complet de Rainbow Tables spécifiquement pour ça. Avant, il fallait les générer soi-même ou fouiller sur des sites communautaires comme FreeRainbowTables.com .

Le concept des RainbowTables c'est que plutôt que de recalculer les hashs à chaque fois, on pré-calcule des milliards de combinaisons possibles et on les stocke. Et Mandiant explique qu'avec ce dataset et du matériel grand public (moins de 600 $ de GPU), on peut désormais casser des clés NTLM en moins de 12 heures.

Soit une demi-journée pour transformer votre serveur "sécurisé" en moulin à vent... Alors comment savoir si vous êtes concerné ? Hé bien c'est là que ça devient sauvage car même si vous pensez être en NTLMv2 (la version plus sécurisée), il suffit qu'un seul équipement mal configuré, genre une vieille imprimante réseau ou un vieux logiciel force le "downgrade" vers NTLMv1 pour exposer des identifiants.

Heureusement, Windows permet d'auditer ça !

Vous pouvez aller fouiller dans les journaux d'événements (Event Viewer) et chercher l'ID 4624. Si vous voyez "Authentication Package: NTLM" et "Package Name (NTLM only): NTLM V1", c'est que vous avez un gros problème.

Pour le guide de survie, pas de panique, on peut désamorcer le truc mais il va falloir être méthodique pour ne pas casser la prod (ce qui vous ferait passer pour un admin en carton, et on veut éviter ça).

  1. Auditez d'abord : Activez les logs d'audit pour le NTLM. Ça se passe dans les GPO (Group Policy Object). Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> Network security: Restrict NTLM: Audit NTLM authentication in this domain
  2. Identifiez les coupables : Repérez les machines qui utilisent encore la v1. Souvent, ce sont de vieux serveurs 2003 qui traînent, des NAS non mis à jour ou des applis métier codées avec les pieds il y a 15 ans.
  3. Forcez le NTLMv2 : Une fois que vous avez tout nettoyé, modifiez la GPO : Network security: LAN Manager authentication level. Passez-la à "Send NTLMv2 response only. Refuse LM & NTLM".

C'est radical, mais c'est une étape indispensable pour assainir votre réseau.

Voilà si je vous en parle c'est pas pour vous faire paniquer mais ne laissez pas traîner ça. Comme d'hab, la sécurité, c'est souvent de la maintenance de l'existant, et virer ces vieux protocoles tout nuls est probablement l'action la plus rentable que vous puissiez faire cette semaine pour la sécurité de votre boite.

Et si vous cherchez d'autres moyens de sécuriser vos accès, jetez un œil à ce que j'écrivais sur les failles critiques NTLM y'a un peu plus d'un an, ça reste d'actualité.

Source

❌