Ryan Bouchou

DAV : reconnaissance en Détection et Analyse de Vulnérabilité

Properties2
tagssecurite-web, pentest
aliasesDAV, Reconnaissance en Détection et Analyse de Vulnérabilité

10 min de lecture

Reconnaissance en Détection et Analyse de Vulnérabilité

Note de synthèse

Ce document propose une refonte structurelle de la phase de reconnaissance. Il vise à dépasser l’approche « outillage-centrée » (tool-centric) pour exposer la logique profonde des protocoles (TCP/IP, SMB, RPC), des surfaces d’exposition et des signaux exploitables. La reconnaissance n’est pas une simple énumération technique, mais un raisonnement progressif sur des systèmes hétérogènes, leurs frontières de confiance et leurs invariants techniques. L’objectif est de transformer une « boîte noire » en un modèle mental systémique.

1. La reconnaissance comme discipline épistémique

La reconnaissance ne constitue pas une phase préliminaire au sens faible, mais une activité épistémique à part entière. Elle vise à réduire l’entropie du système cible pour transformer l’inconnu en un modèle opérationnel cohérent. Contrairement à une idée reçue, la reconnaissance ne cherche pas d’abord des failles (vulnerabilities) ; elle cherche des structures et des invariants. Les vulnérabilités n’émergent qu’en second ordre, comme conséquence de choix architecturaux, de dettes techniques ou de désalignements entre l’usage prévu et l’implémentation réelle.

On distingue classiquement reconnaissance passive (OSINT, écoute sans interaction) et active (interaction directe avec la cible), mais cette dichotomie est aujourd’hui insuffisante. La réalité opérationnelle est celle d’une reconnaissance sous contrainte de discrétion (OPSEC).

  • La furtivité absolue est un mythe : tout paquet envoyé modifie l’état du réseau et génère des logs.
  • L’objectif est le blending in : il s’agit de noyer son signal dans le bruit de fond (background noise) du réseau (scans opportunistes, télémétrie, bots) pour ne pas déclencher les seuils d’alerte des SOC/SIEM.

2. ICMP, traceroute et la topologie implicite

ICMP (Internet Control Message Protocol) n’est pas un simple utilitaire de diagnostic (« ping »), mais le plan de contrôle de la couche 3 (Network). Si les messages Echo Request (Type 8) et Echo Reply (Type 0) sont connus, ce sont les messages d’erreur qui offrent la plus haute valeur informative pour la cartographie :

  • Time Exceeded (Type 11) : base du traceroute.
  • Destination Unreachable (Type 3) : crucial pour inférer des règles de filtrage (firewalling).

La logique profonde du traceroute : Le traceroute n’est pas une commande magique, c’est une méthode d’inférence topologique exploitant le champ TTL (Time To Live) de l’en-tête IP. En incrémentant le TTL de 1 à n, l’attaquant force chaque routeur intermédiaire à « tuer » le paquet et à signaler sa propre existence via un message ICMP Time Exceeded.

  • Interprétation des silences : un saut muet (* * *) n’indique pas forcément un arrêt, mais souvent un équipement (Firewall, Load Balancer) configuré pour dropper silencieusement les paquets ICMP sortants ou filtrer les paquets entrants spécifiques.
  • Asymétrie de routage : un traceroute asymétrique révèle que le chemin aller diffère du chemin retour. Cela impacte directement la fiabilité des scans TCP (gestion d’état) et la détection d’IDS qui ne verraient qu’une moitié du flux.

3. TCP, ICMP et la sémantique des scans

Les scans de ports ne sont pas des opérations binaires (ouvert/fermé). Ils reposent sur l’analyse fine de la machine à états finis du protocole TCP (RFC 793). Chaque réponse (ou absence de réponse) est un signal conditionné par la pile TCP du noyau, les équipements intermédiaires et les politiques de filtrage.

Analyse comparée des techniques

Type de scanMécanismeSémantique et détectabilité
TCP ConnectHandshake complet (SYN → SYN/ACK → ACK)Fiable mais bruyant. L’application cible reçoit une connexion valide, la logue, puis l’attaquant la ferme (RST). Laisse des traces applicatives.
SYN ScanHandshake incomplet (SYN → SYN/ACK → RST)Standard de facto. N’atteint pas la couche application (pas de logs http/ssh), mais visible par tout IDS/Firewall réseau. Rapide et efficace.
FIN / NULL / XmasEnvoi de flags illogiques (e.g. FIN sans connexion)Diagnostique. Exploite le fait que les standards imposent une réponse RST pour un port fermé et le silence pour un port ouvert. Efficace pour contourner certains firewalls stateless, mais inutile contre les OS Windows modernes.
ACK ScanEnvoi de paquets avec flag ACKCartographie du filtrage. Ne détecte pas les ports ouverts, mais distingue les ports filtered (pas de réponse) des ports unfiltered (réponse RST). Sert à mapper les règles du firewall.

