Google Dorking: cos’è e come usarlo nell’Ethical Hacking

Il Google Dorking, chiamato anche Google Hacking, è una tecnica di ricerca avanzata che utilizza gli operatori di Google per individuare informazioni indicizzate ma non necessariamente pensate per essere pubbliche.

Non si tratta di compromettere un sistema, installare malware o violare un’infrastruttura. Il Google Dorking sfrutta ciò che è già stato reso visibile ai motori di ricerca: file, directory, pagine di login, errori applicativi, documenti interni, configurazioni errate o dati pubblicati accidentalmente.

Per questo motivo è una tecnica utilizzata sia dagli attaccanti durante le fasi di ricognizione, sia dai professionisti di cybersecurity nell’ambito di attività autorizzate di OSINT, vulnerability assessment ed ethical hacking.

In ambito aziendale, il problema non è Google. Il problema è ciò che l’organizzazione ha lasciato esposto e indicizzabile.

Perché il Google Dorking è rilevante per la cybersecurity

Ogni azienda pubblica continuamente informazioni online: siti web, portali, documenti PDF, vecchie pagine non più mantenute, ambienti di test, sottodomini, repository, pannelli applicativi e contenuti caricati da utenti o fornitori.

Una parte di queste informazioni può essere indicizzata dai motori di ricerca. Se non viene gestita correttamente, può diventare un punto di partenza per attività di ricognizione.

Il Google Dorking può evidenziare:

• file riservati pubblicati per errore;
• documenti interni accessibili da Internet;
• directory non protette;
• messaggi di errore applicativi;
• vecchi ambienti di staging;
• pagine di login esposte;
• configurazioni errate;
• informazioni utili per attacchi di phishing o social engineering.

In una strategia di sicurezza moderna, verificare cosa è visibile pubblicamente è una misura di controllo fondamentale. È una delle attività preliminari che rientrano nelle fasi di ricognizione passiva e OSINT.

Per un approfondimento più ampio sul tema, puoi leggere anche la guida Nexsys dedicata a OSINT e Open Source Intelligence.

Cos’è il Google Dorking (e perché è nato)

Il termine è stato coniato nel 2002 da Johnny Long per descrivere l’uso di query avanzate (“Google Dorks”) capaci di restituire informazioni indicizzate ma non intenzionalmente pubbliche.

Non si tratta di “bucare” un server.
Si tratta di sfruttare:

• operatori di ricerca avanzata
• errori di configurazione
• esposizioni involontarie

È una forma di ricognizione passiva (passive reconnaissance) utilizzata durante le fasi OSINT di un penetration test.

Se Google può leggere un file, chiunque può trovarlo.

Gli operatori avanzati di Google: sintassi professionale

Per eseguire un audit serio devi combinare operatori logici e filtri.

Operatori principali

• site:

Limita la ricerca a un dominio o TLD.

site:azienda.it

site:.gov

 

• filetype:

Filtra per estensione.

filetype:pdf

filetype:sql

filetype:env

 

• intitle: / allintitle:

Cerca keyword nel titolo HTML.

intitle:"index of"

• inurl: / allinurl:

Trova parole nell’URL.

inurl:admin

 

• intext: / allintext:

Cerca stringhe nel corpo della pagina.

 

• cache:

Visualizza la versione memorizzata da Google.

 

• inanchor:

Ricerca testo nei link in entrata.

Simboli e operatori logici

• " " → frase esatta
• - → esclusione
• * → jolly
• | → OR logico
• _ → completamento automatico

Rischi aziendali legati alle informazioni indicizzate

Le informazioni raccolte tramite Google Dorking possono sembrare isolate, ma spesso diventano pericolose quando vengono correlate.

Un singolo documento pubblico può rivelare nomi di utenti, tecnologie utilizzate, versioni software, indirizzi email, convenzioni di naming, fornitori, sedi, procedure interne o dettagli infrastrutturali.

Queste informazioni possono essere usate per:

• costruire campagne di phishing più credibili;
• identificare software e tecnologie vulnerabili;
• individuare portali aziendali esposti;
• ricostruire la struttura organizzativa;
• preparare attacchi di credential stuffing;
• migliorare la fase di ricognizione prima di un penetration test;
• aumentare l’efficacia di attacchi mirati.

Il rischio non deriva solo dal singolo dato, ma dalla sua combinazione con altre informazioni pubbliche.

Per questo motivo il Google Dorking dovrebbe essere integrato in un processo più ampio di consulenza cybersecurity e assessment tecnico.

Come ridurre il rischio di esposizione sui motori di ricerca

La protezione non si basa su un singolo controllo. Serve una combinazione di governance, configurazione tecnica, monitoraggio e formazione.

1. Controllare cosa è indicizzato

