Caso Studio Security-SEO: cloaker malware fermato in 48 ore, 22K visite salvate

Cliente: anonimizzato — clinica medical tourism (settore YMYL)
Mercato target: Italia + internazionale cross-border
Consulente: Jeansy Sese (SEOSESE)
Periodo incidente: seconda metà 2026 — post caso studio SEO pubblicato ad aprile 2026
Tipo attacco: cloaker malware GRESIKTOTO + TXT DNS hijacking GSC
Traffico a rischio: 22.000 visite organiche/mese
Tempo di bonifica: 48 ore dall’identificazione al confirmed clean
Impatto SEO reale: zero ranking persi, zero warning GSC, zero flag Safe Browsing

Executive Summary
Quattro mesi dopo aver portato un Cliente del settore medical tourism da 7.600 a 22.000 visite organiche mensili (caso studio pubblicato ad aprile 2026), abbiamo affrontato un tentativo di sabotaggio SEO via cloaker malware GRESIKTOTO.
Vettore di ingresso: credenziali hosting compromesse mesi prima (pre-2FA) + vulnerabilità pre-auth su plugin WordPress mainstream.
Impatto potenziale: flag Google Safe Browsing, manual action “hacked content”, de-indicizzazione totale, perdita Featured Snippet conquistati.
Impatto reale: zero. Bonifica completata in 48 ore, 7 check curl Googlebot consecutivi puliti in 32 ore di monitoraggio, zero variazioni di ranking, zero warning GSC, zero traffico perso.
Questo articolo racconta come. Non come post-mortem tecnico — come framework Security-SEO replicabile per chiunque faccia SEO su siti YMYL ad alto traffico.

Il contesto: 4 mesi dopo

Ad aprile 2026 ho pubblicato il caso studio di un Cliente del settore medical tourism: da 7.600 a 22.000 visite organiche/mese in 4 mesi, ottenute con SEO semantica e Featured Snippet Optimization. Il framework ha funzionato, il traffico è cresciuto, il Cliente ha iniziato a ricevere lead qualificati cross-border.

Poi è successo qualcosa che non avevo raccontato nel case study.

Nelle stesse settimane in cui il traffico esplodeva, qualcuno stava tentando di distruggerlo. Un cloaker malware serviva pagine gambling indonesiane al crawler di Google mentre mostrava il sito pulito ai visitatori umani. Se non ce ne fossimo accorti in tempo, il risultato sarebbe stato prevedibile: Safe Browsing flag → manual action → de-indicizzazione → 22.000 visite/mese a zero.

Non è successo. Questo caso studio spiega perché.

Il trigger: come abbiamo scoperto l’attacco

La SEO non è solo keyword research e link building. È anche saper leggere i segnali deboli — i pattern che non torneranno mai in un report Semrush ma che un operatore attento nota nel giro di poche ore.

I segnali che hanno innescato l’indagine:

1. Variazione title inaspettata su 2 URL core (/it/ e /en/) in Search Console Coverage report
2. Spike di query gambling (slot gacor, situs slot, jalur link) in Performance → Queries con zero click — impossibile per un sito di chirurgia estetica
3. Nuovi URL indicizzati con pattern /cache-*.html che non corrispondevano al sitemap
4. Time-on-page crollato su desktop ma non su mobile — classico pattern cloaking asimmetrico

Il trigger decisivo è arrivato da un test banale che dovrebbe essere routine mensile in qualsiasi audit SEO serio:

curl -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
     -s https://[cliente].tld/it/ | grep -iE "gresiktoto|slot gacor|situs slot|jalur link"

Il comando ha restituito 47 match su una singola richiesta. Stesso URL aperto da browser: zero match, sito perfettamente pulito.

Era un cloaker. E stava servendo Google da settimane.

Anatomia del cloaker GRESIKTOTO