Note sur la modernité

Dans un contexte moderne, la question n’est plus « suis-je invisible ? », mais « comment mon scan est-il classifié ? ». Un scan lent et distribué peut passer sous les seuils de détection volumétrique, tandis qu’un scan rapide sera immédiatement bloqué (shunned).

4. Nmap comme moteur de raisonnement

nmap ne doit pas être vu comme un simple scanner, mais comme un framework d’exploration réseau scriptable. Sa puissance réside dans la corrélation : il croise les délais de réponse (RTT), l’analyse de séquences TCP (ISN sampling) et les réponses applicatives pour déduire l’OS et les services.

L’apport du NSE (Nmap Scripting Engine) : Les scripts .nse (écrits en Lua) transforment Nmap en outil d’interaction sémantique. Ils ne se contentent pas de vérifier un port, ils « parlent » le protocole.

  • Ils interrogent des comportements attendus (e.g. http-methods).
  • Ils testent des invariants protocolaires.
  • Ils révèlent des écarts de configuration.
  • Exemple : un script peut détecter une vulnérabilité SSL Heartbleed non pas en exploitant la faille, mais en vérifiant la réponse à une requête malformée spécifique.

5. SMB, authentification et architecture

SMB (Server Message Block) est souvent mal compris car réduit au partage de fichiers. En réalité, c’est un protocole de couche Application/Présentation complexe qui transporte, entre autres, le protocole MSRPC (Microsoft Remote Procedure Call).

Analyse du cas pratique (lab)

nmap -p 445 --script smb-brute -oX scan_smb_scripted 192.168.122.100
  • Analyse : le script smb-brute tente de valider des couples user:password. Une réussite ici valide l’étape de Session Setup du protocole SMB.
  • Nuance critique : avoir des credentials valides ne signifie pas avoir accès aux fichiers. Cela signifie que l’authentification est réussie. L’autorisation (accès aux partages C$, ADMIN$) est une étape ultérieure.
# Tentative erronée
smbclient //192.168.122.100//microsoft-ds -N -p 445 -U msfadmin
  • L’erreur : microsoft-ds n’est pas un nom de partage, c’est le nom du service associé au port 445 dans /etc/services. Cette commande échoue logiquement (« Tree connect failed ») car la ressource n’existe pas.
# Énumération correcte
smbclient -L //192.168.122.100 -U msfadmin
  • Résultat : l’option -L (List) interroge le service IPC$ (Inter-Process Communication) pour lister les partages disponibles.
  • Interprétation :
    • IPC$ : présence essentielle. C’est un tube nommé (named pipe) qui permet les appels RPC anonymes ou authentifiés (énumération des utilisateurs, groupes, politiques).
    • Samba 3.0.20-Debian : cette bannière de version est une information critique (Information Disclosure). Elle indique un OS Legacy et une version logicielle connue pour la faille critique « Username Map Script » (CVE-2007-2447).

Pivot d'identité

Une authentification SMB valide est un point de bascule. Même sans accès direct aux fichiers, elle permet souvent l’énumération exhaustive des utilisateurs (via SAMR pipe), le password spraying latéral, ou l’accès SSH si les credentials sont réutilisés (password reuse).

6. enum4linux et l’énumération structurelle

enum4linux est un wrapper Perl autour des outils de la suite Samba (smbclient, rpcclient, net, nmblookup). Son intérêt est d’automatiser l’extraction d’informations structurelles via RPC.

enum4linux -a 192.168.122.100

La valeur ajoutée réside dans l’exploitation des RIDs (Relative IDs).

  • En Windows/Samba, chaque objet (utilisateur, groupe) possède un SID. La fin du SID est le RID.
  • RID Cycling : même si on ne peut pas lister les utilisateurs directement, on peut interroger le système : « qui est le RID 500 ? qui est le 501 ? ». Le système répond souvent par le nom d’utilisateur, contournant ainsi les restrictions de listage simple. C’est une méthode puissante de cartographie identitaire.

7. theHarvester et la surface d’attaque externe

theHarvester opère sur un plan différent : la reconnaissance passive hors périmètre. Il n’interroge pas la cible, mais ce que le monde sait de la cible. Il agrège des sources OSINT (Open Source Intelligence) :

  • registres DNS (crt.sh, bufferover) ;
  • moteurs de recherche (Google Dorks, Bing) ;
  • bases de données de fuites (LinkedIn, PGP servers).

