Nessun attaccante competente parte dall’exploit. E nessun penetration test serio nemmeno. Prima di lanciare uno scanner o tentare un accesso, un tester deve sapere esattamente cosa esiste, cosa è raggiungibile e quali tecnologie sono in gioco. Questa mappatura preliminare del bersaglio si chiama information gathering, o raccolta informazioni, ed è la fase che trasforma un test alla cieca in un’attività mirata: definisce cosa è esposto, quali sistemi sono coinvolti e quali elementi possono diventare vettori d’attacco reali.
Nel contesto di un servizio di penetration test per aziende, l’information gathering non è una ricerca generica su Internet. È una fase metodologica, autorizzata e tracciata, che consente di ridurre il rumore operativo, evitare test alla cieca e concentrare l’analisi sui punti realmente esposti.
Questa fase è importante anche per distinguere un vero penetration test da una semplice scansione automatica. Uno scanner può trovare vulnerabilità note su servizi già identificati; un tester, invece, deve prima comprendere superficie d’attacco, esposizione pubblica, identità tecniche, domini, sottodomini, servizi, applicazioni, personale esposto e configurazioni deboli.
Cos’è l’Information Gathering nel Penetration Test
L’information gathering è il processo di raccolta, correlazione e validazione delle informazioni disponibili su un target. Può riguardare un’azienda, un dominio, una rete, una web application, un tenant cloud, un’infrastruttura Active Directory, un sistema esposto su Internet o un insieme di asset definiti nello scope del test.
Lo scopo non è “sapere tutto”, ma ottenere dati sufficienti per formulare ipotesi d’attacco realistiche. Un dominio può rivelare sottodomini dimenticati, un certificato TLS può mostrare nomi interni o ambienti di test, un record DNS può indicare servizi cloud, un repository pubblico può esporre riferimenti a chiavi API, endpoint o naming convention aziendali.
Gli standard di riferimento trattano questa fase con nomi diversi: reconnaissance, discovery, footprinting, intelligence gathering. Il concetto rimane lo stesso: raccogliere informazioni prima di passare all’identificazione e alla validazione delle vulnerabilità. Il NIST SP 800-115 descrive la discovery come una fase che include information gathering e scanning; OWASP WSTG - Information Gathering applica lo stesso principio al contesto web application; PTES Intelligence Gathering la colloca tra le attività fondamentali di preparazione tecnica del test.
Perché la raccolta informazioni determina la qualità del test
Un penetration test ha valore quando produce evidenze sfruttabili, priorità tecniche e indicazioni di remediation. L’information gathering influenza direttamente tutti questi aspetti. Un perimetro raccolto male porta a test incompleti; un perimetro raccolto bene permette di identificare asset dimenticati, servizi non documentati e dipendenze non considerate dal cliente.
Esempio tipico: un’azienda chiede un test sul dominio principale, ma durante la ricognizione emergono sottodomini legacy, pannelli amministrativi, ambienti di staging e servizi SaaS collegati allo stesso brand. Questi asset possono essere fuori inventario, ma comunque visibili e raggiungibili da Internet. In molti incidenti reali, l’attaccante non entra dal sistema più protetto, ma dal servizio laterale dimenticato.
Questa è la ragione per cui i servizi di ethical hacking e penetration test devono includere una fase formale di scoping e reconnaissance. Non basta testare “quello che il cliente ricorda”: occorre verificare cosa è realmente esposto e concordare con il cliente come trattare gli asset scoperti durante il test.
Information Gathering passivo e attivo
La raccolta informazioni si divide normalmente in due categorie: passiva e attiva. La distinzione non è accademica: cambia il livello di visibilità verso il target, il rischio operativo e il tipo di autorizzazioni necessarie.
Information Gathering passivo
La raccolta passiva usa fonti che non interrogano direttamente l’infrastruttura target. L’obiettivo è osservare informazioni già disponibili attraverso motori di ricerca, registri pubblici, fonti OSINT, certificati, leak, metadati, documentazione, repository pubblici e cache.
- Query avanzate sui motori di ricerca e operatori documentati da Google Search Help.
- Analisi di domini, intestatari e dati pubblici tramite ICANN Lookup.
- Ricerca di certificati TLS e sottodomini tramite sh.
- Analisi di repository pubblici e riferimenti tecnici tramite GitHub code search.
- Raccolta di indirizzi e-mail, naming convention, documenti pubblici, metadati e riferimenti a tecnologie utilizzate.
Il vantaggio della ricognizione passiva è il basso impatto. Il limite è che le informazioni possono essere incomplete, obsolete o non più pertinenti. Per questo devono essere correlate e verificate prima di diventare base decisionale per il test.
Information Gathering attivo
La raccolta attiva interagisce direttamente con il target o con servizi a esso collegati. Include interrogazioni DNS, banner grabbing, scansioni di porte, fingerprinting di servizi, enumerazione di endpoint e verifica di applicazioni raggiungibili. È più precisa, ma più visibile. Può generare log, alert IDS/IPS, rate limit o blocchi automatici.
Per questo motivo deve essere eseguita solo dentro un perimetro autorizzato, rispettando finestre operative, limiti di aggressività, esclusioni tecniche e regole di ingaggio. La differenza tra un’attività professionale e un comportamento non autorizzato sta proprio in scope, consenso, tracciabilità e controllo del rischio.
Quali informazioni si raccolgono nella fase 1
La tipologia di informazioni dipende dal tipo di penetration test. Un external network penetration test richiede un focus su IP pubblici, domini, sottodomini e servizi esposti. Un web application penetration test richiede endpoint, framework, tecnologie, percorsi applicativi e superfici API. Un internal network penetration test richiede host, segmenti, servizi interni, directory, protocolli e trust relationship.
- Domini, sottodomini, record DNS, record MX, record TXT, record SPF, DKIM e DMARC.
- Indirizzi IP, range pubblici, ASN, provider cloud, CDN, reverse proxy e servizi gestiti.
- Porte aperte, protocolli esposti, banner, versioni applicative e fingerprint del sistema operativo.
- Tecnologie web: CMS, framework, web server, WAF, librerie JavaScript, endpoint API e metodi HTTP.
- Asset dimenticati: ambienti di test, vecchi portali, VPN legacy, pannelli amministrativi, appliance non aggiornate.
- Informazioni sull’organizzazione: naming convention, indirizzi e-mail, ruoli, sedi, documenti pubblici e riferimenti tecnici.
- Eventuali esposizioni involontarie: repository pubblici, chiavi, token, credenziali, file di configurazione o backup raggiungibili.
Questi elementi non rappresentano necessariamente vulnerabilità. Sono segnali. Il lavoro del tester consiste nel trasformare segnali separati in una rappresentazione coerente della superficie d’attacco.
Esempio operativo: da dominio aziendale a superficie d’attacco
Supponiamo di dover testare il perimetro esterno di un’azienda a partire dal solo dominio principale. Una ricognizione strutturata procede per livelli.
- Si parte dal dominio e dai record DNS per capire quali servizi sono dichiarati: posta, portali, VPN, strumenti collaborativi, servizi cloud.
- Si cercano sottodomini tramite certificati pubblici, motori di ricerca, passive DNS e fonti OSINT.
- Si correlano gli host con IP pubblici, provider e tecnologie esposte.
- Si verifica quali servizi rispondono realmente, evitando assunzioni basate su dati storici.
- Si separano asset in-scope, asset da confermare e asset chiaramente fuori perimetro.
- Si documentano evidenze, fonti e timestamp, in modo che il cliente possa validare il perimetro emerso.
A questo punto il tester non ha ancora “attaccato” nulla in senso stretto. Ha però ottenuto una mappa molto più utile del bersaglio: quali sistemi esistono, quali sono esposti, quali sembrano legacy, quali tecnologie compaiono e quali percorsi meritano approfondimento.
Differenza tra Information Gathering, scanning ed enumerazione
I termini vengono spesso usati come sinonimi, ma indicano livelli diversi della stessa catena tecnica. L’information gathering è la raccolta ampia di dati sul target. Lo scanning identifica host, porte e servizi. L’enumerazione approfondisce ciò che è stato trovato: utenti, share, versioni, directory, endpoint, parametri, configurazioni e comportamenti applicativi.
Per un approfondimento specifico sulla fase successiva, è utile collegare l’articolo dedicato all’enumerazione nel penetration testing. Questa separazione aiuta anche la SEO: la pagina information gathering deve presidiare l’intento “raccolta informazioni e reconnaissance”, mentre la pagina enumerazione deve presidiare l’intento “approfondimento tecnico sui servizi individuati”.
Lo stesso criterio evita cannibalizzazioni con l’articolo sulla differenza tra vulnerability assessment e penetration test: questa pagina non deve spiegare in modo esteso tutto il processo VA/PT, ma concentrarsi sulla prima fase del pentest e rimandare alla pagina dedicata per il confronto metodologico.
Information Gathering in un web application penetration test
Nel caso di applicazioni web, la raccolta informazioni assume caratteristiche specifiche. Il tester deve capire architettura, endpoint, metodi di autenticazione, tecnologie, percorsi applicativi, file pubblici, configurazioni esposte e flussi utente. Il riferimento più coerente è OWASP WSTG - Information Gathering, che include attività come search engine discovery, fingerprinting del web server, revisione di file e metadati, identificazione degli entry point e mappatura dell’architettura applicativa.
Questa fase consente di evitare test casuali sui parametri visibili. Prima si mappa l’applicazione, poi si decide dove cercare vulnerabilità di autenticazione, autorizzazione, session management, input validation, upload, configurazione o business logic.
Information Gathering e MITRE ATT&CK Reconnaissance
Nel linguaggio threat-informed, la reconnaissance è anche una tattica MITRE ATT&CK. La sezione MITRE ATT&CK Reconnaissance descrive le tecniche con cui un avversario raccoglie informazioni per supportare operazioni future. In un penetration test, usare questo punto di vista aiuta a collegare il dato tecnico al comportamento reale di un attaccante.
Questo è particolarmente utile nei test orientati al rischio. Sapere che un sottodominio esiste è un’informazione. Capire che quel sottodominio espone una tecnologia obsoleta, fuori inventario e non monitorata è un’indicazione di rischio. Collegare tale esposizione a una possibile catena d’attacco rende il report più utile per il management e per i team IT.
Informatio Gathering sui sistemi AI
La diffusione di agenti conversazionali, assistenti interni e applicazioni basate su modelli linguistici ha aggiunto una superficie che la ricognizione tradizionale non contempla. Accanto a domini, IP e servizi web, oggi un perimetro aziendale espone spesso endpoint di inferenza, API di orchestrazione, interfacce chat pubbliche, plugin e integrazioni verso strumenti esterni. Sono asset a tutti gli effetti, e come tali vanno mappati nella fase 1.
La logica resta quella dell’information gathering classico: prima si osserva cosa è esposto, poi si formulano ipotesi. Cambiano però i segnali da cercare. Un’applicazione AI pubblica può rivelare il modello sottostante dai messaggi di errore, esporre il system prompt attraverso risposte non filtrate, o lasciar intravedere le integrazioni collegate (basi di conoscenza, funzioni, connettori verso servizi interni). Un endpoint di inferenza dimenticato o un ambiente di test di un chatbot rientrano nella stessa categoria di rischio dei sottodomini legacy: raggiungibili, spesso non monitorati, fuori inventario.
Per un team di sicurezza è utile trattare questi elementi come parte della superficie d’attacco fin dalla ricognizione: censire quali applicazioni AI sono realmente pubbliche, quali dati trattano e verso quali sistemi possono agire. Chi vuole approfondire come questa superficie viene poi analizzata e messa alla prova in modo strutturato può vedere il corso AI Red Teaming di Nexsys, dedicato all’attacco controllato di agenti, pipeline RAG e infrastrutture di deployment dei modelli.
Strumenti usati nella raccolta informazioni
Gli strumenti non sostituiscono la metodologia. Servono a raccogliere dati, ma non decidono da soli priorità, affidabilità e impatto. In un contesto professionale si combinano fonti passive, strumenti di discovery, scanner controllati e validazione manuale.
- WHOIS e DNS lookup per domini, record, deleghe e configurazioni pubbliche, anche tramite ICANN Lookup.
- Certificate transparency e ricerca sottodomini tramite sh.
- Motori di ricerca per individuare documenti, portali indicizzati, directory esposte e riferimenti tecnici.
- Motori di ricerca per dispositivi e servizi esposti come Shodan.
- Nmap e strumenti equivalenti per scansione controllata di porte e servizi.
- Burp Suite, OWASP ZAP e browser DevTools per mappare applicazioni web, endpoint e richieste.
- Strumenti OSINT per e-mail, metadati, repository pubblici e informazioni organizzative.
- Distribuzioni e ambienti di laboratorio come Kali Linux, già introdotti nella Guida a Kali Linux.
Il punto critico non è avere “più tool”, ma sapere quando usarli, con quale intensità, su quale perimetro e con quale obiettivo. Una scansione aggressiva fuori finestra può creare problemi operativi; una scansione troppo prudente può non vedere asset rilevanti.
Errori frequenti nella fase di information gathering
- Considerare lo scope iniziale come definitivo, senza verificare asset collegati e dipendenze tecniche.
- Confondere informazioni storiche con asset realmente attivi.
- Usare solo tool automatici senza correlazione manuale.
- Non distinguere fonti affidabili, fonti obsolete e dati duplicati.
- Non documentare fonti, timestamp, comandi e criteri di esclusione.
- Passare subito all’exploitation senza aver completato la mappatura del perimetro.
- Ignorare i segnali organizzativi: e-mail, ruoli, sedi, naming convention, documenti pubblici e processi esposti.
Questi errori riducono la qualità del report finale. Un buon penetration test deve permettere al cliente di capire non solo quale vulnerabilità è stata trovata, ma anche perché quel percorso di attacco era possibile.
Output atteso della fase 1
Alla fine dell’information gathering il tester dovrebbe produrre una base tecnica ordinata, non un elenco grezzo di risultati. L’output deve essere utile per decidere le fasi successive: scanning mirato, enumerazione, vulnerability analysis, exploitation controllato e reporting.
- Elenco asset identificati e classificazione tra in-scope, da confermare e fuori scope.
- Domini, sottodomini, IP, servizi e tecnologie rilevate.
- Fonti utilizzate, data di rilevazione e grado di confidenza del dato.
- Possibili aree di esposizione: servizi legacy, ambienti non documentati, pannelli di gestione, endpoint applicativi.
- Ipotesi tecniche da validare nella fase successiva.
- Rischi preliminari da sottoporre al cliente prima di procedere con attività più intrusive.
Questa documentazione è utile anche in fase commerciale. Aiuta a stimare correttamente effort, finestre operative, complessità e impatto del test. Per questo motivo una pagina informativa sull’information gathering può collegare in modo naturale anche l’articolo su quanto costa un penetration test, senza trasformarsi in una pagina prezzi.
Aspetti legali e regole di ingaggio
L’information gathering può sembrare una fase “leggera”, soprattutto quando usa fonti pubbliche. In realtà, nel contesto di un penetration test professionale deve sempre essere disciplinata da autorizzazione, perimetro, responsabilità e regole di ingaggio.
- Quali domini, IP, applicazioni, sedi o tenant sono autorizzati.
- Quali asset devono essere esclusi.
- Quali finestre operative sono consentite.
- Quale livello di attività attiva è ammesso.
- Come gestire asset inattesi scoperti durante la ricognizione.
- Chi contattare in caso di alert, blocco, degrado o incidente operativo.
- Come trattare dati personali, credenziali, segreti o informazioni riservate eventualmente emerse.
Questo punto è centrale per le aziende. Un penetration test non è un’attività “creativa” lasciata all’iniziativa del tester, ma un’attività tecnica autorizzata, proporzionata e documentata.
Come usare l’information gathering per migliorare la sicurezza aziendale
La raccolta informazioni non serve solo agli attaccanti o ai penetration tester. È anche uno strumento difensivo. Un’azienda che conosce la propria esposizione pubblica può ridurre il rischio prima ancora di eseguire un test completo.
- Mantenere un inventario aggiornato degli asset Internet-facing.
- Rimuovere record DNS obsoleti e sottodomini non più usati.
- Verificare periodicamente certificati, domini e servizi esposti.
- Controllare repository pubblici e documenti indicizzati.
- Limitare l’esposizione di pannelli amministrativi e VPN.
- Monitorare nuove esposizioni create da progetti cloud, SaaS o ambienti temporanei.
- Integrare la ricognizione nella gestione continua del rischio cyber.
In questo senso l’information gathering è anche un ponte tra offensive security e asset management. Molte vulnerabilità diventano critiche non perché tecnicamente sofisticate, ma perché insistono su sistemi dimenticati, non monitorati o non censiti.
Quando serve una formazione specifica
Per i team IT interni, comprendere l’information gathering aiuta a leggere meglio i report di sicurezza, dialogare con i fornitori e validare l’esposizione reale dell’organizzazione. Per chi vuole acquisire competenze operative, Nexsys propone percorsi formativi come il corso Penetration Test e il corso Ethical Hacker, dove la raccolta informazioni viene inserita dentro un processo completo: scoping, reconnaissance, scanning, enumerazione, exploitation controllato e report finale.
La formazione non sostituisce un servizio di test terzo e indipendente, ma permette al personale tecnico di comprendere meglio logiche, limiti e risultati di un penetration test.
Vuoi capire quali asset della tua azienda sono realmente esposti e quanto sono sfruttabili da un attaccante? Richiedi a Nexsys un servizio di penetration test per aziende con analisi della superficie d’attacco, validazione tecnica delle vulnerabilità e report operativo per la remediation.
Per chi opera su ambienti in cui l’AI è già in produzione - assistenti interni, chatbot verso clienti, agenti collegati a sistemi aziendali - la ricognizione si estende anche a questi asset. Il corso AI Red Teaming affronta in modo specifico l’analisi e l’attacco controllato dei sistemi AI, come naturale evoluzione delle competenze offensive verso una superficie che le metodologie tradizionali non coprono ancora.