Ce qu’un test d’intrusion sur le réseau externe trouve vraiment

Nous trouvons encore sur l’internet public des panneaux de connexion qui acceptent admin/admin du premier coup. Pas une fois, pas par hasard. C’est un titre récurrent dans nos rapports. Un boîtier de sauvegarde installé en rack il y a des années et plus jamais touché. Un serveur de préproduction qu’un développeur a monté un week-end avant de l’oublier. Un port d’administration de pare-feu censé être restreint à une seule IP de bureau et qui ne l’a jamais été.

Voilà la vérité qui dérange à propos des tests d’intrusion sur le réseau externe: la voie d’entrée n’est presque jamais astucieuse. C’est quelque chose que vous possédez déjà et que vous avez cessé de surveiller.

Un test d’intrusion sur le réseau externe consiste à attaquer vos systèmes exposés sur internet comme le ferait un véritable intrus – depuis l’extérieur, sans identifiants, sans schéma réseau et sans aide. L’objectif est de trouver la porte avant que quelqu’un qui ne vous rend pas de comptes ne la trouve. Voici un tour d’horizon de ce que ces tests révèlent, de la façon dont nous le mettons au jour et de ce qu’il faut corriger en premier.

Points clés

• Les tests d’intrusion sur le réseau externe attaquent vos actifs exposés sur internet sans accès préalable, afin de repérer les points d’entrée qu’un attaquant vise en premier.
• Les constats à plus fort impact sont généralement banals: panneaux d’administration exposés, appliances VPN et pare-feu non corrigées, et identifiants par défaut ou réutilisés.
• La découverte de la surface d’attaque représente la moitié de la valeur. La plupart des organisations ne peuvent pas énumérer chaque hôte qu’elles exposent, et c’est par les oubliés que nous entrons.
• Les équipements de périphérie comme les VPN, les pare-feu et les passerelles de messagerie sont des cibles de choix, car une seule faille non authentifiée peut livrer tout le périmètre.
• Les correctifs sont volontairement ennuyeux: réduire la surface exposée, corriger vite les équipements de périphérie, supprimer les identifiants par défaut et exiger le MFA sur tout ce qui est exposé sur internet.

Qu’est-ce qu’un test d’intrusion sur le réseau externe?

Un test d’intrusion sur le réseau externe est une attaque contrôlée contre tout ce que votre organisation expose à l’internet public: serveurs web, serveurs de messagerie, passerelles VPN, pare-feu, services d’accès distant, DNS, et tout autre port qu’un tiers peut atteindre. Le testeur part du fauteuil d’un attaquant, en général avec pour seule information le nom de votre entreprise ou une liste de plages d’IP et de domaines.

Il répond à une question brutale. Si un inconnu motivé s’en prenait à nous aujourd’hui, pourrait-il prendre pied depuis l’extérieur? C’est une question différente de celle que pose un test interne. Le travail interne suppose que l’attaquant est déjà entré et mesure jusqu’où il progresse. Le travail externe porte sur le périmètre, et le périmètre est plus vaste et plus désordonné que la plupart des équipes ne le croient.

On confond cela avec un scan de vulnérabilités. À tort. Un scan lance un outil et imprime un rapport. Un test d’intrusion utilise cette sortie comme point de départ, puis un humain la valide, enchaîne les constats et les exploite pour prouver un impact réel. Les scanners sont bruyants et aveugles au contexte. L’un signalera un paramètre TLS de gravité moyenne et passera tout droit devant le panneau d’administration qui accepte admin/admin, parce que se connecter n’est pas quelque chose qu’un scanner tentera vraiment.

Comment cartographier la surface d’attaque externe?

La découverte vient en premier, et c’est là que se cache une part étonnante de la valeur. Avant de toucher à quoi que ce soit, nous construisons l’image la plus complète possible de ce que vous exposez. La liste dans le périmètre qu’un client nous remet est rarement la liste complète de ce qu’il fait réellement tourner en ligne.

Nous commençons par de la reconnaissance passive pour rester discrets: journaux de transparence des certificats, enregistrements DNS, données WHOIS et moteurs de recherche qui indexent les services exposés. La transparence des certificats est ce vers quoi je me tourne en premier. Chaque certificat TLS émis par une entreprise est journalisé publiquement, ce qui laisse fuiter des sous-domaines que personne ne voulait annoncer – les noms d’hôtes dev, uat et vpn-test qui n’étaient jamais censés être trouvables.

# Subdomain enumeration from multiple passive sources
subfinder -d acme-corp.com -all -silent | tee subs.txt

# Resolve, then probe which ones are actually live
cat subs.txt | dnsx -silent -a -resp | httpx -silent -title -status-code -tech-detect

Ensuite, nous passons à l’actif: scan des ports sur les hôtes résolus et prise d’empreinte de ce qui répond. Nous ne comptons pas seulement les ports ouverts. Nous traquons les intéressants. Rien n’aiguise autant l’attention d’un testeur que 3389 (RDP), 445 (SMB) ou un port de base de données qui répond directement sur internet.

