Interventi documentati

Casi reali, raccontati come referti.

Niente testimonianze inventate: questi sono interventi reali del nostro archivio, anonimizzati per proteggere i clienti. WordPress, ma non solo: lo stesso metodo forense vale su Magento, Joomla e gli altri CMS. 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.

04Magento - skimmer carte + backdoor persistente

Marzo 2026

Nove mesi dentro un e-commerce, senza che nessuno se ne accorgesse.

Un e-commerce di arredamento su Magento, con checkout attivo e pagamenti reali. La prima segnalazione arriva dall'antivirus di un cliente, non dal gestore del sito.

“Nessun sintomo evidente per chi usava il sito: gli ordini funzionavano. Sotto, un attaccante aveva accesso stabile da mesi.”

Diagnosi

L'analisi forense ha ricostruito una compromissione stratificata su più mesi. Nel sistema girava una reverse shell cifrata con connessione attiva verso un server di comando in Germania, tenuta viva da un cron orario. Al checkout era stato innestato uno skimmer che copiava i dati di pagamento verso un dominio esterno, affiancato da un raccoglitore di credenziali. Nel database c'era un account amministratore fraudolento e, nelle cartelle di upload dei media, oltre settecento file PHP di backdoor camuffati con intestazioni immagine per superare i controlli superficiali.

Vettore

Magento fermo a una versione a fine vita, con vulnerabilità note di caricamento file non autenticato tramite le API. Una webshell iniziale era rimasta dormiente per mesi prima di essere attivata, e le cartelle dei media eseguivano codice PHP che non avrebbero mai dovuto eseguire. Non un singolo bug, ma una piattaforma non aggiornata su cui l'attaccante ha potuto costruire con calma.

Intervento

Backup forense prima di toccare qualsiasi cosa. Terminata la reverse shell con binario, configurazione, cron e meccanismo di persistenza; rimossi gli oltre settecento file malevoli; ripristinati i file di sistema manomessi dalle sorgenti ufficiali; eliminato l'amministratore fantasma e invalidate tutte le sessioni; bloccata l'esecuzione di PHP nelle cartelle dei media; ruotate le credenziali del database e la chiave di cifratura. Hardening completo e verifica a piattaforma pulita.

Il rischio che cambia tutto: i dati di pagamento

Su un e-commerce con skimmer al checkout non si parla più solo di malware: si parla di dati delle carte esposti, cioè di una violazione con obblighi precisi. Abbiamo indicato la revoca immediata delle chiavi di pagamento, la rotazione delle credenziali dei servizi e la valutazione della notifica al Garante entro 72 ore. È la differenza tra pulire un sito e gestire un incidente.

Esito

Sito messo in sicurezza e rimesso in linea pulito, con referto forense completo di timeline e indicatori. Il caso ha portato nuove firme di rilevamento per skimmer di pagamento, oggi parte dello scanner.

05Joomla - RCE via componente + relay spam

Giugno 2026

Un componente mai aggiornato, due siti compromessi in pochi minuti.

Due siti aziendali su Joomla ospitati sullo stesso server. Uno aggiornato all'ultima versione, l'altro fermo a un ramo a fine vita da anni.

“Traffico anomalo in uscita e il rischio concreto di finire nelle blacklist antispam: uno dei due siti stava inviando posta per conto di altri.”

Diagnosi

Non un attacco mirato, ma una campagna automatica di sfruttamento di massa. Il sito più esposto era stato trasformato in un nodo attivo: un relay per l'invio di spam, un intero toolkit di attacco per colpire altri bersagli e un archivio di circa duemila credenziali raccolte. Il secondo sito era stato solo sondato, con un piccolo dropper depositato: RCE riuscita, ma senza il tempo di fare danni.

Vettore

Un componente editor molto diffuso, in versione vulnerabile, esponeva una funzione che permetteva il caricamento di codice PHP senza autenticazione. La falla era indipendente dalla versione del core: ha colpito sia il Joomla a fine vita sia quello aggiornato. Ad aggravare, due errori di configurazione del server: nessun limite ai percorsi accessibili da PHP e la cartella temporanea che eseguiva codice. Le tracce complete erano nei log di accesso, minuto per minuto.

Intervento

Prima una fase forense in sola lettura per ricostruire la catena dai log, poi il contenimento: isolamento del sito colpito e blocco degli indirizzi attaccanti. Backup forense, rimozione mirata di tutti gli indicatori (webshell, relay di spam, toolkit, cartella di lavoro dell'attaccante), aggiornamento o rimozione del componente vulnerabile su tutti i siti, correzione delle configurazioni pericolose, rotazione delle credenziali del database. Infine monitoraggio contro la riconquista e verifica della reputazione dell'indirizzo IP usato per lo spam.

Esito

Entrambi i siti bonificati e la causa alla radice chiusa su tutto il server, non solo dove era esploso il problema. Il marker della campagna è stato catalogato per riconoscerla al primo colpo in futuro.

// 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.

Report forense di esempio Come funziona la bonifica