WPAD dans Active Directory : risques, détection et désactivation

Le protocole WPAD (Web Proxy Auto-Discovery) permet à un poste Windows de trouver seul le fichier de configuration de proxy de son réseau, sans paramétrage manuel. Dans un domaine Active Directory, cette commodité devient une faiblesse : si aucun serveur légitime ne répond à la recherche du nom « wpad », un poste peut accepter la configuration proposée par une machine hostile, lui confier son trafic web et parfois ses échanges d'authentification NTLM. En 2026, la découverte automatique reste activée par défaut sur Windows, et Microsoft a encore corrigé en juillet 2026 une vulnérabilité d'élévation de privilèges dans son implémentation. Ce guide explique le fonctionnement réel de la découverte (DHCP, DNS, résolutions locales), les risques concrets pour un domaine, les signaux à surveiller et les options de désactivation ou de durcissement compatibles avec la production. Il complète notre dossier de référence sur la sécurité Active Directory.

Qu'est-ce que WPAD ? Définition et rôle du fichier wpad.dat

Dans un réseau d'entreprise, le trafic web des postes transite souvent par un proxy filtrant. Plutôt que de saisir son adresse sur chaque machine, les administrateurs peuvent publier une seule fois les règles dans un fichier, puis laisser les postes le découvrir. C'est le rôle du protocole de découverte automatique de proxy, conçu à la fin des années 1990 et resté au stade de brouillon, sans jamais devenir une norme de l'IETF.

Le fichier wpad.dat, un script PAC

Le fichier recherché porte par convention le nom wpad.dat et se trouve à la racine d'un serveur web interne, à une adresse du type http://wpad.example.fr/wpad.dat, d'où le motif « wpad/wpad.dat » que l'on rencontre dans les journaux de proxy. Son contenu suit le format PAC (Proxy Auto-Config) : une fonction JavaScript nommée FindProxyForURL qui renvoie, pour chaque adresse demandée, une connexion directe ou un ou plusieurs proxys.

Ce format est puissant : il distingue les destinations internes et externes, répartit la charge entre plusieurs proxys ou exclut certains domaines. Cette souplesse explique aussi le danger. Celui qui contrôle le script PAC servi à un poste décide par quel intermédiaire transite son trafic web, sans que l'utilisateur voie la moindre fenêtre ni le moindre avertissement de sécurité.

WinHTTP, WinINet et le service WinHttpAutoProxySvc

Sous Windows, deux piles réseau consomment cette configuration. WinINet sert historiquement les navigateurs et les applications interactives, tandis que WinHTTP est utilisé par les services système et de nombreux agents d'entreprise. Le service WinHTTP Web Proxy Auto-Discovery, nommé WinHttpAutoProxySvc, exécute la découverte et l'interprétation du script PAC pour le compte des applications qui le sollicitent.

Selon l'alerte TA16-144A de la CISA, l'usage de WPAD est activé par défaut sur tous les systèmes Windows, alors qu'il est pris en charge sans être actif par défaut sur macOS, Linux, Chrome, Firefox ou Safari. En pratique, Edge et Chrome sous Windows suivent par défaut les paramètres de proxy du système, ce qui les rend dépendants de ce réglage.

Comment fonctionne la découverte WPAD dans Active Directory

Dans un domaine Active Directory (AD), la découverte automatique de proxy suit un enchaînement précis. Comprendre cet ordre est indispensable, car chaque étape correspond à une surface d'attaque distincte et donc à une contre-mesure spécifique. La séquence ci-dessous résume le parcours d'un poste Windows qui démarre avec l'option « Détecter automatiquement les paramètres » activée.

1. Le poste demande au serveur DHCP l'option 252, qui peut contenir l'URL complète du fichier PAC.
2. Sans réponse exploitable, il construit un nom à partir de son suffixe DNS principal et interroge le DNS.
3. Si le DNS ne fournit aucune adresse, des résolutions locales comme LLMNR ou mDNS peuvent intervenir selon la version et la configuration.
4. Le poste télécharge le fichier wpad.dat sur l'hôte trouvé, généralement en HTTP.
5. Il exécute la fonction PAC et applique le proxy indiqué à ses requêtes web.

La découverte par DHCP (option 252)

