Durcissement de Windows 11 pour Postes de Travail a Haut Risque

Un poste de pentester compromis est un cauchemar reglementaire : cles SSH clients, captures d'identifiants, payloads signes et rapports sous NDA cohabitent sur le meme disque. Chez Basilisk OffSec, nous traitons chaque portable Windows 11 comme un endpoint hostile jusqu'a preuve du contraire, et nous le durcissons comme si l'operateur allait etre hameconne, braque et audite la meme semaine. Cette note documente le baseline que nous executons en production depuis mars 2026 sur 47 machines : regles ASR en mode block, Credential Guard avec VBS renforce, AppLocker pour le perimetre utilisateur et WDAC pour le noyau. La configuration n'est pas elegante, mais elle a reduit de maniere mesurable la surface que nous avions cartographiee dans Bypass d'AMSI et d'ETW pour la Recherche Defensive : Ce que les Blue Teams Doivent Savoir. Cette version etendue parcourt toute la pile couche par couche, avec les reglages exacts, les compromis et l'ordre de deploiement qui evite de bloquer sa propre flotte.

Le modele de menace : pourquoi le portable de l'operateur est le joyau

Avant de toucher un seul objet de strategie de groupe, notez contre qui vous defendez. Un portable de securite offensive n'est pas un endpoint d'entreprise normal : il detient des secrets clients dechiffres, des profils C2 et des rapports decrivant comment penetrer d'autres entreprises. Les adversaires realistes sont au nombre de trois : un operateur de phishing qui pose une macro ou un LNK malveillant, un voleur qui saisit l'appareil dans un aeroport, et un attaquant determine qui veut specifiquement les donnees du client. Chacun exige un controle different. Le phishing se traite par le controle d'execution (ASR, AppLocker, WDAC) ; le vol se traite par le chiffrement pre-boot et le lien au TPM ; la compromission ciblee se traite par l'isolation des identifiants et la telemetrie. Sauter le modele et tout activer d'un coup est la maniere dont les equipes cassent des labs Caldera puis, exasperees, desactivent toute la politique. Cartographiez les actifs, hierarchisez-les, et laissez ce classement decider quel interrupteur vous basculez en premier.

Fondation materielle : TPM, Secure Boot, DMA et firmware

Chaque controle logiciel ci-dessous repose sur du materiel de confiance, alors nous commencons la. Nous exigeons un TPM 2.0 actif, Secure Boot avec nos propres cles enrolees, la protection Kernel DMA activee et un firmware avec Intel Boot Guard ou AMD Platform Secure Boot selon le constructeur. Sans cette racine de confiance, toute politique reste du theatre : une attaque DMA via Thunderbolt ou un chargeur d'amorcage pirate defait tout en quelques minutes. Le portable standard est un ThinkPad P14s Gen 5 ou un Surface Laptop 7. Nous desactivons le CSM legacy, verrouillons le firmware avec un mot de passe superviseur et coupons le boot depuis USB et reseau pour la flotte generale. Dans le firmware, nous desactivons aussi les radios inutilisees et le lecteur d'empreinte quand le modele impose un pre-boot par PIN uniquement. Pour le meme standard operationnel sur serveurs, nous avons publie Hardening de Serveur Linux : CIS Benchmark Applique Sans Casser la Prod avec la meme philosophie.

Chiffrement integral du disque : BitLocker avec code PIN pre-boot

BitLocker n'est pas negociable et doit etre lie au TPM plus un code PIN pre-boot, pas au TPM seul. Le TPM seul deverrouille le disque automatiquement au demarrage, ce qui signifie qu'un portable eteint et vole est a un tour de cold-boot ou de DMA du texte clair. Nous imposons XTS-AES 256, exigeons un PIN numerique d'au moins huit chiffres (via la strategie d'authentification supplementaire au demarrage) et rangeons la cle de recuperation de 48 chiffres dans un coffre offline de l'equipe, jamais dans un compte Microsoft ni dans un Active Directory lisible par le support. Nous activons aussi BitLocker pour les lecteurs de donnees fixes et amovibles, de sorte que la partition des rapports et toute cle USB de travail sont couvertes. La suspension de protection pour les mises a jour firmware desinvoltes est desactivee ; chaque deverrouillage est journalise. Resultat : un appareil perdu est une perte materielle, pas une notification de violation.

Credential Guard, VBS, Secure Launch et HVCI

