Recon Pipeline: Come Automatizzare OSINT, Asset Discovery e Vulnerability Scanning #

Una OSINT pipeline è una catena automatizzata di tool che raccoglie informazioni su un target — domini, sottodomini, porte aperte, tecnologie, credenziali esposte, endpoint — prima ancora di toccare l’applicazione con un test attivo.

Nel bug bounty e nei pentest professionali, la ricognizione è la fase che separa chi trova vulnerabilità critiche da chi non trova nulla. I target con programmi maturi sono stati testati da centinaia di ricercatori: le vulnerabilità ovvie sono già state trovate. Le vulnerabilità che restano stanno nella superficie d’attacco che gli altri non hanno cercato — subdomain dimenticati, endpoint legacy, asset che l’azienda non sa di avere.

Una pipeline automatizzata ti permette di coprire sistematicamente quella superficie senza perderti niente.

Vedi anche: osint, reconnaissance, subdomain-enumeration, dns-enumeration, nmap, ffuf, nuclei.

La Differenza tra Recon Passiva e Attiva #

Prima di costruire la pipeline, capisci la distinzione fondamentale:

Recon passiva: raccogli informazioni senza mai toccare direttamente l’infrastruttura del target. Usi fonti terze — motori di ricerca, certificati TLS, dataset pubblici, archivi internet. Il target non vede nessuna request venire da te.

text

Esempio:
→ Consulti crt.sh per trovare i certificati SSL emessi per *.target.com
→ Il target non sa che hai cercato quei certificati
→ Nessun rischio di rilevamento, nessun log sul loro server

Recon attiva: interagisci direttamente con l’infrastruttura del target — mandi richieste DNS, scansioni porte, request HTTP. Puoi essere rilevato nei log.

text

Esempio:
→ Esegui nmap su target.com
→ Il firewall del target vede le tuoi probe
→ Rischio rilevamento — in un bug bounty spesso è permesso,
  in un pentest varia in base alle regole d'ingaggio

Una buona pipeline fa prima tutta la recon passiva, poi passa a quella attiva con la superficie già mappata.

Struttura della Pipeline #

Ecco la sequenza logica che seguono i migliori bug hunter:

text

1. SUBDOMAIN ENUMERATION (passiva)
   → Trova tutti i sottodomini del target

2. DNS RESOLUTION + LIVE CHECK
   → Quali sottodomini risolvono? Quali server sono attivi?

3. PORT SCANNING
   → Quali porte sono aperte su quegli IP?

4. HTTP FINGERPRINTING
   → Screenshot, status code, tecnologie, header

5. CONTENT DISCOVERY
   → Directory, file, endpoint nascosti

6. VULNERABILITY SCANNING
   → Template automatici su tecnologie identificate

7. SECRET / CREDENTIAL SCANNING
   → Chiavi API, token, credenziali esposte

Ogni step alimenta il successivo. Alla fine hai una mappa completa della superficie d’attacco.

Step 1 — Subdomain Enumeration (Passiva) #

L’obiettivo è trovare tutti i sottodomini del target senza mandare nemmeno una request al loro server.

Certificati TLS (crt.sh) #

Ogni certificato SSL emesso per un dominio viene registrato in log pubblici (Certificate Transparency). crt.sh li indicizza tutti.

bash

# Query manuale su crt.sh
curl -s "https://crt.sh/?q=%.target.com&output=json" | \
  python3 -c "import sys,json; [print(x['name_value']) for x in json.load(sys.stdin)]" | \
  sed 's/\*\.//g' | sort -u

# Spesso rivela sottodomini come:
# staging.target.com
# api-internal.target.com
# dev.target.com
# legacy-admin.target.com
# ← questi sono i target più interessanti

Subfinder — Enumeration Passiva Aggregata #

Subfinder interroga decine di fonti in parallelo: VirusTotal, Shodan, Censys, SecurityTrails, crt.sh, DNSDumpster, e molte altre.

bash

# Installazione
go install -v github.com/projectdiscovery/subfinder/v2/cmd/subfinder@latest

# Uso base
subfinder -d target.com -o subdomains.txt

# Con verbosità per vedere da quale fonte arriva ogni subdomain
subfinder -d target.com -v -o subdomains.txt

# Con più fonti (richiede API key per alcune)
subfinder -d target.com -all -o subdomains.txt

# Multiple target da file
subfinder -dL domains.txt -o subdomains.txt

Amass — Deep Passive + Active Enumeration #

Amass è più potente ma più lento. Fa sia recon passiva che attiva (bruteforce DNS, permutazioni).

bash

# Installazione
go install -v github.com/owasp-amass/amass/v4/...@master