L'option DHCP 252 transporte une chaîne de caractères contenant l'URL du fichier de configuration. Elle est généralement tentée en premier, ce qui en fait la méthode la plus déterministe lorsque l'entreprise maîtrise ses serveurs DHCP. En revanche, un serveur DHCP non autorisé branché sur le même segment peut annoncer sa propre URL, d'où l'intérêt du DHCP snooping sur les commutateurs d'accès.

Le livre blanc de Verisign sur les collisions de noms souligne une limite importante : configurer la découverte uniquement par DHCP ne protège pas un ordinateur portable qui se reconnecte sur un réseau domestique ou public. Le DHCP de la box ou du hotspot ne fournit pas l'option 252, et le poste bascule alors sur la recherche DNS, avec les risques de fuite décrits dans la section suivante.

La recherche wpad dns et la dévolution des suffixes

Pour la méthode wpad dns, le poste préfixe « wpad » à son suffixe DNS principal. Un ordinateur membre de paris.corp.example.fr interroge d'abord wpad.paris.corp.example.fr, puis, par dévolution, wpad.corp.example.fr, en retirant une étiquette à chaque tentative dans la limite du niveau de dévolution configuré. Plusieurs vulnérabilités historiques, comme CVE-2007-5355 ou CVE-2009-0093, ont porté sur la construction ou l'enregistrement de ce nom.

Ce mécanisme fonctionne correctement tant que le DNS interne fait autorité sur le nom construit et y répond de façon maîtrisée. Les problèmes commencent lorsque le nom n'existe pas, lorsqu'il est volontairement bloqué par le serveur DNS sans solution de remplacement, ou lorsque le poste se trouve hors du réseau et pose la question à un résolveur public qui ignore tout de l'entreprise.

wpad.lan, wpad.localdomain : quand les requêtes quittent le réseau

Les requêtes wpad.lan et wpad.localdomain visibles dans les journaux DNS proviennent le plus souvent de postes connectés à des réseaux domestiques ou de configurations par défaut. Des routeurs grand public attribuent un suffixe comme « lan », c'est le cas par défaut d'OpenWrt, et certains systèmes utilisent « localdomain ». Le poste construit alors une requête wpad lan et l'envoie à son résolveur, qui peut la transmettre vers Internet.

Ces suffixes ne sont pas délégués dans la racine du DNS, mais le phénomène illustre un risque plus large : la collision de noms. L'alerte TA16-144A, publiée en mai 2016 par l'agence américaine CISA, décrit comment des requêtes de découverte censées rester internes atteignent des serveurs DNS publics, et comment un tiers qui enregistre le domaine correspondant dans un nouveau gTLD peut publier un proxy malveillant accessible de partout.

Les organisations dont la forêt AD repose sur un suffixe interne non enregistré, comme .corp, .dev ou .network cités par Verisign, sont les plus exposées. Le livre blanc recommande de basculer vers un sous-domaine d'un nom public déjà enregistré, par exemple ad.example.fr, ou à défaut de rendre les DNS internes autoritaires sur ce suffixe. Le 29 juillet 2024, l'ICANN a en outre réservé définitivement le TLD .internal à un usage privé.

Pourquoi une wpad attack menace tout le domaine

L'expression anglaise « wpad attack » désigne l'ensemble des scénarios où un acteur malveillant fournit lui-même la réponse à la découverte de proxy. La base MITRE ATT&CK classe la variante la plus courante dans la sous-technique T1557.001, qui couvre l'empoisonnement des résolutions LLMNR, NBT-NS et mDNS et le relais d'authentification. Le risque dépasse donc la navigation : il touche l'identité des utilisateurs du domaine.

• Interception du trafic web : les requêtes HTTP du poste transitent par un proxy choisi par l'attaquant, qui peut les lire ou les modifier.
• Exposition des métadonnées HTTPS : même chiffré, le trafic révèle les domaines visités et peut être bloqué ou redirigé.
• Capture d'authentification : un proxy hostile peut exiger une authentification et recueillir une réponse NTLM exploitable.
• Relais vers d'autres services : cette authentification peut être relayée vers LDAP, SMB ou HTTP si la signature et la protection étendue ne sont pas imposées.
• Discrétion : aucune alerte n'apparaît côté utilisateur, et le comportement ressemble au mieux à un réseau un peu lent.

Du proxy usurpé au vol d'identifiants