# Fast full-range TCP sweep, then service/version detection on the hits
nmap -p- --min-rate 2000 -oA sweep 203.0.113.0/24
nmap -sV -sC -p 22,443,3389,8443 -oA services 203.0.113.10

Ce qui en ressort, c’est un inventaire vivant: noms d’hôtes, IP, ports ouverts, logiciels en cours d’exécution, versions. Cet inventaire surprend régulièrement ceux qui ont commandé le test. Nous avons remis à des équipes une liste où une bonne partie des hôtes étaient des choses dont leur équipe de sécurité n’avait jamais entendu parler, montées par un développeur ou un prestataire marketing et laissées en marche, lumières allumées.

Que trouve réellement un test externe?

Voici l’inventaire honnête de ce qui atterrit en première page de nos rapports, à peu près dans l’ordre où cela compte.

Services exposés et interfaces d’administration

Le constat sérieux le plus courant est quelque chose qui n’aurait jamais dû être exposé sur internet. Consoles de gestion. Tableaux de bord CI comme Jenkins. Ports de base de données. Serveurs d’API Kubernetes. Instances Elasticsearch et Redis posées là sans authentification – et oui, un Redis ouvert signifie souvent une rapide connexion redis-cli et un regard sur tout ce qui y est mis en cache. Panneaux d’administration d’imprimantes et d’objets IoT. Environnements de préproduction qui reflètent la production mais en sautent les contrôles. Si cela écoute sur une IP publique et que c’était conçu pour un usage interne, nous le documentons.

Équipements de périphérie non corrigés

Les concentrateurs VPN, les pare-feu et les passerelles de messagerie sont exactement là où un attaquant externe veut se trouver, et ils vieillissent mal. Ils se tiennent pile sur la frontière. Ils font tourner des logiciels que vous ne pouvez souvent pas inspecter. Et un seul bug de pré-authentification dans l’un d’eux peut déposer un attaquant directement sur le réseau interne. Des failles critiques non authentifiées dans de grands produits VPN et pare-feu ont figuré parmi les bugs les plus massivement exploités de ces dernières années, précisément parce qu’ils sont exposés sur internet par conception et lents à corriger. Quand nous repérons un équipement de périphérie exécutant une version avec un exploit public connu, cela remonte en tête du rapport – et cela s’accompagne d’un appel téléphonique.

Identifiants par défaut et faibles

Les identifiants par défaut refusent de mourir. Le problème a même sa propre classe de faiblesse, CWE-1392, utilisation d’identifiants par défaut, et nous trouvons encore admin/admin, admin/password et des valeurs par défaut de fournisseurs sur du matériel déployé à la hâte et jamais revisité. Juste derrière vient la réutilisation d’identifiants – des mots de passe grillés dans d’anciennes fuites de tiers qui ouvrent encore votre VPN ou votre webmail. Nous testons les surfaces de connexion découvertes contre des listes soigneusement dérivées de fuites, prudemment et avec limitation de débit, car un attaquant qui lance un password spraying (MITRE ATT&CK T1110.003) se moque d’une politique de verrouillage que vous n’avez jamais configurée.

Absence de MFA sur l’accès distant

Un portail VPN ou Outlook Web Access protégé par un simple mot de passe n’est qu’à un identifiant de la compromission. Le spraying combiné à l’absence de MFA est l’un des chemins les plus fiables vers une organisation que nous rencontrions, et il ne demande aucun code d’exploitation. Si cela donne sur internet et ouvre une porte vers quoi que ce soit d’interne, il faut un deuxième facteur. Point final.

Fuites d’information et mauvaises configurations

Pages d’erreur verbeuses. Répertoires .git exposés. Listings de répertoires. Fichiers de sauvegarde laissés à la racine web. Noms d’hôtes internes qui filtrent à travers les en-têtes HTTP. Pris isolément, cela paraît trivial. Enchaînés ensemble, ils tendent à l’attaquant une carte – et parfois du code source ou des identifiants sans détour.

Pourquoi un seul port ouvert compte-t-il?

Parce que le périmètre est une chaîne, et qu’un attaquant n’a besoin que d’un seul maillon qui tienne. Regardez comment cela se passe. Un sous-domaine oublié pointe vers une application web non corrigée. L’application laisse fuiter votre format interne de noms d’utilisateur. Ce format alimente un password spraying contre le VPN, et le VPN n’a pas de MFA. Il y a désormais un point d’appui à l’intérieur, et le test externe vient de donner l’avant-première d’une compromission au ralenti.

Aucune de ces étapes n’a eu besoin d’un zero-day. C’est le point que nous martelons à nos clients. Vous avez bien plus de chances d’être compromis par une pile d’expositions ordinaires et corrigeables que par une attaque exotique et inédite. Les tests d’intrusion sur le réseau externe existent pour trouver cette pile tant que c’est encore votre problème, à régler tranquillement.