# Recon passiva (solo fonti esterne, nessun contatto col target)
amass enum -passive -d target.com -o amass_passive.txt

# Recon attiva (bruteforce + permutazioni — contatta i DNS del target)
amass enum -active -d target.com -o amass_active.txt

# Bruteforce con wordlist
amass enum -brute -d target.com -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt

# Combina tutte le fonti
amass enum -d target.com -active -brute -o amass_all.txt

Altre Fonti Passive da Non Dimenticare #

bash

# Wayback Machine — URL storici indicizzati da internet archive
# Spesso contiene endpoint deprecati ancora attivi
curl -s "http://web.archive.org/cdx/search/cdx?url=*.target.com/*&output=text&fl=original&collapse=urlkey" | \
  sort -u | head -100

# GitHub / GitLab — cerca menzioni del dominio nel codice pubblico
# Tool: github-dorking o manuale
# Cerca: "target.com" in:code site:github.com

# Shodan — trova IP con servizi esposti per un'organizzazione
# Con API key:
shodan search "target.com" --fields ip_str,port,hostnames

# SecurityTrails (API gratuita limitata)
curl -s "https://api.securitytrails.com/v1/domain/target.com/subdomains" \
  -H "APIKEY: TUA_API_KEY" | python3 -m json.tool

Step 2 — DNS Resolution e Live Check #

Hai una lista di centinaia di sottodomini. Molti non risolvono. dnsx e httpx filtrano solo quelli attivi.

bash

# Installazione
go install -v github.com/projectdiscovery/dnsx/cmd/dnsx@latest
go install -v github.com/projectdiscovery/httpx/cmd/httpx@latest

# DNS resolution: quali sottodomini hanno un record A/CNAME?
cat subdomains.txt | dnsx -a -resp -o resolved.txt
# Output: subdomain.target.com [IP]

# HTTP check: quali rispondono su porta 80/443?
cat resolved.txt | httpx -o live_hosts.txt

# Con più informazioni (status code, title, tecnologia)
cat resolved.txt | httpx \
  -status-code \
  -title \
  -tech-detect \
  -content-length \
  -o live_full.txt

# Esempio output:
# https://staging.target.com [200] [Staging Environment] [Laravel,PHP,Nginx]
# https://api-internal.target.com [403] [Forbidden] [Express,Node.js]
# https://dev.target.com [200] [Dev Portal] [WordPress,Apache]

Step 3 — Port Scanning #

Ora che hai gli IP attivi, cerchi porte aperte oltre 80 e 443. Servizi esposti su porte non standard sono spesso non protetti.

bash

# nmap — accurato ma lento
nmap -sV -sC -p- --open -T4 IP_TARGET -oN nmap_full.txt

# nmap su lista di IP
nmap -sV --open -iL ip_list.txt -oN nmap_multi.txt

# masscan — velocissimo per range grandi (richiede root)
masscan -p1-65535 IP_TARGET --rate=1000 -oG masscan_output.txt

# Combinazione: masscan per trovare porte aperte, nmap per i dettagli
masscan -p1-65535 IP_TARGET --rate=1000 | \
  awk '/open/ {print $4}' | \
  xargs -I{} nmap -sV -p {} IP_TARGET

# Porte ad alto valore da controllare sempre:
# 8080, 8443, 8888 → web app alternative (spesso meno protette)
# 9200, 9300 → Elasticsearch (spesso senza auth)
# 27017 → MongoDB (spesso senza auth)
# 6379 → Redis (spesso senza auth)
# 5432 → PostgreSQL
# 3306 → MySQL
# 445 → SMB
# 22 → SSH (versione, banner)

Step 4 — Screenshot e Fingerprinting #

Con centinaia di host attivi, non puoi visitarli tutti manualmente. Gli screenshot automatici ti permettono di fare triage visivo in pochi minuti.

bash

# gowitness — screenshot di massa
go install github.com/sensepost/gowitness@latest

# Screenshot da lista di URL
gowitness file -f live_hosts.txt --screenshot-path ./screenshots/

# Apri il report HTML interattivo
gowitness report serve

# EyeWitness (Python, già presente in Kali)
eyewitness -f live_hosts.txt --web --timeout 10 -d ./eyewitness_report/

# httpx con screenshot integrato
cat live_hosts.txt | httpx -screenshot -o httpx_screenshots/

Quello che cerchi negli screenshot:

Pannelli di login (Grafana, Jenkins, Kibana, phpMyAdmin, Admin panels)
Pagine di errore che rivelano tecnologie e path
Applicazioni di default non configurate
“Index of /” → directory listing
Applicazioni legacy (vecchie versioni visibili nel footer)

