Malware WordPress auto-riparante utilizza una backdoor blockchain

Una famiglia di malware WordPress auto-riparante chiamata SC può ricostruirsi da otto nascondigli separati, secondo un rapporto del 30 settembre 2026 del ricercatore Sucuri Gabriel Barbosa. La famiglia prende il nome dai marcatori SC_ trovati nel codice iniettato. Durante una pulizia, la stessa backdoor continuava a ricomparire entro pochi secondi da ogni rimozione, indipendentemente da quanto attentamente venissero eliminati i file visibili. Il payload risiede in almeno otto posizioni contemporaneamente, distribuito tra file, database e memoria condivisa, e ognuna di queste posizioni può ricostruire tutte le altre. Elimina il plugin e un drop-in lo riscrive. Elimina il drop-in e il tema lo riscrive. Pulisci ogni file su disco e al successivo caricamento della pagina l'intero insieme viene ripristinato dal database o da un segmento di memoria condivisa. Il risultato è un sistema circolare senza alcun punto singolo che possa essere rimosso per fermarlo.

I componenti recuperati usano uno schema di offuscamento comune: nessun eval, nessun nome di funzione leggibile e nessun marcatore sui pezzi più recenti. Ogni file contiene una tabella di stringhe rimescolate e un piccolo decodificatore che risolve un indice numerico in un nome di funzione reale tramite un cifrario a sostituzione posizionale. Un file .user.ini imposta auto_prepend_file, una direttiva PHP che esegue un file specificato prima di ogni richiesta in quel ramo di directory. La direttiva punta a un file shim dal nome semplice, comunemente in wp-content. Lo shim include un loader nascosto con prefisso punto se esiste e non fa nulla silenziosamente se rimosso, il che mantiene il sito funzionante mentre un altro componente ricrea il file nascosto. Quel loader nascosto ricostruisce un falso plugin must-use da tre fonti provate in ordine: una copia del plugin esistente, uno stub codificato nella directory cache e un bundle di ripristino ZIP con nome esadecimale casuale. Scrive tramite un file temporaneo, imposta i permessi a 0644 e chiama opcache_invalidate affinché il nuovo file venga eseguito immediatamente. Un drop-in db.php, che WordPress carica presto durante l'avvio, trasporta l'intera backdoor come blob gzip e base64 e riscrive il plugin ogni volta che manca o è troppo piccolo. Un drop-in advanced-cache.php, caricato ancora prima quando la cache è abilitata, può ricostruire il plugin da cinque fonti: un plugin must-use esistente, una copia del plugin esistente, un segmento di memoria condivisa System V che contiene PHP, un bundle ZIP cercato in diverse cartelle e infine il database stesso tramite una connessione diretta usando le costanti delle credenziali del sito. Un blocco aggiunto al functions.php del tema attivo, delimitato da marcatori begin ed end, agisce come gemello residente nel tema di db.php e riscrive il plugin quando scompare. Il payload malware effettivo viene installato sia come plugin must-use sia come plugin normale, con copie identiche, una pagina di impostazioni convincente, uno shortcode e un hook di attivazione.

La backdoor si nasconde filtrando l'elenco dei plugin, il transient di aggiornamento e le viste dei plugin del sito e della rete, e inietta JavaScript nell'admin per ripulirsi dalla tabella dei plugin come fallback. Per il comando e controllo, non utilizza un singolo server hardcoded. Trasporta invece un elenco di circa venti gateway RPC Ethereum pubblici e un insieme di selettori di metodi di smart contract. Questi gateway di terze parti legittimi fungono da trasporto, quindi bloccare solo quello visto nel traffico lascia disponibili gli altri. Il payload rileva le impronte del sito raccogliendo URL e host del sito, versioni di WordPress e dei plugin, hash dei percorsi, temi attivi, elenco dei plugin must-use e token di sessione degli amministratori correnti. Cripta quel pacchetto e lo invia all'endpoint risolto. La risposta può contenere JavaScript front-end da iniettare, che su un negozio online consente lo skimming al checkout, nuovo PHP da installare ed elenchi di plugin di sicurezza da disattivare ed eliminare. Quando gli viene ordinato di rimuovere un plugin di sicurezza, può disattivarlo, cancellarne la directory e riassegnare o elevare prima un altro account. Crea anche un amministratore nascosto adottando un admin nascosto esistente o generandone uno nuovo, scrivendo l'account direttamente nelle tabelle users e usermeta quando l'API normale non è disponibile. Memorizza le capacità sotto la chiave meta delle capacità predefinite, nasconde l'account da elenchi utenti, conteggi e viste dei ruoli e forgia cookie di autenticazione validi così che l'operatore possa accedere senza password. Un parametro di richiesta magico, un breve prefisso seguito da un valore fisso, viene gestito prima che WordPress finisca di caricare e restituisce una risposta normale con contenuto prima di uscire. Infine, il payload aggancia un ampio insieme di azioni e filtri per riscrivere ogni altro componente: i drop-in db.php e advanced-cache.php, l'iniezione nel tema, il loader nascosto e le sue direttive di prepend .htaccess e .user.ini, il bundle di ripristino ZIP, il segmento di memoria condivisa e la copia nel database. Apre persino una connessione raw al database per inserire direttamente la sua opzione payload, bypassando WordPress.

