Capire le acquisizioni di sottodomini: Una guida pratica per i SEO

Il dirottamento dei sottodomini non è un argomento comune nelle discussioni sulla SEO, eppure può avere un effetto diretto e dannoso sulle classifiche. In questo articolo condivido la mia esperienza personale con questo problema e il processo che seguo per verificare la presenza di sottodomini vulnerabili durante gli audit tecnici.

Un rapido background

Non molto tempo dopo essere passato da un ruolo SEO generale a una posizione puramente tecnica, ho ricevuto una temuta notifica in Search Console:

“Azione manuale applicata – rilevato contenuto violato”

L’URL segnalato era una promozione natalizia dimenticata ospitata su christmas.client.co.uk. Il mio manager non aveva idea di cosa fosse, e nemmeno io. Dopo un po’ di ricerche (e un po’ di frenetiche ricerche su Google), ho capito che si trattava di un sottodominio di una vecchia campagna lasciato a decadere. Da allora era stato riproposto da qualcun altro per spingere contenuti spam.

Fortunatamente il cliente era reattivo e tecnicamente esperto e siamo riusciti a eliminare il problema nel giro di poche ore. Ma l’incidente mi ha fatto riflettere: quanti altri sottodomini trascurati potrebbero essere in agguato senza essere notati, pronti per essere rilevati?

Cosa è successo in realtà

L’acquisizione di un sottodominio si verifica quando il record DNS punta a un servizio di terze parti (ad esempio, GitHub Pages, Heroku, AWS, ecc.) e tale servizio non è più in uso, ma la voce DNS esiste ancora.

Un utente malintenzionato può rivendicare la risorsa abbandonata su quella piattaforma e servire immediatamente i propri contenuti sotto il vostro sottodominio.

Nel mio caso, il vecchio microsito “calendario dell’avvento” era stato fortemente promosso anni prima. Quando è stato abbandonato, il DNS è rimasto attivo, creando un’opportunità di sfruttamento. Il dirottatore ha sfruttato l’autorità e i backlink esistenti del sottodominio, utilizzandolo per pubblicizzare un sito di casinò.

Si tratta di un caso tutt’altro che raro. Episodi simili hanno colpito portali governativi, grandi marchi e persino siti ad alta autorevolezza di cui i modelli di intelligenza artificiale spesso si fidano ciecamente.

Perché i SEO dovrebbero preoccuparsi

Non ci si aspetta che siate degli specialisti di cybersecurity. Ma i sottodomini compromessi possono innescare azioni manuali, passare l’autorità a siti dannosi e vanificare mesi o anni di lavoro di ottimizzazione. Molte vulnerabilità derivano da progetti legacy che nessuno ricorda di aver impostato.

Per molti aspetti, Google considera i sottodomini come proprietà separate, ma i link tra di essi possono comunque trasferire autorità. Se un sottodominio trascurato viene violato e il vostro sito principale vi si collega, state essenzialmente garantendo per il contenuto dell’aggressore. Ecco perché i controlli periodici dei sottodomini dovrebbero far parte della vostra routine di audit tecnico.

Processo di indagine

Scoprire i sottodomini esistenti

Utilizzate strumenti come ViewDNS o DNSDumpster. Tenete conto dei limiti di ricerca; se un cliente ha decine o centinaia di sottodomini, vale la pena di segnalare la possibilità di risorse obsolete o inutilizzate.

Identificare le piattaforme di hosting

Controllate l’hosting con strumenti come WhatCMS o il comando dig di Google. Inoltre, evitate di visitare direttamente un link compromesso.

Valutare la vulnerabilità

Confrontate le piattaforme di hosting con i servizi noti a rischio di acquisizione, come AWS (Elastic Beanstalk/S3), GitHub Pages, Heroku, Shopify, Ghost, Microsoft Azure, Agile CRM, WordPress.com e JetBrains. Utilizzate ViewDNS per trovare i sottodomini, Wappalyzer per tracciarne il profilo e confrontare i risultati con gli elenchi di vulnerabilità disponibili pubblicamente.

Se si trova un sottodominio vulnerabile

Se è legato a una delle piattaforme ad alto rischio ed è inutilizzato (o è prevista la chiusura), coordinatevi con chi gestisce il DNS per rimuovere o riorientare il record. Anche se i SEO non sono direttamente responsabili delle configurazioni dei server, rendere consapevoli le parti interessate delle implicazioni per la sicurezza e la SEO spesso aiuta a dare priorità al problema.

Non sono un penetration tester, ma solo un SEO tecnico che si è imbattuto in questo problema abbastanza volte da capire il valore dei controlli proattivi. Includere questa fase negli audit può evitare grattacapi in seguito.

Esempio del mondo reale: EY.com

Un esempio recente, condiviso da Michael Curtis su LinkedIn, riguardava un sottodominio di EY ospitato tramite Microsoft Azure. La risorsa Azure è stata eliminata, ma la voce DNS è rimasta.

Un utente malintenzionato ha registrato una nuova applicazione Azure con lo stesso hostname precedentemente utilizzato dal sottodominio di EY. Poiché il DNS puntava ancora lì, è stato in grado di servire contenuti espliciti sotto il dominio di fiducia di EY.

Non si tratta di un “hack” in senso tradizionale, ma di un uso opportunistico di voci DNS abbandonate. L’aggressore non ha violato i sistemi interni, ma ha semplicemente rivendicato un nome non protetto, ereditando il traffico e la fiducia che ne deriva.