Je vais vous raconter la meilleure de la semaine… Microsoft vient quand même de passer 5 ans à gueuler sur tous les toits que
BinaryFormatter
est dangereux (ça servait à sérialiser/desérialiser des objets en binaire ave .NET) et qu’il faut arrêter de l’utiliser… et pourtant, on vient d’apprendre qu’ils continuent secrètement de l’utiliser dans WSUS (Windows Server Update Services), leur système censé sécuriser les mises à jour Windows.
Et bien sûr, ce qui devait arriver, arriva… Une magnifique faille critique dans WSUS vient d’être rendue publique, ce qui met en danger environ 500 000 serveurs WSUS actuellement accessibles via le net.
L’histoire commence en réalité en 2020. A cette date, Microsoft déclare officiellement que BinaryFormatter est dangereux, ce qui ne les empêche pas de se faire poutrer Exchange, Azure DevOps, SharePoint en 2021/2021 justement à cause de ça. Du coup, en 2023, ils annoncent le bannissement total de BinaryFormatter en interne. En 2024, ils effectuent même une mise au rebus complète de .NET 9.
Mais c’était sans compter sur cette jolie CVE-2025-59287 d’octobre 2025 qui exploite à son tour BinaryFormatter dans WSUS !
Un oubli ? Pas si sûr, car Microsoft l’utilisait toujours pour déchiffrer les cookies d’authentification de WSUS, rendant ainsi ce système de mises à jour censé protéger Windows vulnérable. La faille, c’est donc une désérialisation non sécurisée. Un attaquant non authentifié envoie une requête SOAP craftée au endpoint GetCookie de WSUS, avec un cookie AuthorizationCookie contenant un payload malveillant. Et de son côté le serveur déchiffre ce truc avec AES-128-CBC, puis passe le résultat directement à BinaryFormatter pour désérialisation.
Et là, bim bam boum, une magnifique exécution de code arbitraire avec privilèges SYSTEM !
Techniquement, la vulnérabilité touche donc les Windows Server 2012 à 2025 qui ont le rôle WSUS activé. Le score CVSS de cette faille est quand même de 9,8 sur 10 ce qui est fait une faille super critique.
L’exploitation de cette faille débute le 24 octobre soit juste après la publication du patch d’urgence de Microsoft sortie la veille c’est à dire le 23 octobre, pour corriger lui-même un autre patch publié juste avant le 8 octobre. Bref un vrai bordel et il faut croire que les attaquants ont attendu la sortie de ce patch d’urgence pour comprendre comment fonctionnait la faille (
l’exploit est ici
).
De son côté, Google Threat Intelligence traque l’acteur cybercriminel UNC6512 qui a ciblé plusieurs organisations et les chiffres font pas plaisir puisque ce sont environ 100 000 tentatives d’exploitation en 7 jours qui ont eu lieues, et 500 000 serveurs WSUS exposés sur le net sur les ports par défaut (8530 HTTP, 8531 HTTPS).
Microsoft a dû sentir la douille arriver puisqu’ils ont déprécié WSUS en septembre de l’année dernière au profit d’autres solutions comme Intune ou WUfb, soit un an avant la sortie de la CVE. Mais bien sûr, comme l’outil reste dans Windows Server 2025 avec ses 10 ans de support réglementaire, des centaines de milliers d’entreprises l’utilisent encore…
Le chaos était garanti ! Maintenant vous me connaissez, je n’aime pas vous laisser sans solution, alors pour les admins sys qui lisent ça, sachez qu’il existe un script PowerShell baptisé
Find-WSUS
qui permet de détecter tous les serveurs WSUS configurés dans vos GPO. C’est pratique pour faire l’inventaire et vérifier que tout est patché. Et notez aussi que le patch d’urgence c’est le KB5070883. Et si vous ne pouvez pas patcher immédiatement parce que la vie est injuste, désactivez quand même le rôle WSUS de vos Windows Server, ou bloquez les ports 8530/8531 directement dans votre firewall.
Le vrai problème en fait, c’est que WSUS n’est qu’un symptôme car une grosse partie du code en entreprise est constitué de dette technique. C’est à dire du code “mort” qui continue de tourner car personne n’ose y toucher. Brrr… ça fait peur c’et sûr ! Surtout que même Microsoft n’arrive pas à tuer sa propre création 5 ans après l’annonce de sa mort officielle, donc autant dire qu’on a tous un sérieux problème.
Note liminaire : Depuis le temps que je n’avais pas pondu un article sur ce blog, je suis très heureux de faire paraître enfin celui-ci. Un grand merci à tous ceux qui continuent à s’abonner et à visiter le site malgré le fait que je publie moins que les années passées, du fait de mes différents projets pro (et perso).
Rappel : L’article qui va suivre contient des techniques et méthodes qui peuvent s’avérer être illégales et dangereuses si elles sont utilisées à mauvais escient. Ce tutoriel ne doit en aucun cas être utilisé contre un particulier, une entreprise, une organisation à but non lucratif ou une administration publique de quelconque pays. Je me dédouane de toute responsabilité en cas de problèmes ou d’incidents de quelque nature que ce soit après le visionnage de cet article.
I. Introduction
Le rôle WDS (Windows Deployment Services) est une fonctionnalité clé de l’écosystème Windows Server, encore largement utilisée par de nombreuses entreprises pour déployer des systèmes d’exploitation sur des postes de travail ou des serveurs. Bien qu’il ne rivalise pas avec des solutions plus complètes (payante) comme MECM, ex SCCM, il reste très répandu, notamment car il peut s’interfacer avec MDT*. Il permet de simplifier, d’automatiser et de suivre les déploiements. Cependant, mal configuré ou insuffisamment protégé, le rôle WDS peut constituer une porte d’entrée pour un attaquant, qui pourrait s’en servir pour progresser au sein du réseau.
* MDT (Microsoft Deployment Toolkit) est un outil gratuit proposé par Microsoft, qui permet de créer des séquences de tâches personnalisées pour automatiser les déploiements de systèmes d’exploitation. Il vient enrichir WDS avec de nombreuses fonctionnalités sans surcoût.
Cet article examine donc la sécurité du rôle WDS en explorant les principales menaces auxquelles il est confronté, ainsi que des recommandations pour renforcer sa sécurité.
Avant toute chose, voici un petit récap afin d’éviter de vous mélanger entre les différents termes et acronymes qui vont être abordés tout au long de l’article.
II. Rappels : WDS vs MDT vs MECM ?
WDS est principalement utilisé pour déployer des « images systèmes » / master à travers un réseau local. Il est simple à configurer mais reste limité, car il se concentre uniquement sur l’installation d’images. MDT, en revanche, va plus loin en permettant l’automatisation et la personnalisation des images elles-mêmes grâce à des séquences de tâches (installation de logiciels, scripts, etc.), mais il demande une configuration plus complexe. Si vous souhaitez en savoir plus sur le fonctionnement de MDT et WDS, je vous recommande cet article.
Pour mettre en place un lab complet et tester les points abordés ci-dessous, voici une collection d’articles issus de (l’excellent) site it-connect !
Processus détaillés du déploiement d’un OS via « PXE » avec WDS et MDT – source
Méconnu dans le monde de la sécurité offensive imho, les serveurs de déploiement sont pourtant une source d’informations importante pour un attaquant (légitime ou non). Ci-dessous, je vous présente les différentes approches pour que vous soyez en mesure de détecter un service WDS sur le réseau lors de votre audit (uniquement :))
III. D’un point de vu attaquant, qu’est-ce qu’on peut faire ?
A. Comment détecter un service WDS sur le réseau ?
Il y a plusieurs manières d’identifier si un service WDS fonctionne sur le réseau.
Sans identifiant : Essayer de booter sur le réseau avec un PC ou une VM « bridgé » sur la carte réseau utilisé. (Ceci est valable uniquement si le réseau n’est pas ou mal segmenté.)
Avec des identifiants du domaine Active Directory valides : Consulter le partage réseau SMB associé au rôle WDS en recherchant le nom du partage réseau ou sa description « générique » (Ils ne sont pas customizable !) :
Nom du partage réseau : REMINST
Description du partage réseau SMB : Windows Deployment Services Share
B. Sans identifiant valide – « Press F12 for loot »
Rappel du prérequis : Évoluer dans un réseau d’entreprise sans/peu de cloisonnement (ce qui existe encore ^) ou être dans un VLAN d’administration où il est possible d’atteindre le serveur de déploiement PXE.
1. Préparer votre machine
Assurez-vous que le poste physique ou la machine virtuelle (VM) est configuré pour être connecté au réseau local en question.
Pour un poste physique, cela implique une connexion via un câble Ethernet branché sur le réseau cible.
Pour une VM, configurez la carte réseau en mode « bridged » (ponté), ce qui permet à la VM d’accéder au réseau comme si elle était un appareil physique sur le réseau local.
2. Accéder au « boot PXE* »
Redémarrez votre poste ou initialisez la machine virtuelle.
Pendant la phase de démarrage, appuyez sur la touche pour « démarrer en mode PXE » (La touche varie selon les fabricants de matériel, mais F12 est une des plus courantes pour initier un déploiement PXE.)
Pour rappel, le PXE* (Preboot Execution Environment) est un protocole processus de démarrage réseau qui permet à un ordinateur de démarrer et « charger » un OS au travers du réseau, sans support de stockage local comme un disque dur ou une clé USB. Lors d’un démarrage PXE, la machine utilise mon microsologiciel (BIOS, EFI, UEFI**) pour réaliser cette tâche.
*PXE n’est pas un protocole à proprement parler, mais plutôt un ensemble de spécifications qui permet à un ordinateur de démarrer (boot) via le réseau.
Concrètement, PXE « chapotes » les deux protocoles réseaux :
DHCP : pour obtenir une adresse IP et localiser le serveur de déploiement.
TFTP : pour télécharger les fichiers nécessaires au démarrage. (fichier au format .wim)
Plus bas, deux schémas vous permettent de visualiser plus en détail comment cela fonctionne.
Et oui, je sais, encore une note… ^^, mais je trouve important de détailler la différence entre les trois termes suivants, car leur distinction est souvent méconnue, elle aussi.
**BIOS, EFI, UEFI: Ce sont trois types de firmware (en français : micrologiciel) utilisés pour démarrer un ordinateur et « charger » un système d’exploitation.
BIOS : ancien (1980-2010) et limité, fonctionne en mode 16 bits avec une interface textuelle simple. Il ne prend en charge que des disques jusqu’à 2 To via le schéma MBR, ce qui limite la capacité de stockage et les fonctionnalités modernes.
EFI : apparu vers 2002 pour moderniser le BIOS, introduit un mode 32 ou 64 bits, des interfaces graphiques plus évoluées, ainsi que le support du partitionnement GPT, permettant de dépasser la limite des 2 To et d’améliorer la gestion des disques.
UEFI : standardisé vers 2005 comme successeur de l’EFI, apporte des fonctionnalités avancées telles que le Secure Boot pour renforcer la sécurité au démarrage, une meilleure modularité et une compatibilité étendue avec les systèmes d’exploitation modernes. C’est désormais la norme sur la majorité des machines actuelles.
Une fois dans le menu de démarrage, sélectionnez l’option correspondante au démarrage réseau, généralement intitulée « Network Boot », « PXE Boot ».
Cette action déclenche une requête au serveur DHCP du réseau pour obtenir une adresse IP ainsi que les informations nécessaires pour localiser le serveur de déploiement.
WDS permet de diffuser sur le réseau deux types d’images essentiels au déploiement d’un système Windows :
Une image de démarrage boot.wim, basée sur WinPE (Windows Preinstallation Environment), qui fournit un environnement (OS) minimal pour initier le processus de déploiement.
Une image d’installation install.wim, contenant l’ensemble des fichiers nécessaires à l’installation du système d’exploitation.
WinPE permet d’effectuer des tâches initiales comme :
L’établissement de la connexion réseau pour accéder dans un second temps à l’image install.wim.
La détection des périphériques et des disques et le chargement des pilotes nécessaires.
Une fois l’image de démarrage correctement chargée, vous arrivez sur l’interface WinPE. Il est alors possible d’ouvrir une invite de commande en appuyant sur la touche F8. Pourquoi est-ce utile ? Cela permet d’explorer les fichiers contenus dans boot.wim « à chaud ».
En explorant les fichiers de ce « mini » système d’exploitation, on remarque la présence d’un dossier nommé Deploy (ou d’un nom équivalent) à la racine du système de fichiers. Ce dossier contient principalement des éléments de configuration, notamment des fichiers qui permettent de personnaliser le futur système d’exploitation en fonction des règles définies dans le master de déploiement.
Un des fichiers de configuration utilisés par MDT est le fameux Bootstrap.ini. Ce fichier joue un rôle crucial dans le démarrage du processus de déploiement. Il contient des paramètres de configuration qui permettent de définir les éléments nécessaires pour établir la connexion initiale entre le client et le serveur de déploiement.
On y trouve très souvent des identifiants de connexion : un compte du domaine Active Directory permettant d’auto-enrôler l’ordinateur au sein de l’AD. C’est cette information qui va fortement intéresser un attaquant, car ce compte est malheureusement encore trop souvent un compte à fort privilège (et même parfois administrateur du domaine… SANS COMMENTAIRE).
more Boostrap.ini
En examinant ce fichier de configuration utilisé par MDT, on constate qu’il peut contenir un compte Active Directory ainsi qu’un mot de passe en clair. Ces informations sont intégrées afin d’automatiser le processus de déploiement et l’enrôlement des machines dans l’Active Directory. Toutefois, cette méthode implique de stocker des identifiants sensibles en clair dans un fichier accessible à toute machine capable de démarrer sur l’image de déploiement, qu’elle soit légitime ou non. À ce jour, il n’existe aucune solution officielle permettant de chiffrer ces identifiants dans le cadre de MDT, ce qui en fait un point de faiblesse connu, mais encore souvent ignoré. (source)
Note : La variable DomainAdmin dans MDT peut prêter à confusion : malgré son nom, elle ne désigne pas nécessairement un administrateur du domaine. Elle doit simplement contenir un compte disposant des droits suffisants pour joindre un poste à Active Directory. Il est donc recommandé d’utiliser un compte dédié avec des privilèges strictement limités à cette tâche. Pourtant, de nombreux tutoriels en ligne préconisent l’usage de comptes à privilèges élevés, voire d’un administrateur du domaine… ce qui accroît considérablement les risques de compromission du domaine ou de mouvements latéraux en cas d’incident.
Pour vérifier la possibilité de connexion et, surtout, si ces identifiants sont encore valides (car ils peuvent avoir été désactivés si le serveur WDS de déploiement n’est plus utilisé), il suffit de tester l’accès via SMB, LDAP ou RDP à l’aide d’un outil comme NetExec.
nxc smb $DC_IP -u 'admin_mdt' -p '@dm1n_mdt'
C. Avec des identifiants valide : Comment trouver le partage réseau utilisé par le rôle WDS
Avec des identifiants valides, il devient possible d’accéder au partage réseau SMB REMINST utilisé par le rôle WDS, et ainsi de récupérer les mêmes fichiers que ceux transmis à une machine lors de la phase de déploiement via l’image boot.wim (WinPE). Ce scénario reste d’autant plus plausible qu’en 2025, même si le cloisonnement réseau tend à se généraliser au sein des entreprises ces dernières années… quoi que
Pour procéder, commencez par énumérer tous les objets ordinateurs Windows enrôlés dans l’Active Directory (cela peut être fait avec BloodHound ou encore avec ldapsearch (un compte utilisateur standard suffit)).
Ensuite, effectuez une recherche rapide (Ctrl + Maj +F pour un terminal standard) dans les résultats à l’aide du terme « REMINST » pour repérer facilement le(s) partage(s) concerné(s). Par exemple, avec l’outil NetExec, la commande suivante permet d’énumérer les partages :
Historiquement, sur les anciennes versions de Windows Server, l’accès au partage REMINST se faisait parfois sans authentification, ce qui facilitait le processus PXE mais exposait potentiellement le serveur à des accès non autorisés. D’un point de vue attaquant, cela permettait de passer d’une approche « black box » à une « gray box ». Depuis Windows Server 2016, les configurations par défaut restreignent ces accès anonymes en exigeant une authentification. Toutefois, si les partages invités ou les « null sessions » sont toujours activés, un attaquant peut encore identifier et accéder au partage sans disposer d’un compte valide dans le domaine. (source)
Cette méthode est très bruyante et risque fortement de déclencher de nombreuses alertes réseau si un système de surveillance est en place (XDR…). Toutefois, elle permet, lors d’un pentest, de vérifier facilement l’existence de ce partage réseau, contrairement à une approche Red Team où la discrétion et la furtivité sont prioritaires.
Une fois que l’on repère un partage nommé REMINST avec la description Windows Deployment Services shares, il convient d’utiliser SMB pour y accéder. Comme vous pouvez le constater, par défaut, l’utilisateur que je possède dispose bien des droits de lecture (READ) sur ce partage.
Pour cela, vous pouver utiliser une machine windows, ou bien passer par un outil en ligne de commande comme smbclient-ng.
Une fois connecté à la racine du partage SMB, il faut indiquer à smbclient-ng (ou smbng) le partage spécifique que l’on souhaite consulter en le sélectionnant explicitement.
use REMINST
Deux cas de figure peuvent se présenter : soit des scripts d’administration comme Bootstrap.ini, CustomSettings.ini ou Unattend.xml sont encore présents ; soit, si les administrateurs réseau ont correctement nettoyé le répertoire, vous ne trouverez rien, ou presque… C’est d’ailleurs une situation que j’ai rencontrée récemment lors d’un audit : aucun de ces scripts n’était encore présent, car les administrateurs les avaient supprimés. En revanche, les images master restaient accessibles, alors même que le service WDS n’était plus utilisé depuis un certain temps — et l’utilisateur référencé dans Bootstrap.ini était encore actif.
Pour vous en assurer, vous pouvez par exemple télécharger l’ensemble du contenu de ce répertoire afin de l’analyser ultérieurement (comme un bourrin ^^). On constate qu’au sein des fichiers récupérés, il est possible d’obtenir une image WinPE nommée LiteTouchPE_x64.wim. Cette image, qui constitue un environnement WinPE, est chargée de mettre en place l’environnement de préexécution destiné à accueillir le futur système.
Comme le format de l’image est un fichier .wim, il est possible de l’explorer à l’aide d’un outil de décompression comme 7-Zip, qui prend en charge ce type de fichier. En effet, un fichier .wim (Windows Imaging Format) est un format développé par Microsoft permettant de stocker une ou plusieurs images de système d’exploitation dans un seul conteneur. Il fonctionne de manière similaire à une archive, ce qui permet d’en parcourir le contenu sans avoir à le monter ni l’exécuter.
Il ne vous reste plus qu’à tester si les identifiants sont bien valides sur le domaine.
nxc smb $DC -u 'admin_mdt' -p '@dm1n_mdt'
Si la réponse est oui, alors il sera très pertinent de vérifier le niveau des droits de cet utilisateur fraîchement « pwned ».
En analysant les droits de l’utilisateur ADMIN_MDT, on constate qu’il est membre de deux groupes, et non des moindres : Remote Management Users et Account Operators. Le premier lui permet d’exécuter des actions d’administration à distance sur les machines du domaine, tandis que le second lui confère des actions de gestion étendus sur les comptes utilisateurs du domaine, notamment la création, la modification ou la suppression de comptes standards. Ce niveau d’accès représente un vecteur d’escalade de privilèges particulièrement critique dans un environnement Active Directory.
IV. Recommandations
Les recommandations suivantes peuvent être mises en œuvre afin de renforcer la configuration du service WDS :
Limiter l’exposition du serveur en l’isolant dans un sous-réseau (VLAN) dédié. Si cela n’est pas entièrement possible pour des raisons « métier », il est recommandé a minima de désactiver le flux SMB au niveau du pare-feu pour les zones réseau qui n’en ont typiquement pas besoin.
Nettoyer les images WinPE en supprimant tout mot de passe présent dans les scripts d’automatisation, notamment dans les fichiers Bootstrap.ini, CustomSettings.ini, Unattend.xml, ainsi que dans les scripts de séquence de tâches MDT (.vbs, .cmd, .ps1).
Appliquer le principe du moindre privilège au compte utilisé pour l’enrôlement des postes dans l’Active Directory, en privilégiant la saisie manuelle du mot de passe lors du déploiement afin d’éviter son enregistrement dans des fichiers de configuration en clair.
Enfin, c’est tout bête, mais si aucune de ces options ne vous convient et que le serveur de déploiement n’est pas utilisé régulièrement, il est recommandé de ne l’allumer qu’en cas de besoin. Parfois, cela peut être la meilleure des sécurités… tout en permettant d’économiser de l’électricité.
V. Conclusion
Le rôle WDS, combiné à MDT, est un outil efficace et très utilisé pour déployer des systèmes Windows. Pourtant, il reste souvent sous-estimé en termes de risques. Une mauvaise configuration peut exposer des infos sensibles, comme des identifiants Active Directory, et ouvrir une porte d’entrée à un attaquant. En appliquant les bonnes pratiques décrites plus haut, vous réduirez largement les risques liés à WDS et protégerez mieux votre infrastructure.
Connexion