Le scénario le plus redouté en audit interne combine usurpation de nom et authentification implicite. Lorsqu'un poste accepte un proxy hostile, celui-ci peut répondre par une demande d'authentification ; selon la configuration, le client fournit alors une réponse NTLM calculée à partir du secret de l'utilisateur. Notre guide consacré à Responder en audit Active Directory montre comment les auditeurs mettent en évidence cette exposition.

Une fois capturée, la réponse peut être cassée hors ligne si le mot de passe est faible, ou relayée immédiatement vers un autre service. Ce second cas est le plus grave, car il ne dépend pas de la robustesse du mot de passe. Les mécanismes et les contre-mesures sont détaillés dans notre article sur le relais NTLM, ses outils et ses contre-mesures.

Vulnérabilités WPAD : de MS16-077 à CVE-2026-49800

Le bulletin Microsoft MS16-077 de juin 2016 a corrigé plusieurs failles de la découverte automatique de proxy (WPAD), dont CVE-2016-3213, liée à un mécanisme de repli vers NetBIOS. Depuis cette mise à jour, la résolution du nom de découverte n'utilise plus NetBIOS par défaut, et le téléchargement du fichier PAC n'envoie plus automatiquement les identifiants du domaine en réponse à un défi NTLM ou Negotiate.

La vulnérabilité CVE-2026-49800, corrigée par les mises à jour de sécurité de juillet 2026, rappelle que ce composant reste une surface d'attaque. Il s'agit d'un dépassement d'entier menant à une élévation de privilèges locale, qui suppose un accès préalable à la machine. Les correctifs couvrent notamment Windows 10, Windows 11 jusqu'à la version 26H1 et Windows Server 2019, 2022 et 2025.

La Global Query Block List, première protection côté DNS

Les serveurs DNS de Windows Server embarquent une protection souvent méconnue : la Global Query Block List (GQBL). Il s'agit d'une liste de noms d'hôtes auxquels le serveur refuse de répondre, quelle que soit la zone. D'après la documentation Microsoft de la cmdlet Set-DnsServerGlobalQueryBlockList, elle contient par défaut les noms wpad et isatap, deux protocoles jugés particulièrement exposés au détournement.

Une subtilité mérite l'attention. La liste est créée au premier démarrage du service DNS, et Microsoft précise que le nom wpad n'y est pas ajouté si un enregistrement de ce nom existe déjà dans une zone hébergée. Un contrôleur de domaine installé dans une forêt ancienne, où un administrateur avait créé un tel enregistrement, peut donc fonctionner sans cette protection depuis des années.

Par ailleurs, la cmdlet de modification remplace la liste entière au lieu d'y ajouter une entrée. Un administrateur qui veut bloquer un nouveau nom et oublie de reprendre les entrées existantes retire involontairement wpad du blocage. Les membres du groupe DnsAdmins peuvent aussi modifier ou désactiver la liste, ce qui justifie de traiter ces changements comme des modifications de sécurité.

Ce que la GQBL ne couvre pas

La GQBL protège uniquement les requêtes qui atteignent un serveur DNS Windows. Elle n'empêche pas un poste de chercher le nom par LLMNR ou mDNS lorsque le DNS ne fournit pas d'adresse, ni un ordinateur portable d'interroger le résolveur d'un hôtel. Elle ne protège pas davantage contre une option DHCP 252 frauduleuse. C'est une couche utile, mais insuffisante si elle reste isolée.

<# Audit en lecture seule : GQBL et enregistrements wpad sur chaque contrôleur de domaine #>
Import-Module ActiveDirectory, DnsServer
foreach ($dc in (Get-ADDomainController -Filter *).HostName) {
    $gqbl = Get-DnsServerGlobalQueryBlockList -ComputerName $dc
    "{0} | GQBL active : {1} | liste : {2}" -f $dc, $gqbl.Enable, ($gqbl.List -join ', ')
    Get-DnsServerZone -ComputerName $dc |
        Where-Object { $_.ZoneType -eq 'Primary' -and -not $_.IsAutoCreated } |
        ForEach-Object {
            $rr = Get-DnsServerResourceRecord -ComputerName $dc -ZoneName $_.ZoneName -Name 'wpad' -ErrorAction SilentlyContinue
            if ($rr) { "  ALERTE : enregistrement wpad dans la zone {0}" -f $_.ZoneName }
        }
}
<# Option DHCP 252 au niveau serveur (répéter avec -ScopeId pour chaque étendue) #>
Get-DhcpServerv4OptionValue -ComputerName 'dhcp01' -All | Where-Object OptionId -eq 252

