Questo blog è destinato esclusivamente a scopo didattico. Il nostro obiettivo è aiutare le organizzazioni a comprendere l'impatto reale di voci DNS non configurate correttamente e servizi abbandonati, che le espongono ad attacchi di subdomain takeover. Se desiderate valutare la vostra superficie di attacco e proteggere i vostri domini, non esitate a contattare NGSecurity per una valutazione professionale.
Nel 2025, nonostante i progressi nell'infrastruttura cloud e nell'automazione della sicurezza, uno dei vettori di attacco più semplici ma più pericolosi rimane: l'acquisizione di sottodomini . Non richiede exploit zero-day avanzati o malware personalizzati: bastano record DNS dimenticati e qualche minuto di pazienza da parte dell'aggressore.
In questo post esamineremo:
- Cosa sono le acquisizioni di sottodominio
- Perché accadono ancora oggi
- Una dimostrazione pratica di come gli aggressori li trovano e li sfruttano
- E, cosa più importante: come le organizzazioni possono difendersi da loro
🧠 Che cos'è un'acquisizione di sottodominio?
Un'acquisizione di sottodominio si verifica quando un sottodominio (ad esempio, shop.example.com ) punta ad un servizio esterno, come ad esempio pagine di GitHub, Heroku o un bucket AWS S3, ma la risorsa effettiva non esiste più .
Ciò lascia la porta aperta a un aggressore che potrebbe:
- Richiedere la risorsa non collegata (ad esempio, registrare un nome utente GitHub o un bucket S3)
- Fornire contenuti dannosi o pagine di phishing sotto il sottodominio attendibile del tuo marchio
- Sfruttare i modelli di attendibilità del browser (ad esempio, cookie, CORS, OAuth)
💡 Perché le organizzazioni dovrebbero interessarsene?
Poiché il rischio è facile da trascurare e potenzialmente ad alto impatto :
- I moderni team cloud e DevOps avviano e smantellano rapidamente i servizi.
- Spesso i record DNS rimangono indietro dopo la dismissione di una funzionalità o di un prodotto.
- Gli aggressori possono rivendicare silenziosamente questi domini e impersonare il tuo marchio, attaccare i tuoi clienti o intensificare gli attacchi internamente.
E la parte peggiore? Questi attacchi sono completamente evitabili , ma solo se si sa come individuarli.
⚖️ Dimostrazione pratica: come funziona
Analizziamo un flusso di lavoro di base per la ricerca di un'acquisizione di sottodomini utilizzato dagli aggressori (e dagli hacker etici). Tutti gli strumenti mostrati sono open source e disponibili al pubblico.
💡 Nota: questo esempio utilizza strumenti e tecniche pubbliche. Non tentare di sfruttare alcun dominio reale senza autorizzazione.
Utilizzeremo OWASP Amass :
Comando: amass enum -passive -d example.com -o subdomains.txt
Oppure estrai i dati dal sito crt.sh :
curl -s "https://crt.sh/?q=%. esempio.com&output = json " | jq -r '.[ ]. nome_valore ' | ordina -u > sottodomini.txt
A scopo dimostrativo viene utilizzato il link ufficiale di github.io, in quanto spesso contiene sottodomini inutilizzati che potrebbero essere vulnerabili all'acquisizione da parte di altri sottodomini.
Inizieremo controllandolo da crt.sh e troveremo un collegamento di esempio:
https://crt.sh/?q=github.io
Ora scopriamo se può essere potenzialmente vulnerabile a questo problema. Un semplice controllo consiste nel verificare se una pagina sia ufficialmente ospitata dietro di essa o meno.
Considerando quanto sopra, è molto probabile che sia vulnerabile.
Passaggio 2: identificare i record DNS che puntano a servizi esterni
Utilizzare dnsx:
dnsx -l sottodomini.txt -a - cname -resp-only -o cnames.txt
Siamo interessati ai sottodomini che puntano a servizi come:
- *.github.io
- *.herokuapp.com
- *.s3.amazonaws.com
- *.azurewebsites.net
Per il nostro esempio in corso, abbiamo già identificato una pagina ospitata su github.io, ovvero: http://flag-475ab8.near-dimension.github.io/
Fase 3: Rilevare potenziali acquisizioni
Ora esegui la scansione dei sottodomini vulnerabili utilizzando Subzy :
subzy run --targets cnames.txt
Questo strumento verifica i modelli noti di servizi "sospesi" e segnala quelli potenzialmente meritevoli di rivendicazione.
Come mostrato di seguito, questo è effettivamente vulnerabile:
Fase 4: Convalida (in un ambiente controllato)
Se un sottodominio è contrassegnato:
- Visita l'URL: molti servizi mostrano pagine di errore come:
- Qui non esiste un sito GitHub Pages.
- Nessuna app del genere (Heroku)
- Tenta di rivendicare la risorsa sottostante (utilizzando il tuo dominio per il test)
⚠️ Promemoria e nota : considerati i limiti etici, non vengono effettuate ulteriori acquisizioni ed è altamente raccomandato di effettuare questo tipo di test solo nell'ambiente consentito e con il consenso del proprietario.
🎯 Scenari di rischio nel mondo reale
✔️ Esempio 1 – Pagine GitHub
- docs.example.com punta a user.github.io
- Il nome utente GitHub è stato eliminato
- L'attaccante crea quel nome utente e ospita un sito di phishing
✔️ Esempio 2 – Heroku
- shop.example.com CNAME per example-app.herokuapp.com
- App Heroku eliminata ma il DNS esiste ancora
- L'attaccante crea un'app Heroku con lo stesso nome e dirotta il traffico
Questi casi sono stati segnalati ripetutamente in reali campagne di bug bounty e di red team e spesso hanno portato a furti di identità , escalation degli accessi interni o perdite di dati .
🛡️ Come difendersi dalle acquisizioni di sottodomini
Noi di NGSecurity consigliamo alle organizzazioni di:
✅ Controllare regolarmente i record DNS per riferimenti di terze parti inutilizzati o non di proprietà
✅ Utilizzare l'automazione per monitorare i sottodomini e rilevare i servizi sospesi
✅ Rimuovere immediatamente le voci DNS per i servizi deprecati
✅ Valutare l'aggiunta di record di verifica della proprietà (ad esempio, TXT)
✅ Includere controlli di acquisizione del sottodominio nelle valutazioni di sicurezza e nei pentest
🧪 Bonus: Comando All-In-One da provare (sul tuo dominio)
amass enum -passive -d tuodominio.com | dnsx -a - cname | subzy run --targets -
Questa semplice comando può far emergere rischi reali in pochi secondi. Se non sai come reagire ai risultati, siamo qui per aiutarti.
🗣️ Considerazioni finali
Le violazioni dei sottodomini sono apparentemente semplici, ma nelle mani sbagliate possono essere devastanti. Le organizzazioni spesso danno per scontato che le loro configurazioni cloud e DNS siano sicure, finché un aggressore non dimostra il contrario.
Con questo blog intendiamo informare sviluppatori, amministratori di sistema e team di sicurezza su questo vettore di attacco, in modo che possano adottare misure proattive prima che lo facciano gli aggressori.
📞 Contatta NGSecurity
Se desideri una valutazione preliminare gratuita della tua igiene DNS o un'analisi più approfondita della superficie di attacco che includa il rischio di acquisizione del sottodominio, contattaci a:
🔐 Sicurezza NG
✉️ [email protected]
Assicuriamoci che la presenza digitale del tuo brand sia sicura.
