Ogni tanto ci chiama un cliente convinto di avere il sito infetto: i visitatori finiscono su una pagina di phishing, oppure il browser segnala un certificato diverso dal solito, oppure le email di reimpostazione della password non arrivano più. Controlliamo i file, il database, i processi sul server, e non troviamo nulla. Il sito è pulito. Il problema è a monte: qualcuno ha cambiato il posto in cui il nome del dominio porta.
Il nome di dominio è la prima dipendenza di un sito WordPress, e la meno sorvegliata. Chi controlla il DNS decide dove vanno i visitatori, a chi arriva la posta e a chi un’autorità di certificazione rilascia un certificato valido.
In questo articolo vediamo le due forme più comuni di attacco che non passano dal sito: il dirottamento del DNS attraverso l’account del registrar e il takeover dei sottodomini rimasti a puntare verso risorse dismesse. Poi come verificare i record con dig, come usare CAA e Certificate Transparency, perché la posta è il bersaglio più delicato e cosa fare nelle prime ore se succede.
Quando il sito è pulito ma i visitatori finiscono altrove
Per arrivare a un sito, un browser attraversa una catena di anelli, ciascuno gestito da soggetti diversi. Il registrar, cioè il fornitore presso cui si registra il dominio, comunica al registro del dominio di primo livello quali sono i server DNS autorevoli, i record NS. Quei server rispondono con i record del dominio: A e AAAA per gli indirizzi, CNAME per gli alias, MX per la posta, TXT per SPF, DMARC e verifiche varie. Solo alla fine della catena c’è il server che ospita WordPress.
Uno scanner di sicurezza installato nel sito, per quanto bravo, vede solo l’ultimo anello. Se un attaccante modifica un record A o, peggio, i record NS, i visitatori raggiungono un server diverso che può mostrare una copia del sito, raccogliere le credenziali degli amministratori e dei clienti o distribuire malware, mentre il sito originale continua a funzionare, intatto, all’indirizzo che nessuno visita più.
L’account del registrar è la chiave di tutto
Il modo più diretto per dirottare un dominio è entrare nel pannello del registrar o del provider DNS. Non serve alcuna vulnerabilità tecnica: bastano la password, rubata da un infostealer o riutilizzata altrove, oppure l’accesso alla casella email con cui si recupera la password. È lo schema documentato nella direttiva di emergenza ED 19-01 della CISA del gennaio 2019: gli attaccanti, con credenziali valide degli account DNS, modificavano i record per indirizzare il traffico verso la propria infrastruttura e ottenevano certificati validi per i domini presi di mira, in modo da intercettare il traffico senza avvisi nel browser. La campagna descritta da Cisco Talos con il nome di Sea Turtle ha usato la stessa tecnica, arrivando in alcuni casi a compromettere registrar e registri stessi.
Per un sito WordPress i bersagli sono meno esotici ma la dinamica è la stessa. Account del registrar intestati a un’agenzia che non segue più il cliente, password condivise via email, un solo indirizzo di recupero che magari sta proprio sul dominio da proteggere: se il dominio viene dirottato, anche la posta per recuperare l’account finisce all’attaccante. Il minimo indispensabile è un secondo fattore sul pannello, preferibilmente una passkey o una chiave hardware, come spieghiamo nell’articolo sull’autenticazione a due fattori, e un indirizzo di recupero su un dominio diverso.
Lock, 2FA e DNSSEC: cosa protegge davvero
Le protezioni disponibili sono spesso confuse tra loro. Lo stato clientTransferProhibited, che molti pannelli chiamano semplicemente «lock» o «blocco del trasferimento», impedisce che il dominio venga trasferito a un altro registrar, come spiega la pagina dell’ICANN sugli stati EPP. È utile, ma non impedisce a chi è entrato nel pannello di cambiare i record NS o di togliere il blocco. Lo stato clientUpdateProhibited blocca anche gli aggiornamenti. Il livello più forte è il registry lock, con gli stati server…Prohibited impostati dal registro: le modifiche richiedono una procedura fuori banda, per esempio una conferma telefonica, e un attaccante che ha solo la password del pannello non può completarle. Non tutti i registri e i registrar lo offrono, e di solito ha un costo.
DNSSEC firma crittograficamente i record, così che un resolver che la verifica possa scartare risposte falsificate lungo il percorso. Protegge dall’avvelenamento delle cache e dalle manipolazioni in transito, non dal furto dell’account: chi controlla il pannello del registrar può cambiare o rimuovere il record DS insieme ai server NS. Va attivato, ma non sostituisce il secondo fattore e il lock.
Sottodomini orfani e takeover
Il secondo attacco non richiede alcuna credenziale. Un sottodominio, per esempio shop.esempio.it o static.esempio.it, viene fatto puntare con un CNAME a una risorsa di un servizio cloud: un’app su una piattaforma di hosting, un bucket di storage, una distribuzione CDN, una landing page di un servizio di marketing. Anni dopo la risorsa viene cancellata, ma nessuno rimuove il record DNS. Se il servizio permette a chiunque di creare una risorsa con lo stesso nome, un attaccante la crea e da quel momento controlla il contenuto servito sul sottodominio. È il subdomain takeover descritto da MDN, e Microsoft ne documenta il ciclo completo per le proprie risorse nella guida sui record DNS pendenti.
Le conseguenze per un sito WordPress dipendono da cosa quel sottodominio può fare. Se il tema o un plugin caricano script da static.esempio.it, chi controlla il sottodominio esegue il proprio JavaScript sul sito principale, con effetti simili a quelli degli skimmer nel checkout. Se COOKIE_DOMAIN è impostato sul dominio padre, come fa il core per impostazione predefinita nelle installazioni multisite a sottodomini, i cookie di accesso vengono inviati anche al sottodominio conquistato. E se la Content Security Policy o le regole CORS consentono *.esempio.it, il sottodominio ne eredita la fiducia. Anche senza nulla di tutto questo, resta una pagina di phishing ospitata su un nome credibile, con un certificato valido che l’attaccante può ottenere proprio perché controlla il contenuto.
La prevenzione, come ricorda MDN, è una questione di ordine delle operazioni: quando si attiva un servizio, prima si crea la risorsa e poi il record DNS; quando lo si dismette, prima si cancella il record e poi la risorsa. Il progetto can-i-take-over-xyz raccoglie, servizio per servizio, le risposte tipiche di una risorsa non reclamata e se il takeover è possibile.
Verificare i record con dig
Un controllo periodico dei record non richiede strumenti particolari. La prima verifica è la delega: i server NS che il registro del dominio di primo livello annuncia devono essere quelli attesi, e coincidere con quelli dichiarati nella zona. Poi i record principali, da confrontare con un’esportazione di riferimento conservata al sicuro:
# La delega vista dal registro .it, senza cache intermedie
dig +norecurse NS esempio.it @$(dig +short NS it. | head -1)
# I record principali, dal server autorevole
AUTH=$(dig +short NS esempio.it | head -1)
for t in A AAAA MX TXT CAA; do
echo "== $t"; dig +short "$t" esempio.it @"$AUTH"
done
dig +short DS esempio.it # il DS sta nella zona padre: si chiede a un resolver
dig +short A www.esempio.it @"$AUTH"
dig +short TXT _dmarc.esempio.it @"$AUTH"Salvando ogni giorno questo output e confrontandolo con quello del giorno precedente, con un semplice diff in cron, si ottiene un monitoraggio minimo ma efficace. Due accorgimenti lo rendono affidabile: va eseguito da una macchina diversa dal server del sito, e l’avviso deve arrivare a un indirizzo che non stia sul dominio controllato, perché se l’attaccante ha cambiato il record MX l’allarme finirebbe proprio a lui. Alcuni registrar inviano anche una notifica quando cambiano i record NS: conviene verificare che sia attiva e a chi arriva.
Per i sottodomini orfani serve l’elenco completo dei nomi, che si ottiene dall’esportazione della zona nel pannello del provider DNS o, dall’esterno, dai certificati emessi, come vedremo tra poco. Per ogni CNAME si controlla se la destinazione esiste ancora: una risposta NXDOMAIN sulla destinazione è il segnale più chiaro di un record da rimuovere subito.
# sottodomini.txt: un nome per riga
while read -r sub; do
dest=$(dig +short CNAME "$sub" | tail -1)
[ -z "$dest" ] && continue
stato=$(dig A "$dest" +noall +comments | grep -o 'status: [A-Z]*' | cut -d' ' -f2)
echo "$sub -> $dest [$stato]"
done < sottodomini.txt | grep -v 'NOERROR'Non tutti i casi producono un NXDOMAIN: alcuni servizi continuano a risolvere il nome e rispondono via HTTP con un errore del tipo «risorsa inesistente». Per questi l’unica verifica affidabile è aprire il sottodominio e confrontare la risposta con quelle raccolte in can-i-take-over-xyz.
CAA e Certificate Transparency
Un dirottamento DNS ben fatto è accompagnato da un certificato valido, perché senza il browser mostrerebbe un avviso. Due strumenti aiutano. Il record CAA indica quali autorità di certificazione possono emettere certificati per il dominio; le CA lo controllano al momento dell’emissione. Con Let’s Encrypt si può restringere ulteriormente l’emissione a un metodo di validazione o a uno specifico account ACME, come descritto nella documentazione. Il limite è evidente: chi controlla il DNS può modificare anche il record CAA. CAA riduce le emissioni accidentali o da CA non previste, non ferma un attaccante che ha il pannello.
esempio.it. 3600 IN CAA 0 issue "letsencrypt.org"
esempio.it. 3600 IN CAA 0 issuewild ";"
esempio.it. 3600 IN CAA 0 iodef "mailto:sicurezza@esempio-altro.it"Certificate Transparency, invece, è lo strumento di rilevazione: le CA pubbliche registrano i certificati emessi in log pubblici e verificabili, e servizi come crt.sh permettono di interrogarli. Monitorare i nuovi certificati per il proprio dominio è una delle azioni richieste dalla direttiva della CISA citata sopra, e ha un effetto collaterale utile: l’elenco dei nomi nei certificati è un ottimo inventario dei sottodomini, compresi quelli che nessuno ricordava.
# Tutti i nomi apparsi nei certificati del dominio
curl -s "https://crt.sh/?q=%25.esempio.it&output=json" \
| jq -r '.[].name_value' | tr 'A-Z' 'a-z' | sort -u > nomi-ct.txt
# Certificati emessi negli ultimi giorni, con emittente
curl -s "https://crt.sh/?q=esempio.it&output=json" \
| jq -r '.[] | select(.not_before > "2026-10-20") | [.not_before, .issuer_name, .name_value] | @tsv'crt.sh è un servizio gratuito e a volte lento o non raggiungibile; per un monitoraggio continuo conviene un servizio dedicato o una verifica quotidiana che non consideri un errore di rete come un’assenza di novità. Un certificato emesso da una CA che non usi, o per un nome che non conosci, va sempre spiegato.
La posta: MX, SPF e il reset delle password
Il bersaglio più delicato non è il sito ma la posta. Un record MX modificato, anche per poche ore, porta all’attaccante le email del dominio, comprese quelle di reimpostazione della password: di WordPress, del registrar, del pannello di hosting, dei servizi cloud. Un attacco al DNS diventa così, in pochi passaggi, il furto di tutti gli account collegati. È anche il motivo per cui l’indirizzo di recupero dell’account del registrar non dovrebbe stare sul dominio che protegge.
Anche i record TXT vanno riletti con attenzione. Un include: nel record SPF verso il dominio di un servizio di invio dismesso, o un dominio lasciato scadere, può autorizzare qualcun altro a inviare posta a nome tuo; lo stesso vale per un CNAME di DKIM che punta a un fornitore non più usato. Abbiamo parlato di SPF, DKIM e DMARC nell’articolo sul server che invia spam: i report aggregati di DMARC sono anche un buon sistema di allarme, perché mostrano chi sta inviando posta con il tuo dominio.
Se succede: le prime mosse
Se il dominio è stato dirottato, la priorità è riprendere il controllo dell’account presso il registrar, contattandone l’assistenza con la documentazione di titolarità, e subito dopo attivare il secondo fattore, cambiare la password e verificare l’indirizzo di recupero. Poi si ripristinano i record dall’esportazione di riferimento, sapendo che le cache dei resolver continueranno a servire quelli falsi per la durata del TTL. Si cercano su crt.sh i certificati emessi durante il dirottamento e se ne chiede la revoca alla CA. Infine, tutte le credenziali che possono essere state inserite sul dominio in quella finestra vanno considerate compromesse: amministratori di WordPress, caselle di posta, eventualmente i clienti, con la valutazione degli obblighi descritta nell’articolo sul data breach.
Per un sottodominio conquistato, il primo gesto è rimuovere il record DNS orfano, poi capire cosa è stato servito e a chi, e se script o cookie del sito principale erano esposti. In entrambi i casi conviene verificare anche il sito: un attaccante che ha avuto per qualche ora le credenziali degli amministratori può averle usate per lasciare una backdoor, e a quel punto il problema torna a passare dai file e dal database, come descritto nell’articolo sulle prime due ore. Se ti trovi in questa situazione, o vuoi escludere che il sito sia stato toccato dopo un dirottamento, contattaci: analizziamo il sito a livello applicativo e di sistema, con una bonifica garantita in 6, 12 o 24 ore per ogni installazione WordPress.