Comment prévenir ces constats?

Les remèdes sont peu spectaculaires, ce qui est une bonne nouvelle, car peu spectaculaire signifie atteignable.

• Réduisez la surface. Chaque service sur une IP publique devrait avoir une raison documentée d’être là. Sinon, retirez-le d’internet ou placez-le derrière le VPN. Personne n’attaque un port qui n’est pas ouvert.
• Tenez un inventaire d’actifs réellement exact. Vous ne pouvez pas défendre ce que vous ignorez posséder. Maintenez une liste vivante des actifs exposés sur internet et rapprochez-la régulièrement, idéalement au moyen d’une découverte externe automatisée qui mène la même reconnaissance qu’un attaquant.
• Corrigez les équipements de périphérie en voie rapide. Les VPN, les pare-feu et les passerelles de messagerie méritent leur propre procédure accélérée. Quand un fournisseur livre un correctif pour une faille non authentifiée dans l’un d’eux, comptez en jours, pas en semaines.
• Supprimez les identifiants par défaut et imposez le MFA. Changez chaque valeur par défaut au déploiement, bloquez les mots de passe réutilisés et compromis, et exigez l’authentification multifacteur sur chaque surface d’accès distant et d’administration. Ce seul contrôle neutralise une grande part de ce que nous exploitons.
• Retestez après avoir changé les choses. Un périmètre n’est pas statique. De nouveaux services apparaissent, les enregistrements DNS bougent, les appliances prennent du retard. Un test ponctuel est un instantané, pas une garantie.

Comment CyberXplore vous aide

Notre service de test d’intrusion sur le réseau externe fait exactement ce que décrit cet article. Nous cartographions l’intégralité de votre empreinte exposée sur internet, y compris les actifs dont vous ignoriez l’exposition, puis nous validons et exploitons prudemment ce que nous trouvons pour montrer un impact réel plutôt qu’un mur de bruit de scanner. Vous obtenez un rapport priorisé qui sépare les éléments à corriger aujourd’hui du risque de fond, avec des étapes de reproduction claires sur lesquelles vos ingénieurs peuvent agir, et un nouveau test pour confirmer que les trous sont bel et bien refermés. Si vous voulez voir ce qu’un véritable attaquant voit en regardant votre périmètre, demandez un devis et nous en définirons le cadre avec vous.

FAQ

En quoi un test d’intrusion sur le réseau externe diffère-t-il d’un scan de vulnérabilités?

Un scan de vulnérabilités est automatisé et recrache une liste de problèmes potentiels, dont beaucoup de faux positifs, sans preuve que quoi que ce soit soit exploitable. Un test d’intrusion sur le réseau externe se sert du scan comme d’une entrée, puis un humain valide les constats, les enchaîne et démontre en toute sécurité un impact réel. Le scan vous dit ce qui pourrait clocher. Le test prouve ce qu’un attaquant pourrait réellement faire.

Combien de temps dure un test d’intrusion sur le réseau externe?

Pour une empreinte externe typique de petite à moyenne taille, comptez environ une à deux semaines de tests actifs plus la rédaction du rapport, même si cela évolue avec le nombre d’hôtes et de services actifs dans le périmètre. C’est la découverte qui varie le plus, car une surface d’attaque vaste ou tentaculaire prend plus de temps à cartographier à fond. Nous fixons le calendrier en fonction de votre nombre réel d’actifs plutôt qu’au jugé.

Le test perturbera-t-il nos systèmes de production?

Le test se déroule selon des règles d’engagement convenues d’avance. Nous évitons les techniques de déni de service, limitons le débit de tout ce qui touche à l’authentification et nous coordonnons sur les systèmes sensibles. La grande majorité du travail externe consiste en une observation attentive et une validation contrôlée, et tout ce qui présente un réel potentiel de perturbation n’est exécuté qu’avec un accord explicite.

À quelle fréquence devrions-nous réaliser des tests d’intrusion sur le réseau externe?

Au moins une fois par an, et après tout changement important de votre environnement exposé sur internet – un nouveau lancement de produit, une migration, une fusion. Beaucoup d’organisations les réalisent aussi pour satisfaire des exigences de conformité comme PCI DSS ou SOC 2. Parce que les périmètres dérivent, les équipes dont l’empreinte évolue vite tirent profit de tests plus fréquents ou d’une surveillance externe continue de la surface d’attaque entre deux engagements complets.

Que recevons-nous à la fin de la mission?

Un rapport qui s’ouvre sur une synthèse pour la direction et une liste priorisée de constats classés par risque réel, chacun accompagné de preuves claires, d’étapes de reproduction et de conseils de remédiation. Nous séparons les éléments urgents du durcissement de moindre priorité, afin que votre équipe sache exactement par quoi commencer. Nous proposons aussi un nouveau test après remédiation pour confirmer que les problèmes sont réellement refermés et pas seulement signalés.