Step 5 — Content Discovery #

Ora cerchi path nascosti su ogni host attivo: endpoint admin, file di backup, configurazioni esposte.

bash

# ffuf — il più veloce
ffuf -u "https://target.com/FUZZ" \
  -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt \
  -mc 200,301,302,403 \
  -o ffuf_results.json

# Con estensioni (cerca file di backup, config, ecc.)
ffuf -u "https://target.com/FUZZ" \
  -w /usr/share/seclists/Discovery/Web-Content/raft-medium-files.txt \
  -e .php,.bak,.old,.conf,.env,.log,.sql,.zip,.tar.gz \
  -mc 200,301,302 \
  -o ffuf_files.json

# feroxbuster — ricorsivo
feroxbuster -u "https://target.com" \
  -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt \
  --auto-tune \
  -o feroxbuster_results.txt

# Wordlist specifiche per tecnologia (molto più efficaci di quelle generiche)
# Laravel:
ffuf -u "https://target.com/FUZZ" -w /usr/share/seclists/Discovery/Web-Content/Laravel.txt
# WordPress:
ffuf -u "https://target.com/FUZZ" -w /usr/share/seclists/Discovery/Web-Content/CMS/WordPress.fuzz.txt
# Spring Boot Actuator (endpoint esposti di default):
ffuf -u "https://target.com/FUZZ" -w /usr/share/seclists/Discovery/Web-Content/spring-boot.txt

Step 6 — Vulnerability Scanning con Nuclei #

Nuclei esegue migliaia di template su ogni host — CVE noti, misconfigurazioni, endpoint esposti, pannelli di default.

bash

# Installazione
go install -v github.com/projectdiscovery/nuclei/v3/cmd/nuclei@latest

# Aggiorna i template (fallo sempre prima di usarli)
nuclei -update-templates

# Scan base su lista di host
nuclei -l live_hosts.txt -o nuclei_results.txt

# Solo severity alta e critica
nuclei -l live_hosts.txt -severity high,critical -o nuclei_critical.txt

# Solo CVE
nuclei -l live_hosts.txt -tags cve -o nuclei_cves.txt

# Solo misconfigurazioni e esposizioni
nuclei -l live_hosts.txt -tags misconfig,exposure -o nuclei_misconfig.txt

# Template specifici per tecnologia identificata (es. WordPress)
nuclei -l live_hosts.txt -tags wordpress -o nuclei_wp.txt

# Con rate limiting per non fare troppo rumore
nuclei -l live_hosts.txt -rate-limit 50 -bulk-size 10 -o nuclei_results.txt

Step 7 — Secret Scanning #

Cerca credenziali, chiavi API, token hardcodati nel codice sorgente esposto, nei file JavaScript, nei repository pubblici.

JavaScript Source Analysis #

bash

# getJS — estrae tutti i file JS da un sito
go install github.com/003random/getJS@latest
getJS -url "https://target.com" -output js_files.txt

# Scarica tutti i JS trovati
cat js_files.txt | xargs -I{} curl -s {} -o js_files/{$(echo {} | md5sum | cut -d' ' -f1)}.js

# secretfinder — cerca secret nei file JS
python3 SecretFinder.py -i "https://target.com" -e -o results.html
# Cerca: AWS keys, Stripe keys, Firebase URL, Google API keys, JWT, token...

# trufflehog — cerca secret in URL e file
trufflehog filesystem ./js_files/ --only-verified

Google Dorking per Secret Esposti #

bash

# File di configurazione esposti sul dominio
site:target.com ext:env "DB_PASSWORD"
site:target.com ext:json "api_key"
site:target.com ext:xml "password"
site:target.com "Index of" ".env"
site:target.com filetype:log

# GitHub dorking per secret nel codice pubblico
site:github.com "target.com" "api_key"
site:github.com "target.com" "password"
site:github.com "target.com" "secret"
site:github.com "target.com" "DB_HOST"

# Pastebin / paste sites
site:pastebin.com "target.com"
site:gist.github.com "target.com" "password"

GitHub / GitLab Automated Search #

bash

# trufflehog su repository GitHub dell'organizzazione
trufflehog github --org=target-org --only-verified

# gitleaks su un repository specifico
gitleaks detect --source ./cloned-repo/ --report-format json --report-path gitleaks_report.json

# gitrob — enumera repository pubblici di un'organizzazione
gitrob analyze --organization target-org

Step 8 — Subdomain Takeover Check #