GRESIKTOTO è il nome dato a una famiglia di cloaker di origine indonesiana specializzata nel dirottare traffico SEO verso reti di gambling illegale. Il modello di business è chirurgico:

• Non danneggia visibilmente il sito (il proprietario non se ne accorge)
• Non mostra pop-up o redirect al visitatore umano
• Mostra contenuto gambling solo al crawler di Google, identificato via User-Agent
• Sfrutta l’authority del dominio vittima per indicizzare migliaia di pagine doorway
• Monetizza rank dirottando il click su landing gambling solo per query gambling

È il parassita perfetto: vive sulla SEO del Cliente senza ucciderla subito. Google penalizza quando rileva il cloaking, che può richiedere settimane. Nel frattempo l’attaccante monetizza.

Perché colpisce i siti medical tourism

I siti YMYL ad alta authority sono bersagli preferiti per tre ragioni:

1. Trust pre-accumulato — il dominio ha già E-E-A-T solido, quindi le doorway gambling indicizzano più velocemente
2. Traffico internazionale — target multi-paese = doorway multi-lingua senza dover costruire authority da zero
3. Proprietari non-tech — cliniche, studi medici e agenzie di turismo sanitario raramente hanno security engineer in-house

Il nostro Cliente aveva tutte e tre le caratteristiche.

La meccanica del cloaker

Il payload era un file index.php modificato in due directory strategiche (/it/ e /en/) — proprio le cartelle con più peso SEO. Lo pseudo-codice:

<?php
if (stripos($_SERVER['HTTP_USER_AGENT'], 'googlebot') !== false
    || stripos($_SERVER['HTTP_USER_AGENT'], 'bingbot') !== false) {
    // Serve payload gambling con title/H1/content spam
    include 'wp2.php';  // payload statico, non deve leggere il DB
    exit;
}
// Altrimenti: continua il bootstrap WordPress normale
require __DIR__ . '/wp-blog-header.php';

Due dettagli non ovvi che meritano attenzione:

1. Il payload era statico, non dinamico. Il file wp2.php (nome deliberatamente simile a file WP legittimi) serviva HTML pre-generato senza toccare il database. Questo significa: nessuna query sospetta nei log MySQL, nessun pattern di accesso DB anomalo. I classici IDS database-oriented non lo vedono.

2. Era un “fork” del bootstrap. Il file index.php NON era completamente malevolo. Eseguiva il payload solo su match User-Agent, altrimenti lasciava girare WordPress normale. Questo rende la detection via diff più difficile: il file “funziona” per un utente che lo testa da browser in sessione admin.

L’impatto SEO potenziale (scongiurato)

Parliamo di numeri. Se il cloaker fosse rimasto attivo altre 2-4 settimane, la traiettoria era questa:

Il caso più comune in letteratura è il primo: Safe Browsing flag. Chrome mostra l’interstitial rosso “Deceptive site ahead” a chiunque provi ad aprire il sito. Per un Cliente del settore sanitario, significa fine della credibilità commerciale — non solo del traffico.

Il caso peggiore è il terzo: de-indicizzazione dominio intero via manual action. Il recupero post-action richiede reconsideration request, bonifica certificata, e in genere 6-12 mesi per tornare ai livelli pre-incidente. Per un Cliente che aveva appena investito 4 mesi di contenuti semantici, sarebbe stato devastante.

Nessuno di questi scenari si è verificato. Ecco come.

Il vettore dormiente: DNS + GSC hijacking

Qui arriva la parte che pochissimi SEO conoscono, e che è la vera lezione editoriale di questo caso.

Il cloaker non era la vulnerabilità. Era il sintomo.

La vulnerabilità reale era composta da due elementi dormienti, attivati in cascata:

Vettore 1 — Credenziali hosting compromesse

Le credenziali dell’account hosting shared managed del Cliente erano state compromesse mesi prima, probabilmente via phishing o riuso password. L’attaccante le aveva tenute in tasca senza usarle — un pattern tipico: rubare oggi, monetizzare domani, evitare tripwire temporali.