L’azienda dovrebbe verificare periodicamente quali contenuti del proprio dominio sono presenti nei risultati di ricerca. Questo controllo deve includere sito principale, sottodomini, portali, vecchi ambienti, documenti PDF e contenuti pubblicati da terze parti.

2. Rimuovere contenuti non necessari

File obsoleti, documentazione interna, backup, esportazioni e materiali non più validi non dovrebbero restare pubblicamente accessibili. La rimozione dal sito deve essere accompagnata, quando necessario, da richiesta di deindicizzazione.

3. Gestire correttamente robots.txt e meta tag

Il file robots.txt non è una misura di sicurezza. Serve a dare indicazioni ai crawler, ma non impedisce l’accesso a contenuti sensibili. Le pagine realmente riservate devono essere protette da autenticazione e controllo degli accessi.

4. Proteggere ambienti di test e staging

Gli ambienti non produttivi sono spesso meno controllati dei sistemi principali, ma possono contenere dati reali, configurazioni sensibili o versioni applicative vulnerabili. Devono essere protetti, segregati e non indicizzabili.

5. Evitare la pubblicazione di documenti sensibili

PDF, fogli Excel, esportazioni, manuali interni e documenti tecnici devono essere revisionati prima della pubblicazione. Anche i metadati dei file possono contenere informazioni utili.

6. Formare il personale IT e marketing

Molte esposizioni non derivano da un attacco, ma da pubblicazioni errate. Chi gestisce siti, landing page, repository, documenti e portali deve conoscere il rischio di indicizzazione involontaria.

Per il personale non tecnico, può essere utile un percorso di Cyber Security Awareness. Per i team tecnici, invece, è più indicato un percorso pratico su ethical hacking, OSINT e sicurezza infrastrutturale. Dove l’azienda espone già applicazioni basate su AI, il perimetro da presidiare si allarga ulteriormente: in questi contesti diventa rilevante anche una formazione specifica sul red teaming dei sistemi AI.

Google Dorking, OSINT e penetration test

Il Google Dorking è spesso una delle prime attività nella fase di raccolta informazioni. In un penetration test autorizzato, permette di ottenere una vista esterna dell’organizzazione prima di passare a test più tecnici.

Rientra nella ricognizione passiva perché non richiede necessariamente interazione diretta con i sistemi target. Questo lo rende utile per comprendere l’esposizione pubblica senza generare traffico anomalo verso l’infrastruttura aziendale.

Tuttavia, da solo non è sufficiente.

Un assessment completo deve includere anche:

• analisi dei servizi esposti;
• revisione delle configurazioni;
• vulnerability assessment;
• verifica delle identità e dei privilegi;
• analisi Active Directory;
• hardening Microsoft 365;
• controllo endpoint e cloud;
• mappatura degli asset AI esposti (chatbot, endpoint di inferenza, integrazioni);
• valutazione delle procedure di risposta agli incidenti.

Il Google Dorking è quindi una tecnica utile, ma deve essere inserita in una metodologia più ampia.

Per una formazione più completa sulle competenze offensive e difensive, Nexsys propone corsi cybersecurity dedicati a ethical hacking, blue team, incident response e sicurezza aziendale nella sezione formazione informatica professionale.

Google Dorking e superficie AI: gli asset che nessuno cerca

La ricognizione tramite dork nasce per trovare file, directory e portali esposti. Con la diffusione di applicazioni basate su modelli linguistici, alla lista si aggiunge una categoria di asset che poche organizzazioni includono nel proprio inventario: chatbot pubblici, interfacce di test di assistenti conversazionali, endpoint di API AI, documentazione di integrazioni e file di configurazione che referenziano servizi di inferenza.

La logica non cambia. Se un’azienda ha pubblicato - spesso senza una regia centrale - un ambiente di prova di un assistente AI, una pagina di documentazione di un’API o un file che espone chiavi verso un servizio di modelli, quei contenuti possono essere indicizzati esattamente come un vecchio pannello di login. Alcuni esempi di query orientate a questa superficie:

site:azienda.it inurl:chat

filetype:env "OPENAI_API_KEY"

intitle:"index of" intext:prompt

site:azienda.it inurl:(api | assistant | bot)

L’obiettivo difensivo è lo stesso del resto della pagina: verificare cosa è raggiungibile e ridurre l’esposizione. Ma qui il rischio ha una sfumatura in più. Una chiave API esposta non è solo una credenziale: può dare accesso a un modello collegato a dati o sistemi aziendali. E un chatbot di test raggiungibile pubblicamente può essere sondato per capire quali integrazioni monta e come reagisce a input manipolati.

A questo punto la ricognizione passiva incontra l’offensive security applicata all’AI. Chi vuole capire come questi asset - una volta individuati - vengono analizzati e attaccati in modo controllato (agenti, pipeline RAG, integrazioni, infrastruttura di deployment) può vedere il corso AI Red Teaming di Nexsys, dedicato proprio al red teaming dei sistemi AI.