Auditer l'exposition WPAD de votre parc Active Directory

Avant toute désactivation, un état des lieux évite les mauvaises surprises en production. L'objectif est de savoir si la découverte automatique de proxy est réellement utilisée, par quels postes et via quel canal, puis d'identifier les configurations qui laissent une place à l'usurpation. Cet audit se mène en lecture seule, sur les serveurs DHCP, les serveurs DNS et un échantillon représentatif de postes.

• Serveurs DHCP : présence de l'option 252 au niveau du serveur ou des étendues, et URL annoncée.
• Zones DNS intégrées à AD : existence d'un enregistrement wpad, propriétaire de l'objet et date de création.
• Contrôleurs de domaine : état de la GQBL sur chacun d'eux, car le paramètre est local à chaque serveur DNS.
• Postes de travail : valeur de DisableWpad, état de la détection automatique et proxy WinHTTP configuré.
• Résolution locale : statut de LLMNR, NBT-NS et mDNS dans les stratégies de groupe appliquées.
• Nommage : suffixe DNS de la forêt et risque de collision avec un TLD public.

Sur les zones DNS intégrées à Active Directory, contrôlez aussi les droits de création d'enregistrements. Dans la configuration par défaut, les utilisateurs authentifiés peuvent créer de nouveaux enregistrements dans ces zones, ce qui permet à n'importe quel compte du domaine d'y publier un nom encore libre. Cette possibilité rend d'autant plus importante la présence de wpad dans la liste de blocage de chaque serveur.

Retour terrain : Cas typique rencontré en mission — en audit interne Active Directory, je retrouve régulièrement un enregistrement wpad hérité d'un ancien projet de proxy, pointant vers une adresse IP réattribuée depuis à un poste de travail. Sur certains contrôleurs de domaine, wpad a aussi été retiré de la GQBL, sans documentation. Ce poste peut alors servir un fichier PAC aux machines en détection automatique. La correction prend quelques jours : suppression de l'enregistrement, restauration de la GQBL sur chaque serveur DNS et contrôle récurrent dans le suivi de configuration.

Détecter une attaque WPAD : les signaux réseau

La détection d'un abus de découverte de proxy repose sur un principe simple : dans un réseau sain, seuls quelques serveurs connus devraient répondre aux recherches de ce nom ou servir un fichier PAC. Dès lors, toute réponse provenant d'un poste de travail ou d'une adresse inconnue constitue un signal fort, bien plus fiable que le simple volume de requêtes, qui reste élevé sur tout parc Windows.

Les signaux côté réseau

• Réponses LLMNR (UDP 5355) ou NBT-NS (UDP 137) émises par des hôtes qui ne sont ni des serveurs ni des contrôleurs de domaine.
• Requêtes HTTP vers /wpad.dat adressées à l'adresse IP d'un poste de travail.
• Requêtes DNS wpad.* sortant vers des résolveurs publics, signe d'une fuite de suffixe interne.
• Offres DHCP contenant l'option 252 émises par un serveur non autorisé.

La CISA recommande de configurer pare-feu et proxys pour journaliser et bloquer les requêtes sortantes vers des fichiers wpad.dat. Ces journaux sont précieux : un poste qui tente de télécharger un script PAC sur Internet révèle soit un problème de nommage, soit une tentative de détournement. Dans les deux cas, l'investigation commence par l'identification du poste et du réseau auquel il était connecté.

Journaux Windows : repérer les abus sur les postes et les contrôleurs

Sur les postes Windows, Sysmon journalise les requêtes DNS dans son événement 22, ce qui permet de repérer les recherches du nom utilisé par la découverte automatique de proxy (WPAD) et le processus qui les émet. Sur les contrôleurs de domaine, surveillez les modifications des valeurs de registre EnableGlobalQueryBlockList et GlobalQueryBlockList du service DNS, ainsi que les créations d'objets dans les partitions DNS de l'annuaire, visibles via l'événement 5137 si une SACL d'audit les couvre.

Ces signaux supposent une journalisation correctement dimensionnée sur les contrôleurs de domaine et les serveurs DNS. Notre méthode pour configurer une stratégie d'audit avancée dans Active Directory détaille les sous-catégories à activer et la manière de transmettre ces événements vers un SIEM sans saturer le stockage.