Quando il Cliente ha attivato l’autenticazione a due fattori (2FA) sull’hosting, l’attaccante non ha perso l’accesso. Aveva già piazzato TXT record DNS dormienti nella zona DNS del dominio, settimane prima. Quei record non facevano niente di visibile. Aspettavano.

Vettore 2 — TXT google-site-verification fantasma

Questo è il trucco che la maggior parte degli SEO non conosce.

Un record TXT google-site-verification sul root del dominio (example.com) verifica ownership in Google Search Console non solo per example.com, ma per qualunque URL-prefix property che inizi con quel dominio. Sottodomini inclusi. Path specifici inclusi.

L’attaccante aveva piazzato un TXT google-site-verification=R1VT... nel DNS mesi prima. Finché il dominio del sottodominio target non era attivo online, la verifica GSC restava pending. Silenziosa. Invisibile.

Quando il Cliente ha rilanciato un sottodominio (nuova landing page, stessa infrastruttura), GSC ha completato automaticamente la verifica pending. L’attaccante si è ritrovato owner legittimo del sottodominio secondo Google, senza aver mai toccato nulla nel momento del deploy. Email di notifica: “New owner added for [sottodominio]”.

A quel punto l’attaccante aveva:

• Accesso GSC al sottodominio (vedere query, inviare sitemap, richiedere re-indexing)
• Possibilità di inviare Disavow File per sabotare il profilo link
• Possibilità di rimuovere URL via Removals tool
• Visibilità sul traffico del Cliente per calibrare attacchi successivi

Il cloaker sui path /it/ e /en/ era il secondo stadio. Il primo stadio era l’ownership GSC, piazzato mesi prima e scattato al momento giusto.

Perché questo cambia il gioco

La maggior parte dei framework di incident response WordPress si concentra su:

• File integrity monitoring
• Plugin/core vulnerability scanning
• Malware detection sui file PHP

Nessuno di questi avrebbe rilevato i TXT DNS dormienti. Non sono sul filesystem del sito. Non sono in un plugin. Non sono in un file PHP. Sono nella zona DNS — un sistema completamente separato, spesso gestito da pannelli hosting diversi, con audit log raramente consultati.

Se fai SEO su domini con valore commerciale, i TXT records del DNS devono essere parte del tuo audit mensile. Non del tuo team IT. Del tuo audit SEO. Perché la conseguenza di un TXT malevolo è SEO, non IT.

Il protocollo di bonifica (framework replicabile)

Ecco la sequenza operativa esatta. Replicabile. Numerata per ordine di priorità.

Step 1 — Isolamento, non cancellazione

Regola aurea: mai cancellare file malevoli prima di averne copia forense. Serve capire il vettore, identificare altri file compromessi, ricostruire la timeline.

Copia tutti i file sospetti fuori dal document root, in una directory non servita dal webserver (es. ~/forensics/[timestamp]/). Preserva timestamp originali con cp -p.

Step 2 — Opzione B: vanilla restore

Per i file core compromessi (index.php, wp-load.php, wp-config.php se necessario), non tentare il “cleaning” manuale. Troppo rischio di lasciare backdoor annidate.

Sostituisci con versione vanilla scaricata direttamente da wordpress.org:

curl -LO https://wordpress.org/latest.tar.gz
tar xzf latest.tar.gz
# Ripristina index.php vanilla, preserva wp-config.php (dopo verifica)

Se il Cliente ha customizzazioni legittime su index.php (raro), documentale prima e re-applicale dopo. Nel 95% dei casi index.php è vanilla.

Step 3 — Rotazione credenziali hard

In ordine:

