Les hacktivistes exploitent les systèmes industriels canadiens connectés, ciblant eau, énergie et agriculture, selon une alerte du Centre pour la cybersécurité.

Un dépôt GitHub de ressources de pentest
— Permalien

Vous venez de claquer plusieurs milliers d’euros dans une solution antivirus dernier cri pour votre boîte car le commercial vous a convaincu avec du machine learning, de l’IA comportementale, du threat hunting prédictif et j’en passe…

Cool story ! Mais si je vous disais qu’un petit exécutable open source gratuit peut potentiellement passer à travers ? Ce programme s’appelle al-khaser et je vous assure qu’il va vous faire déchanter, car ce truc, c’est le détecteur de mensonges des solutions de cybersécurité.

Al-khaser est outil qui ne fait rien de méchant en soi… C’est ce qu’on appelle un PoC, un “proof of concept” avec de bonnes intentions car il rassemble dans un seul programme toutes les techniques que les vrais malwares utilisent pour se planquer tels que la détection de machines virtuelles, le contournement des débogueurs, l’échappement aux sandbox, et j’en passe.

Comme ça, si votre antivirus ne détecte pas al-khaser, il y a de bonnes chances qu’il rate aussi les vraies menaces qui utilisent les mêmes techniques.

Faut dire que les éditeurs d’antivirus et d’EDR adorent nous vendre leurs nouvelles fonctionnalités IA de fou alors que certaines de leurs solutions ne détectent même pas des techniques pourtant connues depuis longtemps.

Al-khaser met donc tout ça en lumière de façon assez brutale en enchaînant des dizaines de vérifications. Par exemple, il va regarder si votre processeur a vraiment le bon nombre de cœurs ou si c’est une simulation. Il va checker l’adresse MAC de votre carte réseau pour voir si elle correspond à un hyperviseur VMware ou VirtualBox. Il va mesurer le temps d’exécution de certaines opérations pour détecter si le système est accéléré artificiellement, comme dans une sandbox d’analyse. Il va même tester des API Windows classiques comme IsDebuggerPresent ou CheckRemoteDebuggerPresent pour voir si quelqu’un espionne son exécution.

Maintenant si vous voulez tester les protections anti-debug de votre système, vous tapez :

al-khaser.exe –check DEBUG –sleep 30

Oui si vous voulez voir si votre virtualisation VMware ou QEMU est bien masquée :

al-khaser.exe –check VMWARE –check QEMU

Bien sûr, ces techniques ne sortent pas de nulle part car elles sont documentées depuis des années notamment dans ce référentiel dont je vous déjà parlé .

Les équipes de pentest et les red teams adorent al-khaser car ça leur permet de montrer aux décideurs que leur gros investissement en cybersécurité n’est peut-être pas aussi solide qu’ils le pensaient. Vous lancez l’outil un vendredi après-midi dans un environnement de test, et vous voyez instantanément ce que votre EDR détecte ou pas.

Voilà, une fois encore, rassurez-vous, al-khaser ne fait rien de malveillant… Il ne vole pas de données, ne chiffre pas vos fichiers, ne lance pas de ransomware mais se contente juste de lever la main et de dire “hé ho, je suis là, regardez moi, je fais plein de des trucs louches !!”.

Bien sûr, ne lancez pas al-khaser sur n’importe quelle machine car c’est un outil de test qui doit rester dans un environnement contrôlé. Si vous le lancez sur le réseau de prod sans prévenir votre équipe sécu, vous allez déclencher des alertes partout et recevoir des appels pas très sympathiques. Et surtout, juridiquement, vous devez avoir l’autorisation du propriétaire de l’infrastructure, sinon, vous risquez de gros ennuis.

Ce projet est open source, écrit essentiellement en C++, et disponible sur GitHub . Y’a plus qu’à vous monter une VM isolée, récupérer al-khaser, et voir ce que ça donne.

Vous faites du pentest, de la recherche en sécu ou vous êtes juste un curieux qui aime bidouiller des environnements de test ? Dans ce cas, il faut absolument que vous vous montiez un lab cybersécurité ! Mais c’est vai que c’est souvent la galère… Y’a Active Directory à configurer, des VMs Windows à déployer, des réseaux isolés à créer, tout ça manuellement… Ça prend des heures, voire des jours. Heureusement, Ludus règle le problème ! Vous décrivez ce que vous voulez dans un fichier YAML, vous tapez une commande, et hop, votre lab est prêt.

Ludus , c’est donc un système d’automatisation open-source qui tourne sur Proxmox. Vous définissez votre environnement de test (ce qu’ils appellent un “range”) dans un fichier de config, et Ludus s’occupe de tout déployer. Active Directory, machines Windows avec Office et Chocolatey, réseaux isolés, firewall rules personnalisées, DNS interne… Tout ce qu’il faut pour un lab de red team, blue team ou purple team.