La premiere couche logicielle est la securite basee sur la virtualisation. Via Group Policy nous rendons obligatoires Device Guard, Virtualization Based Security, Secure Launch et HVCI (integrite du code imposee par l'hyperviseur). Credential Guard deplace les hachages NTLM et les tickets Kerberos dans un processus isole en VTL1 que l'OS normal ne peut pas lire, de sorte qu'un point d'appui dans la session utilisateur ne peut pas simplement racler des identifiants de domaine en memoire. HVCI impose que seul du code signe et verifie s'execute dans le noyau, fermant la porte aux rootkits non signes et a de nombreuses chaines BYOVD. Secure Launch utilise le DRTM du CPU pour retablir la confiance apres le firmware, retrecissant la fenetre de demarrage. Il y a un cout reel : HVCI bloque certains vieux pilotes et ajoute quelques points de surcharge sur les gros builds, mesure sur notre pipeline de build du Sliver custom. Ce cout achete une session operateur qui fuit bien moins quand elle est inevitablement sondee.

Protection de LSASS : RunAsPPL et audit d'acces

Meme avec Credential Guard, LSASS reste une cible pour le dumping par handles, alors nous l'executons en Protected Process Light. Nous posons RunAsPPL=1 dans HKLM\SYSTEM\CurrentControlSet\Control\Lsa (variante verrouillee par UEFI la ou c'est supporte) et activons l'audit d'acces a LSASS. En tests internes cela a casse mimikatz classique, l'abus de MiniDump via comsvcs.dll et plusieurs astuces de duplication de handles sans meme un EDR, et la protection LSA a bloque chaque tentative d'injection rejouee depuis Persistance Windows : 10 Techniques Documentees et leurs Contre-mesures. Le controle complementaire est une regle de detection sur l'acces aux handles de processus vers lsass.exe avec un masque d'acces desire 0x1010 ou 0x1410, la signature d'une tentative de dump. Cout : environ quatre pour cent de surcharge CPU sur les gros builds Rust, mesure sur notre pipeline du Sliver custom. Prix modique pour le chemin de vol d'identifiants le plus abuse sous Windows.

Regles Attack Surface Reduction en mode block