La lezione più importante di questo caso è che la persistenza non si limita ai file. Sucuri ha recuperato copie vive del payload in tre posizioni non file, ognuna delle quali ricostruirà l'intero insieme alla richiesta successiva. Il payload completo si trova in una riga della tabella options con un nome casuale, memorizzato nello stesso formato gzip e base64, e advanced-cache.php lo rilegge tramite una connessione diretta al database. Sui server che supportano la memoria condivisa System V, il payload viene scritto in un segmento identificato da una chiave numerica fissa. Quel segmento risiede nella RAM, quindi sopravvive sia alla cancellazione dei file sia alla pulizia del database, e su hosting condiviso può persino appartenere a un account diverso. L'infezione registra anche hook cron, inclusi nomi casuali insieme a un hook di recupero noto. Il cron di sistema esegue il file cron di WordPress, non il traffico dei visitatori, e quindi attiva la ridistribuzione secondo pianificazione. Le varianti SC correlate utilizzano trigger del database che ricreano un amministratore all'inserimento. Un trigger viene eseguito all'interno del database, quindi sopravvive a un ripristino completo dei file e persino alla cancellazione dell'account che continua a ricreare, il che rende inutile la pulizia degli utenti finché il trigger non viene eliminato.

Poiché ogni componente può ricostruire gli altri, l'ordine delle operazioni conta più delle singole eliminazioni. La pulizia raccomandata da Sucuri inizia neutralizzando il prepend prima di eliminare il suo obiettivo. Il valore di auto_prepend_file viene memorizzato nella cache da PHP per un massimo di 300 secondi, quindi svuotare prima il target del prepend trasformandolo in uno stub inerte e poi rimuovere la direttiva da .user.ini, php.ini e .htaccess evita di bloccare ogni richiesta PHP sull'account. Successivamente, cancellare le copie del payload fuori dal disco: rimuovere la riga del payload dalla tabella options, eliminare il segmento di memoria condivisa e cancellare le opzioni di controllo e i transient. Su hosting condiviso, un segmento di memoria condivisa potrebbe appartenere a un altro account, nel qual caso solo quell'account o l'host può rimuoverlo, e diventa innocuo una volta che i drop-in che lo leggono vengono eliminati. Poi rimuovere le attività pianificate e gli eventuali trigger del database: cancellare gli hook cron dannosi e controllare information_schema.TRIGGERS per qualsiasi trigger che ricrei un amministratore all'inserimento. Rimuovere l'amministratore nascosto le cui capacità sono memorizzate sotto la chiave meta delle capacità predefinite e ripulire l'opzione orfana che punta al suo ID. Pulire i file in un'unica passata: rimuovere i loader autonomi e lo shim, eliminare entrambe le copie del finto plugin da mu-plugins e plugins, eliminare il bundle di ripristino ZIP ovunque sia nascosto e rimuovere i drop-in iniettati. Per db.php e advanced-cache.php, eliminare i file dannosi; per il functions.php del tema, tagliare solo il blocco delimitato tra i marcatori begin ed end in modo che il codice legittimo del tema rimanga intatto. Infine, eseguire una scansione completa e monitorare i percorsi interessati. Un componente che ritorna significa che un punto di persistenza è sopravvissuto o che il percorso di ingresso originale è ancora aperto.

Sucuri consiglia di mantenere WordPress e tutti i componenti aggiornati, di usare un web application firewall per bloccare i tentativi di exploit e il traffico di comando in uscita, di controllare la tabella options, le attività pianificate, i trigger del database e gli account utente con una pianificazione regolare e di trattare qualsiasi ricomparsa come segno di un punto di persistenza sopravvissuto. Per i proprietari di siti che desiderano questo tipo di difesa senza doverla mantenere da soli, un piano di hosting WordPress gestito come AEU Hosting può assumersi parte del lavoro di patching e hardening della piattaforma, anche se nessun host può sostituire i passaggi di pulizia sopra descritti.