Subdomain takeover, spiegato — e come rilevarlo | Scanthra

Scanthra · 7 min di lettura · Aggiornato Maggio 2026

Il meccanismo, in un paragrafo

Tre anni fa qualcuno nel tuo team ha creato eventi.tuaazienda.com come CNAME che puntava a tua-pagina-evento.herokuapp.com. La campagna di marketing è finita, l'app Heroku è stata cancellata, il CNAME in DNS è stato dimenticato. Oggi, chiunque può iscriversi a Heroku, rivendicare il nome tua-pagina-evento.herokuapp.com, e servire qualsiasi HTML voglia. I browser che visitano eventi.tuaazienda.com ottengono la loro pagina, con il tuo dominio nella barra degli indirizzi, con la fiducia del tuo brand. TLS (crittografia) funziona perché servizi come Heroku emettono certificati automaticamente. Dal punto di vista del browser, è una visita perfettamente legittima al tuo sito reale.

Perché questo è importante

Attacchi reali osservati in natura:

• Phishing. "Accedi a tua-banca.example.com" porta alla pagina dell'attaccante con un perfetto lucchetto TLS.
• Furto di cookie. Se il tuo dominio principale imposta cookie su .example.com, il sottodominio compromesso può leggerli semplicemente vivendo sotto lo stesso genitore.
• SEO poisoning. Gli attaccanti reindirizzano dal tuo sottodominio a host di frode pubblicitaria o malware. Google a volte mette in blacklist l'intero example.com come risultato.
• Danno al brand. Una notizia come "Il sottodominio di Acme Corp serve pagine di truffa crypto" è difficile da ripulire.

I servizi vulnerabili

Il subdomain takeover è una classe di vulnerabilità contro qualsiasi SaaS che: (1) permette agli utenti di rivendicare un sottodominio arbitrario sulla piattaforma, e (2) non verifica che chi rivendica possieda anche il dominio originale. Le piattaforme storicamente vulnerabili hanno incluso:

• Heroku, AWS S3 bucket (hosting di siti statici), Azure Cloud Apps / Traffic Manager / CDN, GitHub Pages, GitLab Pages, Shopify, Squarespace, Tumblr, Webflow, Netlify, Vercel, Fastly, Pantheon, Zendesk, Statuspage, SendGrid, Mailgun, Tilda, Strikingly, Surge.sh, Ghost.io, Cargo, Read the Docs.

L'indicatore di takeover di ogni piattaforma è leggermente diverso — la maggior parte mostra un caratteristico fingerprint "no such app" / "bucket does not exist" / "404 Not Found" quando il nome non è rivendicato. Il repository EdOverflow/can-i-take-over-xyz mantenuto dalla community su GitHub mantiene la lista aggiornata.

Come rilevare i record pendenti da soli

Passo 1 — Elenca i tuoi sottodomini

Non puoi correggere ciò che non conosci. Fonti per un inventario completo:

• Il file di zona del tuo provider DNS — esporta ogni record A, AAAA e CNAME.
• Log di Certificate Transparency tramite crt.sh — ogni certificato TLS mai emesso per il tuo dominio è pubblico.
• Scansioni precedenti, voci di password manager, wiki interni — ovunque qualcuno potrebbe aver aggiunto un sottodominio che nessuno ha rimosso.

Passo 2 — Risolvi ciascuno

Per ogni record:

• Se è un A/AAAA che punta a un IP che non possiedi più — elimina.
• Se è un CNAME che punta a un servizio di terze parti, recupera l'URL e guarda la risposta. "No such app", "There isn't a GitHub Pages site here", "NoSuchBucket" o "Repository not found" sono segnali di takeover.
• Se dig +short cname.sottodominio restituisce un NXDOMAIN per il target — è un forte segnale di takeover.

Passo 3 — Rimuovi o reclama

Se non hai bisogno del sottodominio, elimina il record DNS. Se hai ancora bisogno di esso, puntalo a un asset corrente. Evita di puntare ad app cloud "placeholder" — tendono a derivare verso uno stato vulnerabile.

Come prevenire il prossimo

• Proprietario DNS per record. Ogni record di sottodominio nella tua zona dovrebbe avere un proprietario documentato nelle note del tuo provider DNS o in un foglio di calcolo interno.
• Checklist di dismissione. "Chiudi il sito della campagna" deve includere "rimuovi il CNAME DNS che punta all'host della campagna".
• Revisione DNS trimestrale. 30 minuti a trimestre evita un incidente che danneggia il brand.
• Wildcard con attenzione. Un wildcard *.example.com CNAME verso un servizio di terze parti è un invito permanente al takeover per qualsiasi nome non rivendicato.

Come Scanthra rileva questo

Il nostro modulo DNS Recon interroga i log pubblici di Certificate Transparency (passivamente, senza brute-force DNS) e segnala ogni sottodominio che ha mai avuto un certificato reale. Mettiamo in evidenza i sottodomini con aspetto di sviluppo, staging e admin come problemi rilevati — i candidati classici per i record dimenticati e pendenti. Il rilevamento del subdomain takeover stesso (controllo se ogni target CNAME non è rivendicato su un provider vulnerabile noto) è nella nostra roadmap e beneficia prima gli utenti paganti.