Skip to main content

Chapitre 3.1 Quiz - Reconnaissance, Balayage et Enumeration

Mode Quiz - Toutes les reponses sont masquees. Tentez chaque question avant de reveler la reponse.

Question 1

Vous executez nmap -sS -T4 -p- 10.10.10.50 et observez que le port 445 est filtered, mais en executant nmap -sA -p 445 10.10.10.50 il apparait comme unfiltered. Que vous indique cela sur la regle pare-feu proteg eant le port 445, et quelle est votre prochaine etape ?

Reveler la reponse

Reponse : Le pare-feu utilise un filtrage de paquets sans etat - il bloque les paquets SYN entrants (tentatives de connexion initiales) mais ne suit pas l'etat des connexions, donc les paquets ACK passent.

Explication :

  • -sS (scan SYN) : envoie un TCP SYN - le pare-feu le rejette - filtered
  • -sA (scan ACK) : envoie un TCP ACK - le pare-feu n'a pas de regle avec etat pour le bloquer - le paquet atteint l'hote - l'hote repond avec RST - unfiltered

Un pare-feu avec etat suit l'etat des connexions. Il bloquerait egalement le paquet ACK car aucun echange SYN-ACK correspondant n'existe dans sa table d'etat, retournant filtered pour les scans ACK aussi. Une ACL sans etat ou un simple filtre de paquets ne correspond qu'aux champs statiques (flags, port, IP) - un ACK vers le port 445 sans entree d'etat correspondante passerait quand meme.

Prochaine etape : Utiliser l'usurpation de port source ou des tentatives de connexion basees sur ACK pour sonder a travers le filtre sans etat :

# Usurpation de port source (certains pare-feux sans etat autorisent le trafic du port 53 ou 80)
nmap -sS --source-port 53 -p 445 10.10.10.50

# Sonde ACK hping3 pour confirmer l'accessibilite SMB
hping3 -A -p 445 10.10.10.50      # Envoyer ACK au port 445

# Si les sondes ACK recoivent RST = l'hote est actif et le port est accessible au L3
# Essayer SYN avec faux port source pour contourner la regle sans etat :
hping3 -S -p 445 --sport 53 10.10.10.50

Correctif defensif : Remplacer l'ACL sans etat par une regle de pare-feu avec etat (iptables -m state --state NEW ou equivalent). Une regle correcte : iptables -A INPUT -p tcp --dport 445 -m state --state NEW -j DROP.

MITRE ATT&CK : T1595.001 (Balayage actif : Balayage de ports)

Question 2

Une tentative de transfert de zone contre ns1.target-corp.com reussit et retourne 847 enregistrements. Parmi eux, vous trouvez des entrees comme dev-db01.internal.target-corp.com - 10.50.2.11 et vpn-gateway.target-corp.com - 203.0.113.45. Quelle est la valeur operationnelle immediate de cette sortie, et quels deux enregistrements prioritiseriez-vous pour l'enumeration de suivi ?

Reveler la reponse

Reponse : Le transfert de zone fournit une cartographie complete du reseau interne sans balayage actif - produisant le meme renseignement qu'un scan de plusieurs jours.

Valeur operationnelle :

  • Tous les noms d'hotes internes et leurs IPs - elimine le besoin de force brute de sous-domaines
  • Revele les conventions de nommage (ex. dev-db01 - il existe probablement prod-db01, qa-db01)
  • Expose simultanement l'infrastructure exposee sur Internet (vpn-gateway) et interne (dev-db01)
  • Les anciens noms d'hotes peuvent reveler une infrastructure decommissionnee encore accessible

Deux enregistrements a prioriser :

  1. vpn-gateway.target-corp.com (203.0.113.45) - la passerelle VPN est une cible perimetrique a haute valeur. Enumerer la version du logiciel VPN, le protocole (IPsec/SSL) et tester les CVE connus. Compromettre les identifiants VPN donne un acces au niveau reseau.
# Identifier le logiciel et la version VPN
nmap -sV -p 443,500,4500,1194 203.0.113.45
nmap -p 443 --script ssl-cert,ssl-enum-ciphers 203.0.113.45
# Verifier Pulse Secure, Fortinet, Citrix NetScaler - tous ont eu des CVE critiques
  1. dev-db01.internal.target-corp.com (10.50.2.11) - les bases de donnees en environnements de developpement ont souvent des controles d'acces plus faibles, des identifiants par defaut, ou des versions non corrigees tout en contenant des donnees sensibles.
# Apres acces reseau - enumerer la base de donnees
nmap -sV -p 3306,5432,1433,1521 10.50.2.11   # MySQL, PostgreSQL, MSSQL, Oracle

Correctif defensif : Restreindre allow-transfer dans BIND/named uniquement a l'IP du serveur de noms secondaire autorise. Verifier avec :

dig axfr @ns1.target-corp.com target-corp.com
# Devrait retourner : Transfer failed.