1. Password hosting (tutti gli account, non solo admin)
2. Chiavi SSH — revoca e rigenera
3. Password database MySQL — aggiorna wp-config.php
4. Password admin WordPress — tutti gli utenti con ruolo >= editor
5. WP salt keys — rigenera via wp config shuffle-salts o service online ufficiale
6. API keys di servizi integrati (mailer, CRM, payment)
7. 2FA ovunque sia possibile — hosting, GSC, WP admin

Step 4 — Audit DNS completo

Questo è il punto che la maggior parte dei protocolli salta.

Scarica la zona DNS completa e verifica ogni singolo record TXT, in particolare quelli google-site-verification, facebook-domain-verification, _acme-challenge scaduti, e qualsiasi record SPF/DKIM con selettori non documentati.

Per ogni record google-site-verification:

• Identifica a quale account Google appartiene (chiedi direttamente al presunto owner)
• Se nessuno del team conferma di averlo creato → cancella immediatamente
• Dopo la pulizia, rigenera una verifica controllata da te per mantenere ownership legittima

Step 5 — Cleanup GSC

In Search Console:

• Users and permissions → rimuovi qualunque owner/user non riconosciuto
• Verifica owners di ogni property e sottoproperty
• Disavow file → controlla se è stato modificato (timestamp)
• Removals tool → controlla richieste recenti
• Sitemap → verifica che sia il tuo, non uno iniettato

Step 6 — Patch vulnerabilità upstream

Nel nostro caso specifico il vettore di rientro era un plugin WordPress mainstream con CVE pre-auth aperto (bypass autenticazione, RCE via file upload non validato). Update completato durante la settimana di bonifica.

Principio: bonificare senza patchare la vulnerabilità di ingresso è come svuotare una barca senza tappare il buco. Tornerà a riempirsi.

Step 7 — Verifica curl Googlebot (la parte che tutti saltano)

Ecco il protocollo curl obbligatorio che abbiamo usato. Senza questo step, non dichiarare mai una bonifica chiusa.

# Test su 8-10 URL rappresentativi: homepage, /it/, /en/, sotto-pagine, 404
for url in \
  "https://cliente.tld/" \
  "https://cliente.tld/it/" \
  "https://cliente.tld/it/sotto-pagina-1/" \
  "https://cliente.tld/it/sotto-pagina-2/" \
  "https://cliente.tld/en/" \
  "https://cliente.tld/en/sotto-pagina-1/" \
  "https://cliente.tld/it/paginanonesistente-xyz/" \
  "https://cliente.tld/en/paginanonesistente-xyz/"
