Il malware SC trasforma la pulizia in trigger di rigenerazione

Il 30 settembre il team di risposta agli incidenti di Sucuri ha pubblicato l'analisi di SC, un malware per WordPress che ridefinisce i parametri della persistenza. SC non si limita a nascondersi: costruisce una rete circolare di almeno otto componenti interdipendenti su file, database e memoria condivisa, dove l'eliminazione di qualsiasi elemento singolo attiva il ripristino di tutti gli altri entro secondi.

Come funziona la mesh circolare di persistenza

L'infezione inizia tipicamente con una direttiva .user.ini che imposta auto_prepend_file verso un loader nascosto in wp-content. Il loader ricostruisce il plugin da copie esistenti, da stub codificato, o da archivio ZIP. Da qui il sistema si espande.

wp-content/db.php contiene il payload completo in formato gzip e base64: se il plugin manca, lo riscrive. wp-content/advanced-cache.php dispone di cinque fonti di recovery: must-use plugin, plugin ordinario, memoria condivisa System V, archivio ZIP, e database. Il tema attivo, attraverso un blocco iniettato in functions.php, funge da nodo aggiuntivo. Il payload è installato simultaneamente come must-use plugin e come plugin convenzionale, con una falsa pagina impostazioni.

La persistenza nel database avviene attraverso una riga in wp_options con nome casuale, contenente il payload compresso. La memoria condivisa System V ospita codice PHP che sopravvive alla cancellazione dei file su disco. Secondo Sucuri, il risultato è "a circular system with no single point you can remove to stop it".

"For SC infections, deleting the visible plugin is not remediation; it is only the event that activates the malware's recovery mechanism"

Il C2 decentralizzato su blockchain Ethereum

Il malware non dipende da domini malevoli bloccabili. Il payload trasporta una lista di circa venti gateway RPC Ethereum pubblici e un set di selettori di metodi per smart contract. Invia richieste a questi gateway per leggere istruzioni cifrate da uno smart contract.

Questa architettura elimina il tradizionale punto di interruzione del C2: non esiste un server da blackholare o un dominio da sequestrare. La fonte non specifica gli indirizzi smart contract esatti. L'uso di infrastruttura pubblica e legittima rende inoltre difficile distinguere il traffico malevolo da quello ordinario a livello di monitoraggio di rete.

La strategia di occultamento e le capacità attive

Il payload filtra la lista plugin, il transient degli aggiornamenti, e le viste plugin del sito e della rete per rimuovere la propria voce. Emette anche JavaScript amministrativo per cancellarsi dalla tabella plugin come misura di fallback. Questo occultamento avviene a livello di presentazione, non di presenza: il codice resta attivo mentre l'amministratore non lo rileva nell'interfaccia.

Tra le capacità documentate: profiling del sito, raccolta di token di sessione amministratore, iniezione JavaScript nel frontend, rimozione di plugin di sicurezza, e skimming di e-commerce. La fonte non quantifica il numero di siti compromessi né le perdite finanziarie confermate. Il vettore di infezione iniziale non è stato determinato.

Perché la rimozione tradizionale è controproducente

La direttiva .user.ini genera una cache PHP che, secondo la fonte secondaria CyberSecurityNews, può durare circa trecento secondi. La rimozione impropria del file causa il fallimento delle richieste PHP per il periodo di cache residue. Questo significa che un tentativo di pulizia parziale o sequenziale esporrebbe il sito a doppio danno: downtime funzionale e rigenerazione completa del backdoor.

Il paradigma operativo richiede uno spostamento radicale. Gli attuali playbook di cleanup file-centrici, basati su identificazione e cancellazione di payload noti, sono strutturalmente inadeguati. Ciò che emerge con chiarezza è l'impossibilità di trattare SC come infezione da "pulire": il sistema infetto deve essere considerato compromesso nella sua interezza.

Cosa fare adesso

Per i team che gestiscono installazioni WordPress, il brief di Sucuri indica tre azioni concrete specifiche al caso SC.

Primo: verificare la presenza della direttiva .user.ini con auto_prepend_file in wp-content, che è il punto di ingresso tipico della persistenza. La sua presenza attiva il loader nascosto e il ciclo di rigenerazione.

Secondo: ispezionare i drop-in wp-content/db.php e wp-content/advanced-cache.php, che contengono rispettivamente il payload completo in gzip+base64 e il meccanismo di recovery a cinque fonti. Questi file legittimi per caching e database sono sovrascritti da SC per funzionare come nodi di bootstrap.

Terzo: controllare il tema attivo, specificamente functions.php, per blocchi iniettati che fungono da nodo di recovery aggiuntivo. Il brief documenta che il tema attivo è un vettore di persistenza attivo, non un target passivo.

La verifica deve coprire tutte e otto le primitive di persistenza prima di qualsiasi azione di remediation: .user.ini, loader nascosto, db.php, advanced-cache.php, iniezione tema, must-use plugin, plugin convenzionale, e memoria condivisa System V. La rimozione sequenziale o parziale attiva il recovery entro secondi.

Perché è importante

Il dossier non specifica come avvenga il primo compromesso, né fornisce indicatori di compromesso invarianti: i nomi file riportati variano per sito. Non documenta la presenza effettiva di database trigger nelle varianti osservate, descritti come presenti in "related variants" ma non confermati per il core SC. La chiave numerica esatta del segmento memoria condivisa System V non è stata rivelata.

Il brief non elenca azioni operative specifiche oltre alla verifica delle primitive. La fonte non descrive metodi di contenimento, procedure di rebuild, o strumenti di rilevamento automatico. Questi limiti rendono il pezzo segnaletico piuttosto che prescrittivo: il valore è nel documentare l'esistenza di una classe di minaccia che rende obsoleti gli approcci di cleanup tradizionali.

L'evoluzione dei threat actor verso persistenza che sfrutta meccanismi legittimi del CMS indica una direzione di ricerca per i vendor di sicurezza e per le organizzazioni che gestiscono flotte WordPress. Il problema non è più la singola infezione: è la topologia di bootstrap del CMS stessa, trasformata in superficie di attacco auto-rigenerante.

Le informazioni sono basate sull'analisi Sucuri citata e aggiornate al momento della pubblicazione.

Fonti

• https://gbhackers.com/sc-wordpress-malware/
• https://cybersecuritynews.com/wordpress-malware-2/
• https://blog.sucuri.net/2026/09/sc-wordpress-malware-a-self-healing-mesh-of-loaders-drop-ins-and-a-blockchain-controlled-backdoor.html
• https://news.cybertechworld.co.in/index.php/2026/10/01/wordpress-backdoor-rebuilds-itself-after-cleanup-using-files-database-and-shared-memory/