Un sottodominio può puntare a un servizio esterno (GitHub Pages, Heroku, AWS S3, Fastly) che non è più attivo. Se il servizio è stato cancellato ma il record DNS esiste ancora, chiunque può registrare quel servizio e prendere il controllo del sottodominio.

bash

# subjack — check automatico subdomain takeover
go install github.com/haccer/subjack@latest
subjack -w subdomains.txt -t 100 -timeout 30 -o takeover_results.txt -ssl

# nuclei con template takeover
nuclei -l subdomains.txt -tags takeover -o nuclei_takeover.txt

# Segnali manuali da cercare:
# "There isn't a GitHub Pages site here." → GitHub Pages takeover possibile
# "NoSuchBucket" → S3 bucket takeover possibile
# "No such app" → Heroku takeover possibile
# "404 Not Found" su Fastly/CloudFront → CDN takeover possibile

# Vedi: subdomain-takeover per la guida completa

→ subdomain-takeover

Pipeline Automatizzata: Script Completo #

Questo script mette insieme tutti gli step in sequenza. Salvalo come recon.sh e usalo come punto di partenza.

bash

#!/bin/bash
# recon.sh — OSINT Pipeline Completa
# Uso: ./recon.sh target.com

TARGET=$1
OUTPUT_DIR="recon_$TARGET"
mkdir -p $OUTPUT_DIR/{subdomains,screenshots,nuclei,secrets,ports}

echo "[*] Avvio pipeline per: $TARGET"

# STEP 1 — Subdomain enumeration passiva
echo "[+] Subdomain enumeration..."
subfinder -d $TARGET -silent -o $OUTPUT_DIR/subdomains/subfinder.txt
amass enum -passive -d $TARGET -o $OUTPUT_DIR/subdomains/amass.txt 2>/dev/null

# crt.sh
curl -s "https://crt.sh/?q=%25.$TARGET&output=json" 2>/dev/null | \
  python3 -c "import sys,json; [print(x.get('name_value','')) for x in json.load(sys.stdin)]" 2>/dev/null | \
  sed 's/\*\.//g' >> $OUTPUT_DIR/subdomains/crtsh.txt

