Interventi documentati

Casi reali, raccontati come referti.

Niente testimonianze inventate: questi sono interventi reali del nostro archivio, anonimizzati per proteggere i clienti. Per ogni caso trovi sintomo, diagnosi, vettore d'ingresso, intervento ed esito, con i numeri veri. Compresi gli imprevisti: è così che si giudica un metodo.

01Injection JS + credenziali rubate
Giugno 2026

Sei siti della stessa agenzia infettati in quattro minuti.

Un'agenzia web italiana con sei siti WordPress sullo stesso server. Il cliente segnala un file sospetto dentro un plugin che nessuno ha mai installato.

Un plugin sconosciuto comparso dal nulla su un sito. Gli altri cinque sembravano a posto.

Diagnosi

Campagna di injection JavaScript con plugin civetta e codice iniettato nei file dei temi. I log hanno mostrato la vera storia: login in wp-admin riuscito al primo tentativo su tutti e sei i siti, da indirizzi IP diversi, nello stesso intervallo di quattro minuti. Nessun brute force: credenziali già rubate, replay scriptato.

Vettore

Non era una falla dei siti: erano le credenziali dell'amministratore, con ogni probabilità sottratte da un infostealer sulla postazione di lavoro. È il caso tipico in cui "pulire i file" senza capire l'ingresso garantisce la reinfezione il giorno dopo.

Intervento

Backup verificati prima di toccare qualsiasi cosa. Bonifica chirurgica sul tema custom (rimozione del blocco iniettato, sintassi verificata) e reinstallazione forzata dei componenti ufficiali dove possibile. Rotazione password, invalidazione di tutte le sessioni, blocco dell'editor file e di XML-RPC. I quattro siti non ancora prioritari sono stati sospesi in modo reversibile: contenimento prima, ripristino poi.

Esito

I due siti di produzione sono tornati online puliti in giornata, con referto tecnico per ciascuno. Dall'attacco abbiamo estratto tre nuove firme di rilevamento che oggi fanno parte dello scanner: ogni intervento rende più forte il controllo successivo.

02Cloaking SEO giapponese + RCE
Giugno 2026

"Abbiamo i file cryptati": non era un ransomware.

Una PMI italiana su hosting condiviso, segnalata dal proprio fornitore. Il sito era irraggiungibile e i file sembravano cifrati.

L'intero albero WordPress rinominato con un suffisso casuale: sembrava una cifratura, era un sabotaggio reversibile.

Diagnosi

Tre compromissioni stratificate: una rete di sette plugin civetta con payload nascosto in file di testo (invisibile agli scanner che leggono solo i .php), un cloaker che serviva spam giapponese solo a Googlebot, e un'escalation finale con webshell, utente amministratore fantasma nel database e 2.525 file .htaccess di controllo sparsi ovunque.

Vettore

Un plugin di gestione file con vulnerabilità nota di upload remoto: assente nello snapshot pulito di fine maggio, compare nei backup lo stesso minuto del primo file malevolo. Correlazione temporale documentata nel referto.

Intervento

Il backup più recente del cliente era già infetto: la sorgente pulita è stata individuata confrontando gli snapshot storici. Malware rimosso, albero rinominato recuperato senza perdita di contenuti, i 2.525 .htaccess eliminati per impronta hash (non a tappeto), utente fantasma rimosso, credenziali database ruotate, hardening completo.

Il follow-up che fa la differenza

Il giorno dopo la consegna, il monitoraggio post-intervento ha intercettato una backdoor di auto-login rimasta nel tema: codice non offuscato, solo funzioni WordPress legittime, invisibile ai motori a firme e presente perfino nel backup "pulito" del cliente, con data di modifica falsificata. L'abbiamo rimossa, documentata e trasformata in una firma di rilevamento. Lo raccontiamo perché è così che lavora un processo serio: la garanzia di 90 giorni esiste esattamente per questo.

Esito

Sito recuperato al 100%, referto forense con timeline completa, monitoraggio attivo. La backdoor residua è stata trovata dal nostro processo di verifica, non da una segnalazione del cliente.

03Japanese keyword hack / cloaking
Maggio 2026

Il sito sembrava sano. Lo era solo per il proprietario.

Un sito aziendale italiano passato dallo scanner. Nessun sintomo visibile: navigandolo, tutto normale.

Nessuno. È il punto: il cloaking è progettato per essere invisibile a chi possiede il sito.

Diagnosi

Lo scanner richiede ogni pagina due volte: come un visitatore qualsiasi e come Googlebot. Al visitatore veniva servita la pagina legittima; a Googlebot, contenuto spam in giapponese destinato ad avvelenare l'indicizzazione. Il confronto tra le due risposte è la prova.

Perché è pericoloso

Google indicizza migliaia di pagine spam a nome del dominio; quando se ne accorge arrivano la penalizzazione e l'avviso "sito compromesso" nei risultati. A quel punto il danno è fatto e il recupero della reputazione richiede settimane. Rilevarlo prima della penalizzazione cambia completamente i costi.

Esito

Compromissione documentata con evidenze tecniche prima della penalizzazione di Google, senza credenziali e senza toccare il sito.

// Verifica tu stesso

Il metodo dietro questi casi è pubblico.

Puoi sfogliare un report forense di esempio, leggere il runbook completo della bonifica sul blog e verificare le garanzie. Prima di affidarci il sito, controlla come lavoriamo.