MITRE ATT&CK : T1590.002 (Collecte d'informations reseau : DNS)

Question 3

Vous effectuez un scan Nmap depuis votre machine d'attaque contre une cible disposant d'un IDS Snort avec le preprocesseur portscan active. Quelle combinaison de flags Nmap reduirait le plus votre probabilite de detection, et quel risque residuel demeure ?

Reveler la reponse

Reponse : -sS -T1 --randomize-hosts --data-length 25 -D decoy1,decoy2,ME --source-port 53

Justification par flag :

nmap -sS \\\\                      # Scan SYN - pas de connexions completes, pas de journaux applicatifs
  -T1 \\\\                         # Temporisation furtive - 15s entre les sondes (en dessous des detecteurs de seuil)
  --randomize-hosts \\\\            # Balayage non sequentiel evite les signatures de scan sequentiel
  --data-length 25 \\\\             # Charge utile aleatoire casse les signatures Snort basees sur le contenu
  -D 10.0.0.1,10.0.0.5,ME \\\\     # Les leurres masquent la vraie IP source dans les journaux IDS
  --source-port 53 \\\\             # Le port source 53 peut contourner les pare-feux sans etat
  -n \\\\                           # Pas de resolution DNS (pas de requetes DNS dans les journaux du resolveur)
  -p 22,80,443,3389,445,8080 \\\\  # Limiter aux ports cles - moins de sondes = score d'anomalie plus faible
  10.10.10.0/24

Pourquoi cela fonctionne contre le preprocesseur portscan :

  • Le preprocesseur portscan de Snort se declenche sur un seuil de SYN vers plusieurs ports/hotes dans une fenetre de temps
  • -T1 etale les sondes sur des fenetres suffisamment longues pour rester en dessous du seuil par defaut
  • --randomize-hosts empeche le modele sequentiel que les moteurs portscan reconnaissent
  • Les leurres augmentent le rapport bruit/signal dans les alertes IDS

Risques residuels :

  1. Les IPs leurres doivent etre des hotes actifs - Snort peut filtrer les IPs usurpees par les incoherences TTL ou la validation source
  2. Si la cible execute Zeek, meme les scans T1 sont visibles dans conn.log comme connexions RST uniquement (pas de sessions etablies)
  3. Le port source 53 est trivialement contrarie par tout pare-feu avec etat
  4. Le scan prend des jours en T1 sur un /24 - la fenetre operationnelle peut ne pas le permettre

Ce qu'aucun flag de scan ne peut contrer : Les TAPs physiques alimentant un SIEM avec des analyses comportementales de base. Votre profil de scan deviait du trafic normal quelle que soit la lenteur.

MITRE ATT&CK : T1595.001 (Balayage actif : Balayage de ports)

Question 4

En utilisant uniquement la reconnaissance passive - aucun paquet envoye vers la cible - construisez l'image la plus complete possible de target-corp.com. Listez les cinq sources de donnees specifiques que vous interrogeriez, ce que chacune revele, et la commande CLI pour chacune.

Reveler la reponse

Reponse :

1. Transparence des certificats (crt.sh) - Tous les sous-domaines

curl -s "https://crt.sh/?q=%.target-corp.com&output=json" | \\
  jq -r '.[].name_value' | sed 's/\\\\*\\\\.//g' | sort -u

Revele : Chaque sous-domaine ayant jamais eu un certificat TLS emis - souvent 80%+ de l'inventaire complet de sous-domaines incluant les environnements de staging, developpement et les applications internes.

2. Shodan - Services exposes sur Internet, bannieres, versions de logiciels

shodan search "hostname:target-corp.com" \\
  --fields ip_str,port,product,version,os,org

Revele : Ports ouverts et services sur toutes les IPs exposees sur Internet, versions de logiciels, OS, details de certificats SSL, en-tetes de reponse HTTP - sans envoyer un seul paquet a la cible.

3. Recherche BGP/ASN - Plages IP

curl -s "https://api.bgpview.io/search?query_term=target+corporation" | \\
  jq '.data.asns[].asn' | \\
  xargs -I{} curl -s "https://api.bgpview.io/asn/{}/prefixes" | \\
  jq -r '.data.ipv4_prefixes[].prefix'

Revele : Toutes les plages IP appartenant a l'organisation cible, leur ASN, fournisseurs en amont et relations de peering - definit l'empreinte reseau complete.

4. GitHub / truffleHog - Secrets divulgues et noms d'hotes internes

trufflehog github --org=target-corporation --only-verified --json 2>/dev/null | \\
  jq '{file:.SourceMetadata.Data.Github.file, detector:.DetectorName, raw:.Raw}'

Revele : Cles API, chaines de connexion de bases de donnees, cles privees commitees accidentellement, noms d'hotes/URLs internes references dans les commentaires de code ou fichiers de configuration.

5. DNS + SPF/DMARC - Infrastructure de messagerie et posture de securite email

for record in MX TXT NS SOA; do
    dig +short $record target-corp.com
done
dig +short TXT _dmarc.target-corp.com

Revele : Infrastructure de serveurs de messagerie, services tiers (Salesforce, SendGrid, Google Workspace), niveau d'application DMARC (p=none = hameconnage viable), expediteurs autorises SPF, et identite du serveur de noms.

Sortie combinee : Avant d'envoyer un seul paquet a la cible, vous connaissez leurs plages IP, tous les sous-domaines, les logiciels fonctionnant sur les hotes exposes sur Internet, si leurs developpeurs ont commite des identifiants sur GitHub, et si leur email peut etre usurpe. C'est la base d'un engagement professionnel.

MITRE ATT&CK : T1596 (Recherche dans les bases de donnees techniques ouvertes), T1590 (Collecte d'informations reseau), T1593 (Recherche sur les sites/domaines ouverts)

Fin du Quiz 3.1 - Reconnaissance, Balayage et Enumeration