Désactiver WPAD proprement : registre et GPO

Lorsque l'entreprise n'utilise pas la découverte automatique, la désactivation reste la mesure la plus efficace. Microsoft documente une valeur de registre dédiée, DisableWpad, disponible depuis Windows 10 version 1809 et Windows Server 2019. Fixée à 1, elle arrête la détection pour tous les appels passant par l'API WinHTTP ; les proxys doivent ensuite être configurés explicitement.

La même page précise deux limites. D'abord, une application peut toujours résoudre le nom wpad en interrogeant directement le DNS. Ensuite, la détection automatique doit aussi être désactivée dans les paramètres de Windows, car des applications tierces et des navigateurs s'appuient sur ce réglage pour leur propre découverte de proxy. Les deux actions sont donc complémentaires et doivent être déployées ensemble.

<# Poste client : état actuel de la découverte #>
Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp' -Name DisableWpad -ErrorAction SilentlyContinue
netsh winhttp show proxy

<# Désactivation documentée par Microsoft (Windows 10 1809+ / Server 2019+), à déployer par GPO #>
reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp" /v DisableWpad /t REG_DWORD /d 1 /f

<# À éviter : désactiver le service WinHttpAutoProxySvc (incidents signalés sous Windows 11 24H2) #>

Le piège du service WinHttpAutoProxySvc

Désactiver le service WinHttpAutoProxySvc paraît radical et donc séduisant. C'est pourtant une fausse bonne idée : ne désactivez pas ce service par stratégie de groupe. Depuis la mise à niveau vers Windows 11 24H2, de nombreux administrateurs ont signalé sur les forums de Microsoft des pertes de connectivité sur des postes où il était désactivé, le gestionnaire de connexions WcmSvc en dépendant désormais.

Navigateurs et postes gérés : verrouiller la configuration du proxy

Désactiver la découverte automatique de proxy (WPAD) au niveau du système ne suffit pas si un navigateur applique ses propres réglages. Edge et Chrome sous Windows suivent par défaut les paramètres du système, mais disposent de stratégies d'entreprise, comme ProxyMode ou ProxyPacUrl, pour imposer un proxy fixe ou un script PAC explicite. Firefox gère ses paramètres de façon autonome et se pilote aussi par stratégie.

Sur les postes gérés par Intune, le CSP NetworkProxy expose un nœud AutoDetect qui désactive la détection automatique, ainsi qu'un nœud permettant de définir l'URL du script de configuration. Inventoriez enfin les agents logiciels qui embarquent leur propre pile HTTP, comme certains outils de sauvegarde, de supervision ou de mise à jour : ils peuvent conserver un comportement de découverte indépendant des réglages de Windows.

Conserver WPAD sans s'exposer : durcir plutôt que supprimer

Certaines organisations dépendent encore de la découverte automatique, par exemple pour des postes non gérés, des environnements industriels ou des réseaux invités. Dans ce cas, l'objectif n'est plus de supprimer le protocole Web Proxy Auto-Discovery, mais de garantir que la seule réponse possible provient d'un serveur maîtrisé, sur le réseau interne comme à l'extérieur.

1. Préférez une URL de configuration explicite poussée par GPO ou Intune, qui supprime toute l'étape de découverte.
2. Si la découverte reste nécessaire, annoncez l'URL par l'option DHCP 252 sur des étendues maîtrisées et activez le DHCP snooping.
3. Pour la recherche DNS, créez un enregistrement statique, retirez le nom de la GQBL de façon documentée et restreignez les droits sur l'objet.
4. Hébergez le script PAC sur un serveur durci, en lecture seule, avec un contrôle d'intégrité du fichier.
5. Bloquez et journalisez en sortie les téléchargements de wpad.dat et les requêtes DNS de découverte vers l'extérieur.

Le nommage de la forêt compte autant que la configuration. Si votre domaine AD repose sur un suffixe interne non enregistré, planifiez sa sortie ou, à défaut, rendez vos DNS internes autoritaires sur ce suffixe, comme le recommandent la CISA et Verisign. Les postes nomades doivent en outre disposer d'une configuration de proxy explicite, car la découverte par DHCP disparaît dès qu'ils quittent le réseau.

Réduire la surface autour de WPAD : LLMNR, NBT-NS et NTLM

