Ieri abbiamo ricevuto un’e-mail da un cliente. Il suo sito mostrava un casinò indonesiano invece della pagina della sua azienda di logistica. Ne sono seguite 6 ore di lavoro intenso contro un sistema di attacco ben organizzato. Questa è la storia di ciò che abbiamo scoperto, di come abbiamo ripulito il sito e di cosa abbiamo imparato.
Cosa è successo
Uno dei siti WordPress dei nostri clienti è stato compromesso il 3 luglio 2026. Gli aggressori sono entrati tramite uno scanner automatico che ha sfruttato una vulnerabilità nota pubblicamente (CVE-2026-63030) in una versione obsoleta di WordPress. Il cliente aveva ricevuto i nostri solleciti sull’aggiornamento necessario, ma erano rimasti senza risposta. Ma la parte più interessante non è l’intrusione in sé. La parte più interessante è ciò che hanno fatto dopo.
Nei 66 giorni successivi gli aggressori hanno costruito con cura un’infrastruttura di persistenza. Più backdoor indipendenti, un’obfuscation sofisticata, un’infrastruttura di comando e controllo tramite GitLab e Telegram. Solo quando tutto era pronto hanno rilasciato il payload finale: la homepage del sito è stata sostituita con un clone statico del marchio del casinò indonesiano RUBY8000, a scopo di manipolazione SEO.
Perché è importante
Se Google avesse fatto in tempo a indicizzare il sito nello stato di casinò prima che lo ripulissimo, la reputazione SEO del cliente sarebbe stata danneggiata per mesi. Google inserisce rapidamente questi siti in blacklist, e tornare a un posizionamento normale richiede molto tempo e una richiesta manuale tramite Google Search Console.
Anatomia dell’attacco
Quando abbiamo avviato l’analisi forense, abbiamo capito che non avevamo a che fare con un dilettante o uno script kiddie. L’attacco comprendeva 8 fasi chiaramente identificabili, ciascuna pensata come riserva della precedente:
Fase 1 – Foothold iniziale
Caricamento di una webshell PHP tramite un punto vulnerabile.
Fase 2 – Privilege escalation
Creati 22 account amministratore WordPress con schemi generati in massa (admin_wp2, wpadmin, root_admin…).
Fase 3 – Persistence tramite plugin
Inseriti 4 plugin backdoor nascosti: core-helper-f6003adcd7, wp2shell_badba2c3, wp2shell-f38e02fa54f1, WP-Compact, più un falso plugin di ottimizzazione WebP, wtec-webp, con una shell ALFA_TEAMSHELL integrata.
Fase 4 – Backdoor Auto_prepend_file
Nei file .htaccess e .user.ini sono state inserite direttive che forzavano l’esecuzione di default.php prima di ogni elaborazione di una richiesta PHP. Anche eliminando tutti i plugin, la backdoor avrebbe continuato a funzionare.
Fase 5 – index.php nascosti in profondità
Oltre 15 file index.php collocati in profondità nella struttura di WordPress (ad es. wp-includes/theme-compat/plugins/, wp-admin/network/pomo/) con obfuscation basata su goto e payload base64 eseguiti tramite eval.
Fase 6 – Riserva mu-plugins-old
Una directory mu-plugins alternativa con una backdoor l10n. Il nome si spacciava per una vecchia copia di backup.
Fase 7 – Comunicazione C&C
Tre canali indipendenti di comando e controllo: uno snippet GitLab per scaricare dinamicamente il payload, un bot Telegram per le notifiche e una comunicazione HTTP diretta con il server dell’operatore.
Fase 8 – Payload deploy
Il file index.php del sito è stato sostituito da index.html, che contiene un clone completo del casinò RUBY8000.
Il dettaglio tecnico più interessante – whitespace obfuscation
Nel file default.php (77 KB) abbiamo trovato questa meraviglia:
$dispatcher = ‘ \t \t\t \t\t \t \t \t \t\t\t\t\t\t …’;
$binary = str_replace([‘ ‘, “\t”], [‘0’, ‘1’], $dispatcher);
// Ogni 8 bit vengono convertiti in un carattere:
$decoded = ”;
for ($i = 0; $i < strlen($binary); $i += 8) {
$decoded .= chr(bindec(substr($binary, $i, 8)));
}
eval($decoded); // Esegue il codice PHP decodificato
L’aggressore ha usato spazi e tabulazioni come dati binari. Ogni spazio è 0, ogni tab è 1. Ogni 8 simboli formano un byte. È una soluzione astuta, perché:
- Gli scanner antivirus automatici di solito analizzano i printable characters
- Visivamente il file sembra composto da commenti vuoti e formattati
- Un grep per “eval” trova un solo punto in fondo al codice, non 77 KB di payload offuscato (obfuscated)
Come abbiamo ripulito il sito
L’approccio standard sarebbe stato il ripristino da una copia di backup. Ma l’ultimo backup pulito del cliente risaliva a più di 66 giorni prima e, nel frattempo, il sito aveva ricevuto numerosi aggiornamenti legittimi dei contenuti. Non potevamo semplicemente “tornare indietro” e perdere tutto quel lavoro.
Per questo abbiamo scelto un approccio chirurgico: individuare con precisione e rimuovere ogni artefatto dell’attaccante, preservando tutti i contenuti legittimi. Tre fasi:
Fase 1: Bonifica iniziale
Bash + wp-cli via SSH. Abbiamo disattivato ed eliminato 4 plugin backdoor, cancellato default.php, il file .htaccess con auto_prepend_file e .user.ini. Con wp-cli abbiamo eliminato 22 account admin e invalidato tutti i token di sessione. Prima di qualsiasi modifica, un backup completo del DB come rete di sicurezza.
Fase 2: Scansione in profondità
Scansione ricorsiva dei file PHP in tutta l’installazione WordPress, alla ricerca di firme e anomalie. Ad esempio: un file index.php di oltre 20 KB in profondità nella struttura di WordPress è sospetto. Abbiamo trovato altri 10 file backdoor nascosti, non visibili nella prima fase. Abbiamo inoltre eliminato la directory ALFA_DATA con i CGI wrappers e 15 file .htaccess dell’attaccante.
Fase 3: Pulizia WordPress-native
Abbiamo usato l’integrazione Novamira MCP per accedere direttamente alle API di WordPress. Abbiamo verificato i file core di WordPress rispetto ai checksums ufficiali (tutti puliti). Abbiamo ripulito i record del database di TranslatePress dai contenuti RUBY8000. Abbiamo svuotato la cache di Elementor e quella HTTP di Varnish.
Hardening del server dopo la pulizia
Un sito pulito che resta immutato è come una porta chiusa con la stessa chiave che è stata forzata. Per questo abbiamo rafforzato la configurazione:
// aggiunte a wp-config.php
define(‘DISALLOW_FILE_EDIT’, true); // Vieta la modifica di plugin/temi dall’admin
define(‘AUTOMATIC_UPDATER_DISABLED’, false);
define(‘WP_AUTO_UPDATE_CORE’, ‘minor’); // Auto-updates per le patch di sicurezza
define(‘FORCE_SSL_ADMIN’, true); // HTTPS forzato per wp-admin
Inoltre abbiamo ruotato tutti i salts di WordPress AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY (forzando la disconnessione di qualsiasi sessione residua dell’attaccante), bloccato xmlrpc.php, protetto wp-config.php dalle richieste HTTP e impostato il blocco dell’esecuzione PHP nelle directory wp-content/uploads/ e wp-includes/.
4 lezioni che abbiamo portato con noi da questo caso
1. Gli aggiornamenti di WordPress non sono “quando avremo tempo”, sono critici
La causa iniziale di questo caso era semplice: una versione di WordPress obsoleta. Avevamo inviato al cliente dei promemoria sull’aggiornamento necessario, ma sono rimasti senza risposta. Quando viene pubblicata una vulnerabilità di sicurezza in un componente di WordPress, gli scanner automatici si attivano nel giro di poche ore. Per questo gli aggiornamenti vanno eseguiti nell’arco di settimane, non di mesi.
Consiglio pratico: sottoscrivete un contratto di manutenzione con il vostro partner WordPress, in cui sia stabilito chiaramente che il partner tecnico esegue gli aggiornamenti in autonomia, senza dover chiedere conferma ogni volta. Così evitate che un’e-mail su un aggiornamento critico resti chiusa per settimane.
2. La rotazione dei backup è fondamentale
Il cliente aveva dei backup, ma erano precedenti all’attacco. Un periodo di latenza di 66 giorni significava che tutti i backup “recenti” contenevano già il malware. Consigliamo di conservare almeno 90 giorni di storico dei backup, con archiviazione off-site e copie di backup immutabili (immutable).
3. Una rotazione dei log di 7 giorni è troppo breve
Non siamo riusciti a individuare con certezza al 100% il punto di accesso iniziale, perché i log di accesso di Nginx venivano conservati solo per 7 giorni. Una log retention di almeno 180 giorni dovrebbe essere obbligatoria per qualsiasi sito che tratta dati personali.
4. Il WAF non è un lusso, è il minimo indispensabile
Sul sito era installato un plugin di sicurezza, ma molte delle sue funzioni non erano attivate. Un WAF (Web Application Firewall) in tempo reale, con firme delle minacce attive e aggiornate, avrebbe probabilmente fermato lo scanner iniziale. Inoltre, la 2FA per tutti gli account admin è un requisito minimo, non un’opzione.
Cosa fare se sei stato colpito anche tu da un attacco simile
- Non ripristinare da un backup se non sei sicuro che sia pulito. Prima di tutto, salva una copia del sito compromesso come prova.
- Non cambiare le password da un dispositivo compromesso. Se sul tuo computer c’è un keylogger, anche le nuove password verranno intercettate.
- Cambia le password da un altro dispositivo: admin di WordPress, pannello di controllo dell’hosting, MySQL, FTP/SSH.
- Termina tutte le sessioni attive e imponi la 2FA a tutti gli account admin.
- Contatta uno specialista di sicurezza. Una pulizia manuale senza le competenze necessarie di solito lascia intatta una parte delle backdoor, e l’attacco ritorna entro 2-4 settimane.
CERT.LV segnalazione volontariaSe il tuo sito è stato colpito da un incidente informatico, puoi segnalarlo volontariamente a CERT.LV ([email protected]). Non comporta obblighi aggiuntivi, e gli IoC che invii possono aiutare ad avvisare altre organizzazioni lettoni riguardo alla stessa campagna.
Il tuo sito WordPress è protetto?
Il reparto Sicurezza di EvoEX offre audit di sicurezza, monitoraggio 24/7 e risposta d’emergenza agli incidenti. La protezione proattiva costa circa il 10% dei costi di un singolo incidente.
RICORDA!
Prevenire gli attacchi informatici non è un processo rapido o semplice: richiede competenze tecniche approfondite, tempi di reazione d’emergenza e documentazione per le autorità competenti. Per questo consigliamo di scegliere il servizio di manutenzione offerto dal tuo sviluppatore WordPress. Se non hai un partner tecnico, contattaci.