Du scan à la preuve : comment SunuProbe et SunuExploit valident un risque sans faux positif

Trouver une faille potentielle et prouver qu'elle est réellement exploitable sont deux métiers différents. Voici comment nos deux outils s'articulent — et pourquoi un simple « match CVE » ne suffit jamais à conclure.

18 octobre 2026 · Équipe SunuCyberSecurity

Source : code des modules SunuProbe et SunuExploit, lu directement sur notre backend — pas une description marketing

Un scanner automatisé peut dire « cette version de ce service correspond à une CVE connue ». C'est une information utile, mais c'est une hypothèse, pas une preuve : la version annoncée par un bandeau de service n'est pas toujours exacte, un correctif peut avoir été appliqué sans changer de numéro de version, et certaines CVE ne sont exploitables que dans des conditions précises. Sur ce point, deux de nos modules sont complémentaires et volontairement séparés : SunuProbe cartographie, SunuExploit confirme — sous autorisation, et seulement là où la confirmation est réellement implémentée.

SunuProbe : cartographier avant de juger

SunuProbe découvre les hôtes et les services actifs sur un réseau, à partir d'une ou plusieurs plages CIDR — jusqu'à une plage /16 en une seule mission, soit potentiellement des dizaines de milliers d'adresses. L'objectif n'est pas de deviner si tel hôte est vulnérable, mais de produire un inventaire fiable : quels appareils répondent, quels ports sont ouverts, quels services et quelles versions s'annoncent. C'est cet inventaire qui alimente ensuite le rapprochement avec les bases de vulnérabilités connues (CVE) — l'étape qui produit des candidats, pas des verdicts.

Chaque appareil découvert devient un nœud documenté — adresse, ports ouverts, services identifiés — avant toute tentative de qualification du risque.

Pourquoi un « match CVE » ne suffit pas

Un rapprochement automatique entre une version de service et une base CVE produit mécaniquement des faux positifs : bannière de version imprécise, correctif de sécurité appliqué hors cycle, condition d'exploitation (configuration, droits, exposition réseau) non remplie. Livrer ce genre de candidat tel quel à une équipe technique, sans distinction entre ce qui est confirmé et ce qui est probable, use la confiance dans le rapport entier — et le risque, c'est qu'une vraie faille, perdue dans la liste, finisse elle aussi ignorée. C'est le rôle de SunuExploit : ne qualifier de « vulnérable » que ce qui a été vérifié par une tentative réelle et contrôlée.

SunuExploit : la validation, pas la démonstration

SunuExploit s'appuie sur Metasploit, le framework de test d'intrusion de référence du secteur — pas un moteur d'exploitation maison non audité. Mais il ne couvre, aujourd'hui, que trois marques d'équipements réseau : MikroTik, Cisco et Fortinet. Huawei et Juniper sont prévus mais pas encore implémentés. Ce n'est pas un bouton « pirater n'importe quoi » : c'est un module volontairement restreint à ce qui a été testé et validé en interne, et il le dit — une cible hors périmètre reçoit l'état « non implémenté », jamais un verdict inventé.

L'autorisation n'est pas une case à cocher

Avant tout lancement, SunuExploit exige une déclaration structurée : nom du client, référence de la mission, nom et contact de la personne qui autorise le test. Les quatre champs sont obligatoires — leur absence bloque techniquement le lancement, ce n'est pas une mention en bas de page qu'on peut ignorer. C'est la même logique que pour un test d'intrusion classique mené par un humain : pas d'autorisation tracée, pas de test.

Deux leçons d'ingénierie, sans client ni incident à citer

Fin septembre 2026, en travaillant sur SunuExploit, nous avons identifié une faille de sécurité non corrigée dans une bibliothèque tierce dont le module dépend pour piloter Metasploit — une injection possible via le champ d'adresse cible, sans correctif disponible côté éditeur de la bibliothèque à cette date. Plutôt que d'attendre un correctif hypothétique, nous avons ajouté notre propre validation stricte du format d'adresse en amont, pour bloquer toute tentative d'injection avant qu'elle n'atteigne la bibliothèque concernée.

Deuxième leçon, plus discrète : pour décider qu'une cible est injoignable plutôt que vulnérable, le module analyse la sortie texte de Metasploit à la recherche de motifs d'échec de connexion. Un équipement Cisco en particulier renvoie un message contenant littéralement le mot « timeout » dans le nom d'un de ses propres paramètres de configuration — sans rapport avec une vraie coupure réseau. Une détection naïve aurait classé ce cas « injoignable » à tort. Le motif de détection a été resserré précisément pour éviter ce faux négatif.

Quatre états, jamais un verdict binaire

Chaque tentative de validation se termine sur un état parmi quatre, jamais un simple « oui/non » :

• Vulnérabilité confirmée — la tentative a réellement réussi sur la cible.
• Non vulnérable — la cible a résisté à la tentative.
• Non implémenté — la marque de l'équipement n'est pas (encore) couverte par SunuExploit.
• Inconclusif — la connexion a échoué ou l'information disponible ne permet pas de trancher, sans qu'un verdict soit forcé.

Ce dernier état, « inconclusif », est volontaire : mieux vaut dire honnêtement qu'on ne sait pas que de deviner un résultat optimiste pour remplir une case du rapport.

Méthodologie

Capacités décrites à partir du code source réel des modules SunuProbe et SunuExploit (backend SunuCyberSecurity), lu et vérifié le 18 octobre 2026 — périmètre des marques supportées, champs d'autorisation obligatoires et états de résultat exacts tels qu'implémentés à cette date, susceptibles d'évoluer. Aucun client ni mission spécifique n'est mentionné dans cet article.

À lire aussi

Mettez ces notions en pratique

Un scan gratuit, en quelques minutes, sans carte bancaire.