do
  response=$(curl -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" -s "$url")
  gambling_hits=$(echo "$response" | grep -icE "gresiktoto|slot gacor|situs slot|jalur link|rahasia link|gresikvip")
  title=$(echo "$response" | grep -oE '<title>[^<]+</title>' | head -1)
  canonical=$(echo "$response" | grep -ciE 'rel=["'\'']canonical["'\'']')
  size=$(echo -n "$response" | wc -c)
  echo "$url → size=$size | gambling_hits=$gambling_hits | canonical=$canonical | $title"
done

Cosa deve mostrare il risultato:

• gambling_hits=0 su tutti gli URL (incluso 404)
• canonical=1 su ogni 200 OK, canonical=0 sui 404
• Title per-pagina (non tutti uguali — indicatore che routing WP è attivo)
• Size coerente con il contenuto atteso (no pagine impreviste di 2KB o 500KB)

Ripeti il test ogni 4-6 ore per 24-36 ore. Un cloaker può essere “a tempo” (attivo solo in certe finestre orarie) o avere meccanismi di ricomparsa automatica via cron. Un singolo check pulito non basta.

Nel caso del Cliente: abbiamo eseguito 7 check consecutivi da T+0 a T+32h. 5 URL su 9 erano byte-identici all’ultimo check, a conferma che la cache WP era in steady state. Zero gambling hits. Titolo e canonical corretti. 404 funzionante.

Solo allora abbiamo dichiarato chiusa la bonifica.

Step 8 — Monitoraggio 30 giorni

Nei 30 giorni successivi:

• Check curl Googlebot automatizzato ogni 6h via cron
• Alert immediato su qualunque gambling hit (via webhook/email)
• Monitoraggio GSC Coverage per nuovi URL inaspettati
• Monitoraggio Performance → Queries per pattern gambling
• Audit DNS TXT settimanale

L’angolo legale: YMYL, GDPR, responsabilità

Questo caso aveva una dimensione che nei classici case study SEO non si vede: responsabilità legale.

Il Cliente operava in ambito sanitario. YMYL puro. Il sito raccoglieva richieste di contatto con dati sanitari (domande specifiche su trattamenti, foto paziente opzionali). Da GDPR, questi sono dati particolari Art. 9.

Un attacco che potenzialmente espone dati sanitari attiva l’obbligo di notifica al Garante entro 72 ore (GDPR Art. 33) quando c’è probabilità di rischio per diritti e libertà degli interessati. Nel nostro caso specifico, l’analisi forense ha concluso che:

1. Il cloaker serviva payload statico, non leggeva database paziente
2. Non abbiamo trovato evidenza di accesso al database MySQL degli utenti dal momento della compromissione
3. Non abbiamo trovato evidenza di esfiltrazione dati
4. L’obiettivo dell’attaccante era SEO hijacking per monetizzazione gambling, non data exfiltration

Questo è stato documentato in un data protection assessment e l’evento è stato classificato come near-miss — rischio potenziale contenuto, nessuna notifica Garante obbligatoria. Ma la valutazione deve essere documentata e firmata dal DPO o figura equivalente, non lasciata implicita.

Chi risponde se il dato fosse stato esfiltrato? La risposta breve: il titolare del trattamento (il Cliente). Contrattualmente, i responsabili esterni (hosting, agenzia, dev) rispondono solo per le parti sotto il loro controllo diretto, e solo nei limiti delle clausole DPA firmate. Senza DPA scritto, la responsabilità di default è tutta sul titolare.

Lezione: se la tua agenzia SEO ha accesso GSC, FTP, database, o DNS di un Cliente che tratta dati particolari, devi avere un DPA firmato. Non è burocrazia. È la differenza tra “siamo coinvolti” e “siamo imputati”.

Lezioni: perché Security ≠ IT, è SEO

Il takeaway editoriale di questo caso è questo: la Security-SEO è una disciplina separata sia dalla security IT tradizionale, sia dalla SEO classica.

Un security engineer ti proteggerà da un data breach, ma non noterà un TXT google-site-verification malevolo perché “non è un rischio IT”. Un SEO classico ti ottimizzerà i Core Web Vitals ma non testerà index.php con User-Agent Googlebot perché “non è un lavoro SEO”.

Nel mezzo c’è un vuoto operativo. Ed è esattamente il vuoto che un cloaker GRESIKTOTO sfrutta.

Checklist Security-SEO mensile (framework replicabile)

Settimana 1 — File & Infrastruttura

• Diff di index.php, wp-load.php, wp-config.php vs repository ufficiale
• Check plugin con CVE aperti (WPScan o Patchstack)
• Audit user WordPress con ruolo >= editor (eliminare dormienti)
• Verifica 2FA attiva su hosting, WP admin, GSC

Settimana 2 — DNS & Dominio

• Dump completo zona DNS, diff vs mese precedente
• Audit ogni record TXT: identifica owner, cancella fantasmi
• Verifica WHOIS privacy + scadenza dominio (> 1 anno)
• Check SPF/DKIM/DMARC per coerenza

Settimana 3 — GSC & Ownership

• Users and permissions di ogni property → solo owner autorizzati
• Verifica Disavow file (timestamp + contenuto)
• Verifica Removals tool (richieste recenti)
• Verifica sitemap sottomessa = sitemap reale

Settimana 4 — Behavioral & Crawling

• Test curl Googlebot su 8-10 URL rappresentativi (pattern gambling + title + canonical)
• Analisi log server per pattern User-Agent anomali
• Check query GSC Performance per pattern off-topic
• Check Coverage report per URL indicizzati inaspettati

Una checklist di 4 ore al mese. Il costo di non farla è il caso che hai appena letto.

Limiti e onestà del dato

Per coerenza col format degli altri case study, ecco i limiti da dichiarare:

1. Campione singolo. Questo è un Cliente, un attacco, un recovery. Non è evidenza statistica che il framework funzioni in tutti i contesti. È una proof-of-concept operativa su un caso reale.
2. Timing favorevole. Abbiamo scoperto il cloaker prima che Google emettesse Safe Browsing flag o manual action. Se l’avessimo scoperto dopo, lo scenario di recovery sarebbe stato radicalmente diverso (reconsideration request, 3-6 mesi di ricostruzione authority). Il framework include detection proattiva proprio per evitare quel scenario.
3. Vettore di ingresso specifico. Credenziali hosting pre-2FA + CVE plugin specifico. Altri vettori (Supply chain attack su tema nulled, script injection via commenti, XSS riflesso) richiederebbero adattamenti del framework.
4. Impatto “zero” verificato nel breve termine. Nessuna perdita di ranking nei 30 giorni successivi alla bonifica. Il monitoraggio a 6-12 mesi è in corso — possibili effetti delayed non sono ancora esclusi al 100%. Finora zero segnali negativi.
5. Dati anonimizzati. Il Cliente e l’hosting specifico sono anonimizzati per protezione reputazionale. I dettagli tecnici (nome malware, tecnica di cloaking, pattern TXT, CVE plugin) sono invece pubblici — già documentati in threat intelligence feed, malware analysis report, CVE database. Zero 0-day rivelato in questo articolo.

Il framework è replicabile?

Sì, con tre pre-condizioni:

1. Accesso tecnico reale a hosting, DNS, GSC, WP admin. Se la tua agenzia non ha questi accessi o non sa usarli, il framework non è applicabile — serve un operatore con mindset DevOps/SysAdmin oltre che SEO.
2. Consenso Cliente a fare routine di test potenzialmente “aggressive” (curl ripetuto con UA Googlebot può essere interpretato come bot malevolo da alcuni WAF — va whitelistato o eseguito da IP autorizzato).
3. Tolleranza al falso positivo. Un audit TXT mensile troverà, in media, 1-2 record di cui nessuno ricorda la provenienza. Nel 95% dei casi sono legittimi (vecchi servizi, tool dismessi, verifiche SEO agency precedenti). Ma non si può assumere legittimità. Bisogna verificare uno per uno. Serve il tempo (e lo stomaco) per farlo.

Con queste tre pre-condizioni, la checklist Security-SEO mensile diventa infrastruttura ripetibile, non caso eccezionale.

Conclusione: SEO senza Security è un castello di sabbia

Costruire authority SEO richiede mesi. Distruggerla richiede giorni.

Il caso studio SEO di questo Cliente (da 7.6K a 22K traffico in 4 mesi) raccontava come si costruisce. Questo caso studio Security-SEO racconta come la si difende. Sono due facce della stessa competenza, e nel 2026 non puoi più permetterti di averne solo una.

La crescita SEO non è un asset fino a quando non è anche un asset difeso. Un ranking organico non è tuo finché un cloaker, un TXT DNS fantasma, o un plugin non patchato possono strappartelo in 48 ore.

Questo è il motivo per cui nei miei audit ho aggiunto un blocco dedicato alla Security-SEO. Non come servizio opzionale. Come pre-requisito.

Jeansy Sese è consulente SEO specializzato in SEO semantica, AI Visibility e Security-SEO. Autore dei caso studio SEOSESE GEO, KEIT GEO Medical Tourism e KEIT SEO Medical Tourism. Questo articolo è il quarto della serie.