La découverte automatique de proxy n'est dangereuse que parce qu'un tiers peut répondre à sa place puis récupérer une authentification exploitable. Agir sur ces deux leviers réduit fortement l'impact, même si un poste mal configuré subsiste. MITRE ATT&CK recommande ainsi de désactiver LLMNR, mDNS et NetBIOS par stratégie de groupe lorsqu'ils ne sont pas nécessaires, et de filtrer leur trafic.

• LLMNR : activez le paramètre « Désactiver la résolution de noms multidiffusion » sous Modèles d'administration, Réseau, Client DNS.
• NBT-NS : désactivez NetBIOS sur TCP/IP via l'option fournisseur Microsoft du DHCP ou la configuration des cartes réseau.
• mDNS : désactivez-le lorsque aucun usage métier ne l'exige, après une phase de test.
• SMB : imposez la signature sur les serveurs et les postes de travail.
• LDAP : exigez la signature et la liaison de canal sur les contrôleurs de domaine.
• NTLM : auditez puis restreignez son usage, en privilégiant Kerberos.

Ces paramètres s'intègrent naturellement dans un socle de GPO de durcissement Active Directory, déployé par vagues et mesuré. Restreindre NTLM réduit à la fois le relais d'authentification et d'autres abus du protocole, comme le Pass-the-Hash dans Active Directory, qui exploite directement l'empreinte du mot de passe.

Pour visualiser la chaîne complète entre empoisonnement de nom, proxy usurpé et relais vers un service sensible, consultez notre analyse de l'attaque NTLM Relay, de l'exploitation à la défense. Elle montre pourquoi la signature des protocoles reste la contre-mesure la plus robuste, même lorsque la résolution de noms ne peut pas être totalement verrouillée.

Plan d'action WPAD en cinq étapes pour 2026

Un durcissement réussi de la découverte automatique de proxy suit un ordre précis : mesurer, protéger le DNS, désactiver côté client, couper les résolutions locales, puis surveiller. Cet ordre limite le risque d'incident, car chaque étape s'appuie sur les constats de la précédente et peut être validée sur un groupe pilote avant sa généralisation.

1. Semaine 1, inventaire : exécutez l'audit des contrôleurs de domaine et des serveurs DHCP, puis identifiez les postes qui téléchargent réellement un fichier PAC.
2. Semaine 1, DNS : rétablissez wpad dans la GQBL de chaque serveur, sauf usage documenté, et supprimez les enregistrements orphelins.
3. Semaines 2 et 3, postes : déployez DisableWpad et verrouillez la détection automatique sur un pilote, puis sur l'ensemble du parc.
4. Semaine 3, résolution locale : désactivez LLMNR et NBT-NS, puis imposez la signature SMB et LDAP.
5. Semaine 4, surveillance : activez les alertes sur les réponses LLMNR anormales, les modifications de GQBL et les téléchargements de wpad.dat.

Retour terrain : Cas typique rencontré en mission — la désactivation à grande échelle bute rarement sur les navigateurs, mais souvent sur des clients lourds métier, des agents de mise à jour ou des outils de supervision qui s'appuyaient sans le savoir sur le proxy découvert automatiquement. Un pilote de quelques semaines, réunissant des postes de chaque métier et des portables nomades, fait apparaître ces dépendances. Point de vigilance : configurer explicitement le proxy WinHTTP des services système avant la généralisation, et garder prête une stratégie de groupe de retour arrière.

À lire aussi : l'empoisonnement de cache DNS ; la détection Kerberos avec l'event ID 4769.

Questions fréquentes

Conclusion

WPAD illustre un travers récurrent de la sécurité Active Directory : une fonction de confort, activée par défaut, qui fait confiance à la première réponse reçue. Dans la plupart des organisations, la découverte automatique de proxy n'est plus nécessaire et peut être désactivée par GPO, à condition de traiter ensemble WinHTTP, les paramètres utilisateur et les navigateurs. Là où elle reste utile, une URL explicite et un DNS maîtrisé suppriment l'essentiel du risque.

La priorité pour la fin 2026 consiste à vérifier la GQBL sur chaque contrôleur de domaine, à appliquer les correctifs de juillet, à couper LLMNR et NBT-NS, puis à surveiller les réponses anormales. Pour replacer ces mesures dans une feuille de route globale de sécurisation de l'annuaire, appuyez-vous sur notre hub de sécurité Active Directory.