Logique d’usage : les emails collectés (format : prenom.nom@cible.com) définissent la nomenclature des identifiants pour les attaques par force brute (SSH/SMB). Les sous-domaines découverts élargissent la surface d’attaque technique (souvent des serveurs de dev ou de staging oubliés).

8. Metasploit (framework) comme outil d’analyse

Metasploit (MSF) est souvent réduit à l’exécution d’exploits. Or, sa section auxiliary/ est l’une des plus riches bibliothèques de reconnaissance active au monde.

  • Philosophie modulaire : MSF permet de configurer finement les paramètres du protocole (timeouts, versions, threads).
  • Validation d’hypothèse : contrairement à un scanner généraliste, un module auxiliaire MSF répond à une question précise (e.g. auxiliary/scanner/ssh/ssh_login pour tester des credentials, ou auxiliary/scanner/http/http_version pour identifier un serveur web précis). Il sert à confirmer une intuition née lors de la phase Nmap.

9. Synthèse : reconnaissance, bruit et modernité

Le défi de l’ingénieur en cybersécurité n’est plus la pénurie d’information, mais sa saturation. Les réseaux modernes sont bruités. Une reconnaissance efficace ne consiste pas à tout scanner, mais à :

  1. Identifier les frontières de confiance (DMZ, interne, partenaires).
  2. Corréler les signaux faibles (un port filtré + un TTL spécifique = un type de firewall).
  3. Maintenir la cohérence temporelle (ne pas scanner agressivement aux heures de pointe si l’on veut rester discret).

QUOTE

Reconnaître, ce n’est pas tout voir. C’est comprendre ce qui est structurant pour le système cible. C’est transformer des données brutes (IP, ports, bannières) en intelligence exploitable (chemins d’attaque, dettes techniques, mauvaises configurations).

10. Fuzzing web et découverte de ressources non liées

Le directory fuzzing (ou énumération de contenu) est une réponse aux limites des robots d’indexation classiques (crawlers/spiders). Là où un crawler suit des liens existants, le fuzzer attaque l’espace de nommage de l’application pour révéler des ressources orphelines : fichiers de configuration, sauvegardes (.bak), panels d’administration ou endpoints d’API non documentés. Cette approche brise le principe de « sécurité par l’obscurité ».

Comme le souligne la méthodologie exposée sur The Hacker Recipes, l’efficacité de cette phase repose sur trois piliers : la pertinence des dictionnaires (wordlists), la vitesse d’exécution et, surtout, la capacité de filtrage.

  • L’évolution de l’outillage : si des outils historiques comme dirb ou DirBuster ont posé les bases, ils sont aujourd’hui souvent limités par leur gestion des threads et leur rigidité. L’état de l’art (tel que ffuf ou gobuster, écrits en Go) privilégie la concurrence massive et la flexibilité.

  • La logique de calibrage : la difficulté n’est pas d’envoyer des requêtes, mais d’interpréter les réponses. Un serveur peut répondre 200 OK à toutes les requêtes (soft 404), rendant un scan naïf inutile.

  • ffuf (Fuzz Faster U Fool) se distingue ici par ses capacités de filtrage granulaires. Il permet à l’analyste de supprimer le bruit en filtrant non seulement sur le code HTTP, mais aussi sur la taille de la réponse (-fs), le nombre de mots (-fw) ou de lignes (-fl).

  • Contextualisation : le fuzzing aveugle est bruyant et inefficace. Il doit être contextuel : identifier la technologie (via Wappalyzer ou les en-têtes) pour cibler les extensions pertinentes (.php, .jsp, .aspx) et utiliser des wordlists adaptées (e.g. SecLists).

Exemple de raisonnement via ffuf pour nettoyer le bruit d’une wildcard response :

# 1. Scan initial (trop de faux positifs)
ffuf -w wordlist.txt -u http://cible.com/FUZZ
 
# 2. Analyse : On remarque que toutes les pages inexistantes font exactement 42 mots.
# 3. Scan calibré (filtrage des réponses de 42 mots)
ffuf -w wordlist.txt -u http://cible.com/FUZZ -fw 42

IMPORTANT

Le fuzzing web ne cherche pas seulement des dossiers (/admin). Il doit être récursif et itératif pour découvrir des vecteurs d’attaque critiques comme des fichiers de logs exposés ou des clés SSH oubliées dans un dossier .git mal protégé.

Ressources et références techniques

Vue Graphique

Liens retour