En octobre 2016, un développeur suisse connu sous le pseudo swisskyrepo a commencé à compiler ses notes de pentester dans un dépôt GitHub. Rien de révolutionnaire au départ, juste un mec qui en avait marre de chercher la même injection SQL pour la 50ème fois dans ses notes. Mais ce qui est cool c’est qu’au fur et à mesure des années, il a structuré ça proprement avec une section par type de vulnérabilité, des README clairs, des fichiers Intruder pour Burp Suite, des exemples concrets…etc.

Ça s’appelle Payloads All The Things, et c’est accessible ici .

Ce qui était donc au départ un simple carnet de notes personnel est devenu THE référence mondiale en cybersécurité offensive avec des centaines de contributeurs qui ajoutent quotidiennement de nouvelles techniques. C’est devenu la pierre de Rosette (pas la charcuterie, renseignez-vous !! lol) de la sécurité offensive, celle qu’on cite dans tous les cours de certification OSCP, celle qu’on consulte pendant les CTF, celle qu’on recommande aux débutants…

Avant PayloadsAllTheThings, le savoir en cybersécurité offensive était soit verrouillé dans des formations hors de prix à 5 000 boules, soit éparpillé dans des recoins obscurs du web, soit jalousement gardé par des pentesters qui pètent plus haut que leur cul… Des pêt-testeurs quoi…

SwisskyRepo a d’ailleurs fait un choix radical qui est tout mettre en open source, sous licence MIT, accessible à tous. Et le contenu, c’est du lourd !

On y trouve tout ce dont un pentester peut avoir besoin : SQL Injection avec toutes les variantes possibles (MySQL, PostgreSQL, Oracle, MSSQL…), XSS avec les bypasses de filtres, SSRF avec les techniques d’exfiltration, Command Injection, OAuth Misconfiguration, GraphQL Injection, File Inclusion, Authentication Bypasses, API Key Leaks…etc… La liste est hallucinante.

Chaque section est structurée comme un cookbook technique avec le contexte de la vulnérabilité, les payloads classés par type, les bypasses pour contourner les protections, des exemples concrets, et les références vers les CVE ou les articles de recherche.

Par exemple, si vous voulez exploiter un serveur Redis mal configuré, il y a une section pour ça. Si vous voulez comprendre comment contourner un WAF, pareil ! Et si vous cherchez à pivoter dans un réseau interne après avoir compromis une machine, tout est documenté en anglais sur ce site.

Mais swisskyrepo ne s’est pas arrêté là. Son projet a muté en écosystème puisqu’il a aussi créé InternalAllTheThings , un wiki dédié au pentesting interne et aux attaques Active Directory (Certificate Services, Enumeration, Group Policies, Kerberos attacks, Hash manipulation, Roasting techniques…).

Et également HardwareAllTheThings , le même genre de wiki mais sur la sécurité hardware et IoT : JTAG, SWD, UART pour les interfaces de debug, firmware dumping et reverse engineering, Arduino, Raspberry Pi, Flipper Zero pour les gadgets, Bluetooth, CAN, WiFi, RFID/NFC pour les protocoles, SDR et GSM pour la radio, fault injection pour les attaques par canal auxiliaire…

Bref, tout ce qu’il faut savoir pour hacker des objets connectés, des cartes à puce ou des systèmes embarqués.

Du coup, avec cette famille complète de “AllTheThings”, on couvre toute la surface d’attaque moderne, le web, l’infra interne et le hardware. Un pentest complet peut donc se faire avec ces trois ressources comme base de connaissance. Chouette non ?

Bien, sûr c’est à utiliser dans un cadre légal, sinon, vous irez en prison ! C’est pas un forum de script kiddies qui échangent des zero-days volés, c’est une vraie bibliothèque technique pour les professionnels et les étudiants en cybersécurité.

Grâce à ça, un étudiant motivé peut devenir compétent en sécurité offensive en quelques mois juste avec des ressources gratuites : PayloadsAllTheThings pour les techniques, TryHackMe ou HackTheBox pour la pratique, les blogs de chercheurs pour les analyses approfondies, les conférences enregistrées (DEF CON, Black Hat) pour rester à jour.

Le savoir se libère, n’en déplaise aux relous ! Moi je trouve que c’est cool, car ça vulgarise les connaissances, ça les mets à la portée de tous et c’est tant mieux.

Donc un grand merci à SwisskyRepo d’avoir lancé ce projet !

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.

Pour aller plus loin : Quelle est la différence entre le format GPT et MBR pour un disque dur ?

source

source

3. Network boot

• 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 :

nxc smb computers.txt -u $USER -p $PASSWORD --shares

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.

mkdir REMINST_DUMP && cd REMINST_DUMP
smbng -d "$DOMAIN" -u "$USER" -p "$PASSWORD" --host "$WDS_TARGET_IP"

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.

Merci à @scam pour leur relecture

++

GSB // @archidoté

L’article Quid de la sécurité du rôle Windows Deployment Services – WDS ? est apparu en premier sur Le Guide Du SecOps • LGDS.

— Permalink