ASR arrive ensuite et c'est precisement la que la plupart des equipes perdent leurs nerfs. Nous activons les seize regles en block, pas en audit. Oui, cela casse les processus enfants d'Office, l'execution de scripts obfusques, les processus issus de WMI et les executables USB non fiables. Nous gardons une OU separee nommee "OffSec-Tools" ou certaines regles restent en audit pour la machine de laboratoire du chercheur qui doit faire tourner Caldera, comme decrit dans Adversary Emulation avec Caldera et MITRE ATT&CK en Lab d'Entreprise. Pour le reste de la flotte, la regle D4F940AB-401B-4EFC-AADC-AD5F3C50688A (bloquer les processus enfants d'Office) a elle seule a neutralise 73 pour cent des vecteurs d'initial access simules dans Initial Access Simule : Macros, LNK et ISO dans un Lab Windows 11 Isole. Combinez-la avec le blocage du vol d'identifiants depuis LSASS, du contenu executable des e-mails et des appels Win32 depuis les macros Office pour le meilleur rendement par regle.

AppLocker pour le perimetre utilisateur

AppLocker et WDAC vivent dans des couches differentes et vous voulez les deux. AppLocker gouverne le user-mode via des listes par editeur et par chemin et est ideal pour stopper le ZIP suspect qu'un utilisateur vient de deposer dans Downloads ou un script sous un profil utilisateur. Nous refusons par defaut l'execution depuis les emplacements inscriptibles (Downloads, Temp, AppData) et n'autorisons que les binaires signes plus un chemin d'outils cure sous un repertoire detenu par l'admin. Les regles couvrent EXE, DLL, MSI, Script et applications empaquetees ; les regles DLL sont actives malgre leur cout parce que le side-loading de DLL est une technique de loader favorite. AppLocker s'applique via le service Application Identity et s'audite d'abord : deux semaines en "audit seul", on recolte les evenements 8003 et 8004, puis on passe en enforce. Ce n'est pas une frontiere dure a lui seul, mais comme tamis externe devant WDAC il retire une enorme classe de dechets lances par l'utilisateur.

WDAC pour la couche noyau et pilotes

WDAC (Windows Defender Application Control) est la veritable frontiere d'integrite du code et couvre noyau et pilotes via une politique signee liee a notre certificat EV, avec les Microsoft Recommended Driver Block Rules importees en janvier 2026. Nous generons la politique de base avec New-CIPolicy, la faisons tourner en audit pendant 30 jours, collectons les event IDs 3076 et 3077, raffinons puis passons en enforce seulement ensuite. Le gain : les pilotes vulnerables catalogues sur loldrivers.io, y compris ceux utilises dans les routines d'evasion couvertes dans Evasion EDR pour la Recherche : Direct Syscalls Expliques sans Romance, ne se chargent tout simplement plus. Seuls s'executent les binaires signes par Microsoft, par l'OEM (Lenovo, Microsoft Surface) ou correspondant a nos hashes internes. Nous deployons la politique comme fichier signe et verrouille par UEFI, de sorte qu'un attaquant admin ne puisse pas l'echanger en silence, et alertons sur tout evenement de modification de politique comme signal de haute severite.

Microsoft Defender comme derniere couche et sa telemetrie

Defender arrive en dernier avec Tamper Protection active, Cloud Block Level eleve, PUA en block, Network Protection actif et Controlled Folder Access couvrant Documents, Bureau et le repertoire des rapports. Le point n'est pas que Defender attrape tout ; c'est que chaque couche au-dessus a deja retreci le champ, donc Defender est desormais un capteur a fort signal plutot qu'un portier bruyant. Nous envoyons les evenements vers le pipeline Sigma plus Elastic decrit dans Threat Hunting avec Sigma et Elastic : De l'Indicateur a la Regle de Detection, avec un focus sur la modification de politique WDAC, la creation de service via sc.exe, la persistance par taches planifiees et l'acces aux handles LSASS avec masque 0x1010. Sur 90 jours sur 47 postes nous avons eu zero compromission confirmee et douze alertes a fort signal, dont deux veritables tentatives de drive-by pendant des engagements bug bounty. Une telemetrie sans rotation de revue est de la deco, alors chaque classe d'alerte a un proprietaire nomme et un runbook.

Methodologie de deploiement et gouvernance des exceptions

Le pire mode d'echec est de basculer tous les interrupteurs d'un coup, de casser quelqu'un en plein engagement et de voir toute la politique desactivee de rage avant midi. Ne faites pas cela. Roulez 30 jours en audit, envoyez les logs vers un SIEM, ajustez l'ensemble minimal viable d'exceptions et passez en block seulement ensuite. Chaque exception recoit un ticket Jira, un proprietaire nomme et une date de revue trimestrielle, car un durcissement que personne ne relit pourrit en six mois quand arrivent de nouveaux outils et versions de pilotes. Versionnez les politiques comme du code dans un depot git, signez-les en CI et deployez via Intune ou votre outil de gestion de configuration pour que le baseline soit reproductible et comparable. Traitez l'OU OffSec-Tools comme une exception documentee et surveillee, pas comme une porte derobee permanente, et re-baselinez-la chaque trimestre selon ce dont les chercheurs ont reellement encore besoin.

FAQ : cela casse-t-il l'outillage quotidien de pentest ?

La plupart du temps non, et la ou cela casse, la casse est intentionnelle et bornee. WDAC en enforce bloque l'outillage custom non signe, c'est pourquoi le lab du chercheur vit dans sa propre OU avec une politique relachee et sans donnees clients. Pour la flotte de production nous signons nos binaires internes et ajoutons leurs hashes a la politique WDAC, de sorte que les outils maison en Rust et Go tournent alors que des executables non signes au hasard non. ASR en block empeche Office de lancer cmd.exe ou PowerShell, ce qui n'arrive presque jamais dans le travail legitime d'operateur ; les rares modeles de reporting charges en macros ont ete migres hors de VBA. Si un outil a vraiment besoin d'une exception, cela passe par le processus d'exclusion a ticket plutot qu'un relachement general de politique, de sorte que le rayon d'impact de chaque autorisation reste petit et auditable.

FAQ : comment demarrer de zero sans interruption ?

Activez les controles dans l'ordre de dependance pour que chaque etape soit independamment utile et reversible. La sequence recommandee : d'abord BitLocker avec PIN pre-boot, puis Credential Guard et VBS, puis LSA PPL, puis ASR en audit suivi de block, puis AppLocker en audit suivi d'enforce, puis WDAC en audit suivi d'enforce. Chaque etape tourne au moins une semaine avec les logs vers le SIEM avant que la suivante n'atterrisse, de sorte qu'une regression est confrontee a une variable et non a dix. Gardez un rollback documente pour chaque GPO et un admin local de secours range hors ligne. Personne ne devrait pouvoir designer un seul changement et dire "on ne sait pas si c'est ca qui l'a casse", parce que vous avez change exactement une chose a la fois.

Conclusion : un baseline qui survit au contact

Le durcissement de postes a haut risque n'est pas un projet heroique d'une journee ; c'est un baseline en couches qui doit survivre a de vrais engagements, de vrais scenarios de vol et de vrais audits. Racine de confiance materielle, BitLocker avec PIN, Credential Guard, LSA PPL, ASR en block, AppLocker, WDAC et un capteur Defender alimentant un pipeline surveille transforment ensemble le portable de l'operateur d'une cible molle en un endroit veritablement hostile ou atterrir. L'ordre compte autant que les reglages : audit avant block, une variable a la fois, chaque exception a ticket et revue. Faites-le dans cette sequence, gardez les politiques dans git, et vous menerez des operations offensives sur des machines que vous pouvez reellement defendre, remettre a un auditeur et perdre dans un aeroport sans ecrire de notification de violation.