# Unisci e deduplicа
cat $OUTPUT_DIR/subdomains/*.txt | sort -u > $OUTPUT_DIR/subdomains/all.txt
TOTAL=$(wc -l < $OUTPUT_DIR/subdomains/all.txt)
echo "[+] Trovati $TOTAL sottodomini unici"

# STEP 2 — DNS resolution
echo "[+] DNS resolution..."
cat $OUTPUT_DIR/subdomains/all.txt | \
  dnsx -silent -a -resp -o $OUTPUT_DIR/subdomains/resolved.txt

# STEP 3 — HTTP check
echo "[+] HTTP fingerprinting..."
cat $OUTPUT_DIR/subdomains/resolved.txt | \
  httpx -silent -status-code -title -tech-detect \
  -o $OUTPUT_DIR/live_hosts.txt

# STEP 4 — Screenshot
echo "[+] Screenshot..."
gowitness file -f $OUTPUT_DIR/live_hosts.txt \
  --screenshot-path $OUTPUT_DIR/screenshots/ 2>/dev/null

# STEP 5 — Port scan (solo host attivi, porte comuni)
echo "[+] Port scanning..."
cat $OUTPUT_DIR/subdomains/resolved.txt | \
  awk '{print $2}' | sort -u > $OUTPUT_DIR/ports/ip_list.txt
nmap -iL $OUTPUT_DIR/ports/ip_list.txt \
  -p 80,443,8080,8443,8888,9200,27017,6379,5432,3306,22,445 \
  --open -oN $OUTPUT_DIR/ports/nmap.txt 2>/dev/null

# STEP 6 — Nuclei
echo "[+] Nuclei scanning..."
nuclei -l $OUTPUT_DIR/live_hosts.txt \
  -severity medium,high,critical \
  -silent \
  -o $OUTPUT_DIR/nuclei/results.txt 2>/dev/null

# STEP 7 — Subdomain takeover
echo "[+] Takeover check..."
subjack -w $OUTPUT_DIR/subdomains/all.txt \
  -t 50 -timeout 20 \
  -o $OUTPUT_DIR/takeover.txt -ssl 2>/dev/null

echo ""
echo "[*] DONE. Risultati in: $OUTPUT_DIR/"
echo "[*] Live hosts: $(wc -l < $OUTPUT_DIR/live_hosts.txt)"
echo "[*] Nuclei findings: $(wc -l < $OUTPUT_DIR/nuclei/results.txt)"

Fonti Passive Avanzate #

Oltre ai tool, queste fonti web ti danno informazioni che nessun tool trova automaticamente:

Shodan — motore di ricerca per dispositivi connessi a internet. Cerca l’organizzazione per trovare IP, porte aperte, banner di servizio, certificati.

text

Dork Shodan:
org:"Target Company"
ssl:"target.com"
hostname:"target.com"

Censys — simile a Shodan ma più orientato ai certificati e ai protocolli.

text

Dork Censys:
parsed.names: target.com
autonomous_system.name: "Target Inc"

FOFA — alternativa cinese a Shodan, utile per target che non compaiono su Shodan.

GreyNoise — distingue traffico di scanner da traffico reale. Utile per vedere chi sta già scansionando il target.

Wayback Machine — URL storici. Endpoint rimossi dal sito ma ancora attivi sul server. Parametri dimenticati.

bash

# Estrai tutti gli URL storici di un dominio
curl -s "https://web.archive.org/cdx/search/cdx?url=*.target.com/*&output=text&fl=original&collapse=urlkey" | \
  grep -v "^$" | sort -u > wayback_urls.txt

# Filtra per endpoint interessanti
cat wayback_urls.txt | grep -iE "\.(php|asp|aspx|jsp|json|xml|env|bak|sql|zip)$"
cat wayback_urls.txt | grep -iE "(admin|login|api|dashboard|config|backup|upload)"

Checklist #

text

SETUP
☐ Tool installati: subfinder, amass, dnsx, httpx, nuclei, gowitness, ffuf, trufflehog
☐ API key configurate: SecurityTrails, Shodan, VirusTotal, GitHub
☐ Wordlist aggiornate: SecLists clonato in /usr/share/seclists/

PASSIVE RECON
☐ crt.sh interrogato per certificati
☐ subfinder eseguito con tutte le fonti
☐ amass enum --passive eseguito
☐ Wayback Machine interrogato per URL storici
☐ Shodan/Censys cercato per org e hostname
☐ GitHub/GitLab cercato per menzioni del dominio

DNS + LIVE CHECK
☐ dnsx per filtrare sottodomini che risolvono
☐ httpx per identificare host HTTP/HTTPS attivi
☐ Status code e tecnologie annotati

ACTIVE RECON
☐ Port scan (nmap o masscan) su IP attivi
☐ Screenshot (gowitness o eyewitness) per triage visivo
☐ Content discovery (ffuf o feroxbuster) su host interessanti
☐ Wordlist specifica per tecnologia identificata

VULNERABILITY + SECRET
☐ Nuclei con template high/critical
☐ Subdomain takeover check (subjack)
☐ JS file scaricati e analizzati per secret
☐ Google dork per file esposti (.env, .log, .bak)
☐ GitHub dork per credenziali hardcodate
☐ trufflehog su repository pubblici dell'organizzazione

DOCUMENTAZIONE
☐ Mappa della superficie d'attacco
☐ Sottodomini interessanti evidenziati
☐ Tecnologie identificate per ogni host
☐ Finding prioritizzati per impatto

FAQ #

Da dove inizio se il target ha migliaia di sottodomini? Triage per priorità: prima guarda gli screenshot e filtra per pannelli di login, applicazioni non standard, pagine di errore verbose. Poi concentrati sui sottodomini con tecnologie note vulnerabili (WordPress, Jenkins, Grafana, phpMyAdmin) o con porte insolite aperte. Ignora per ora i sottodomini generici con CDN davanti.

Posso usare questa pipeline in un bug bounty senza violare le regole? La recon passiva (crt.sh, Shodan, Wayback Machine) non tocca mai i server del target — è sempre permessa. La recon attiva (port scan, content discovery, nuclei) deve essere nel scope del programma. Leggi sempre le regole prima di fare scansioni attive.

Quante API key mi servono per una pipeline efficace? Per iniziare: GitHub (gratuita, necessaria per dorking), Shodan (piano gratuito limitato). Per una pipeline completa: SecurityTrails, VirusTotal, Censys. Molti tool come subfinder hanno modalità senza API key che usano solo fonti pubbliche — già molto utile.

Amass vs Subfinder: quale uso? Usali entrambi e unisci i risultati. Subfinder è più veloce e trova più sottodomini in modalità passiva grazie alle sue numerose fonti. Amass è più lento ma fa bruteforce e permutazioni che subfinder non fa. La combinazione copre molto di più di ognuno separatamente.

Come gestisco un output di 10.000 sottodomini? Filtra subito con dnsx (solo quelli che risolvono), poi httpx (solo quelli che rispondono HTTP). Di solito dal 10% al 30% è realmente attivo. Poi usa gowitness per gli screenshot e fai triage visivo — in 30 minuti identifichi i target interessanti tra centinaia.