Malware WordPress usa i commenti Steam come C2 nascosto con Unicode invisibile

GoDaddy Security scopre una campagna malware che colpisce circa 1980 siti WordPress e utilizza i commenti pubblici dei profili Steam Community come infrastruttura nascosta di comando e controllo. Gli attaccanti abusano della piattaforma di Valve per ospitare dati codificati dentro commenti apparentemente innocui, trasformando un servizio legittimo, popolare e ad alta reputazione in un canale C2 difficile da bloccare con controlli tradizionali. Il malware recupera i commenti dai profili Steam, estrae caratteri Unicode invisibili, ricostruisce payload binari, decodifica eventuali dati compressi e attiva due catene offensive parallele: una lato client, basata sull’iniezione di JavaScript nelle pagine WordPress, e una lato server, fondata su una backdoor PHP autenticata tramite cookie e capace di eseguire modifiche remote su file di plugin e temi. La campagna risulta attiva almeno da luglio 2025 e mostra un livello di sofisticazione superiore rispetto alle classiche infezioni WordPress basate su script offuscati o redirect verso domini sospetti. Qui il C2 non risiede su un server criminale evidente, ma dentro commenti di profili Steam come steamcommunity.com/profiles/76561199096946028, steamcommunity.com/id/ravypadliha, steamcommunity.com/id/enomisvool123/ e steamcommunity.com/id/eremohin342. Questa scelta permette agli attaccanti di aggiornare istruzioni, URL e payload senza modificare direttamente il codice installato sul sito vittima. Il traffico in uscita verso Steam può sembrare legittimo o comunque meno sospetto rispetto a comunicazioni verso domini appena registrati, infrastrutture bulletproof o IP già segnalati. Per i proprietari di siti WordPress il rischio è doppio: il sito compromesso può diventare veicolo di malware verso i visitatori e, allo stesso tempo, può mantenere una backdoor persistente che consente agli attaccanti di modificare codice PHP, alterare plugin, iniettare script esterni e preservare accesso anche dopo tentativi incompleti di pulizia.

La catena recupera i commenti Steam con cURL e cache WordPress

Il malware implementa una funzione dedicata al recupero dei contenuti dai profili Steam Community e utilizza cURL con uno user-agent realistico per simulare richieste plausibili verso la piattaforma. La verifica SSL viene disabilitata, scelta che semplifica il recupero dei dati e riduce possibili problemi di compatibilità durante l’esecuzione su hosting WordPress configurati in modo irregolare. Durante il caricamento delle pagine, il codice malevolo contatta il profilo Steam selezionato e cerca il contenuto all’interno del div con classe commentthread_comment_text, dove gli attaccanti hanno nascosto i payload codificati. Il risultato viene salvato tramite transient WordPress con prefisso caption_ e scadenza di 5 minuti, così da ridurre richieste ripetute, limitare il rumore di rete e mantenere operativo il canale anche in caso di errori temporanei o limitazioni applicate da Steam. Se il fetch non riesce, il malware tenta di riutilizzare la cache precedente, preservando la continuità del comando e controllo.

Questo dettaglio dimostra una progettazione attenta alla resilienza operativa: gli attaccanti non dipendono da una singola richiesta andata a buon fine e possono mantenere attivi payload già recuperati anche quando la comunicazione esterna risulta momentaneamente indisponibile. La tecnica è particolarmente insidiosa perché sfrutta funzioni legittime dell’ecosistema WordPress e le combina con una piattaforma terza credibile. Un amministratore che analizza superficialmente il traffico potrebbe non considerare una richiesta verso Steam come immediatamente malevola, soprattutto se il sito non mostra sintomi evidenti o se l’iniezione JavaScript non si attiva per tutti i visitatori. La presenza di funzioni come Ce8d26cADf211699, richieste verso steamcommunity.com, transient con prefisso caption_ e parsing del div commentthread_comment_text diventa quindi un indicatore cruciale per rilevare l’infezione.

La steganografia Unicode invisibile nasconde payload nei commenti

L’elemento più sofisticato della campagna è l’uso di steganografia Unicode invisibile per occultare payload nei commenti Steam. Gli attaccanti impiegano sei caratteri non visibili, U+200C, U+200D, U+2061, U+2062, U+2063 e U+2064, incorporandoli dentro testi che appaiono normali agli utenti e ai controlli manuali. Il decoder del malware elimina prima tutti i caratteri visibili usati come decoy, poi mappa ogni carattere invisibile a un valore compreso tra 0 e 5. Questi valori vengono convertiti in sequenze binarie da 2 bit per carattere, ricostruiti in byte e sottoposti a operazione bitwise NOT. Se necessario, il codice tenta infine una decompressione gzip per ottenere il contenuto finale. Il risultato è un canale C2 nascosto dentro testo pubblico che può sembrare una conversazione ordinaria su Steam, ma in realtà trasporta URL, istruzioni operative o configurazioni da applicare ai siti WordPress compromessi.

Questa tecnica rende inefficace gran parte dell’analisi visiva: un commento può apparire vuoto, casuale o innocuo, mentre contiene dati binari recuperabili solo dal decoder corretto. La scelta di caratteri Unicode invisibili introduce anche un problema per scanner e filtri che non normalizzano correttamente il testo o che non ispezionano sequenze non stampabili all’interno di contenuti pubblici. Il malware può così sfruttare una piattaforma legittima come deposito dinamico di configurazioni senza ospitare file direttamente riconoscibili come malevoli. In termini operativi, la combinazione tra commenti Steam, Unicode invisibile e caching WordPress crea un’infrastruttura C2 economica, distribuita e difficile da distinguere dal traffico legittimo, con un vantaggio ulteriore: gli attaccanti possono aggiornare i comandi modificando un commento sul profilo Steam, senza toccare i file già presenti sui siti infetti.

AES-256-CTR, PBKDF2 e HMAC proteggono il canale nascosto

Il malware supporta anche un livello opzionale di crittografia che aumenta ulteriormente la difficoltà di analisi. Quando questa protezione è attiva, il payload nascosto nei commenti Steam viene trattato con AES-256-CTR, derivazione chiave tramite PBKDF2 e autenticazione HMAC per garantire integrità e riservatezza dei comandi. La scelta di CTR consente di cifrare e decifrare flussi in modo efficiente, mentre PBKDF2 rende più robusta la generazione della chiave a partire da materiale segreto incorporato nel malware. HMAC permette invece di verificare che il payload non sia stato alterato o corrotto prima dell’esecuzione. Questa architettura rende quasi inutile una semplice copia dei commenti Steam da parte di un analista: senza conoscere la chiave e la logica implementativa, il contenuto resta opaco. La steganografia nasconde l’esistenza del payload, la crittografia ne protegge il significato, e l’autenticazione impedisce modifiche non autorizzate. Dal punto di vista difensivo, questo obbliga i team di sicurezza a concentrarsi non solo sul contenuto recuperato da Steam, ma anche sul codice presente nel sito WordPress, sulle funzioni di decodifica, sulle chiamate cURL, sugli hook WordPress e sugli artefatti persistenti. L’uso combinato di tecniche normalmente associate a malware più avanzati mostra che la compromissione WordPress non può più essere trattata come semplice problema di defacement o spam SEO. Un sito WordPress infetto può ospitare un implant capace di recuperare comandi cifrati, interpretarli dinamicamente, modificare codice PHP e servire script malevoli ai visitatori. La campagna rilevata da GoDaddy Security mostra quindi una convergenza tra tecniche di web malware, steganografia, abuso di piattaforme legittime e backdoor server-side.

La catena client-side inietta JavaScript esterno nelle pagine

Dopo aver decodificato il contenuto nascosto nei commenti Steam, il malware può attivare la catena lato client e inserire JavaScript esterno nelle pagine del sito compromesso. La funzione WordPress wp_enqueue_script() viene usata per registrare e caricare uno script con handle asahi-jquery-min-bundle, una denominazione studiata per confondersi con normali librerie frontend o bundle jQuery. Lo script viene servito su tutte le pagine del sito e può eseguire redirect, furto di dati, fingerprinting dei visitatori, ulteriore iniezione di codice o distribuzione di payload aggiuntivi. L’iniezione avviene in modo trasparente per amministratori e utenti finali, soprattutto se il codice non altera immediatamente l’aspetto del sito o si attiva solo in determinate condizioni. Questo trasforma ogni sito WordPress compromesso in un punto di distribuzione malevolo, capace di colpire i visitatori senza che questi abbiano alcun rapporto diretto con gli attaccanti. La scelta di usare wp_enqueue_script() è significativa perché sfrutta il meccanismo legittimo con cui WordPress gestisce gli asset frontend. Invece di inserire semplicemente un tag script sospetto in modo grezzo, il malware si integra nel flusso del CMS e rende l’iniezione più difficile da distinguere da quella prodotta da temi o plugin. La presenza dell’handle asahi-jquery-min-bundle, richieste verso script esterni non riconosciuti e modifiche anomale nella coda degli asset diventano indicatori importanti durante l’analisi. Per i proprietari dei siti, il danno reputazionale può essere rilevante: un portale compromesso può infettare utenti, reindirizzare traffico verso pagine fraudolente, distribuire malware o partecipare a campagne di malvertising, anche se i contenuti editoriali o commerciali del sito restano apparentemente invariati.

La backdoor PHP usa cookie nelle richieste POST per eseguire codice

Oltre alla catena client-side, il malware installa una backdoor server-side capace di ricevere comandi autenticati tramite cookie e modificare file PHP. Il codice aggancia l’azione template_redirect di WordPress, intercetta richieste POST e controlla la presenza di cookie specifici. Se l’autenticazione risulta valida, la backdoor può rispondere a un comando ping oppure eseguire operazioni più invasive, come ricevere codice PHP codificato in base64, cercare porzioni specifiche nei file e sostituirle con nuovi blocchi malevoli. Questo meccanismo consente agli attaccanti di modificare plugin e temi già presenti, evitando la creazione di file nuovi che potrebbero essere rilevati più facilmente da scanner di integrità superficiali. La possibilità di alterare codice esistente rende la persistenza più robusta: anche se l’amministratore cancella uno script sospetto o ripristina una parte del sito, altri file PHP compromessi possono riattivare la catena. L’uso di cookie come meccanismo di autenticazione permette inoltre agli operatori di distinguere le proprie richieste da quelle ordinarie, riducendo il rischio di esecuzione accidentale o di scoperta immediata. La backdoor può operare su qualsiasi file accessibile dal processo del web server, quindi il rischio dipende dai permessi assegnati all’utente con cui gira PHP. Se il sito consente scrittura ampia su directory di plugin e temi, gli attaccanti possono mantenere un controllo profondo sull’installazione. Indicatori come hook sospetti su template_redirect, gestione anomala di cookie nelle richieste POST, codice base64, funzioni di ricerca e sostituzione nei file PHP e riferimenti all’handle asahi-jquery-min-bundle devono essere analizzati con priorità. La bonifica non può limitarsi alla rimozione dello script visibile: serve verificare file core, plugin, temi, transient, cron, utenti amministrativi e permessi filesystem.

La campagna attiva dal 2025 mostra una compromissione su larga scala

GoDaddy Security traccia la campagna almeno da luglio 2025 e identifica circa 1980 installazioni WordPress infette, un numero che indica un’operazione persistente e distribuita su scala globale. Gli attaccanti non sembrano concentrarsi su un singolo settore, ma sfruttano la diffusione di WordPress per massimizzare la superficie d’attacco. Il vettore iniziale non viene indicato con certezza, ma la dinamica è compatibile con l’abuso di vulnerabilità note in plugin e temi, credenziali rubate, pannelli amministrativi deboli o hosting non aggiornati. Ogni sito compromesso diventa un nodo della campagna, capace di recuperare comandi da Steam, iniettare JavaScript e mantenere una backdoor server-side. L’uso di profili Steam come deposito di payload aggiorna il modello tradizionale di C2: gli attaccanti non devono mantenere server dedicati, non devono esporre domini sospetti e possono spostare rapidamente istruzioni operative modificando commenti pubblici. Questa resilienza rende più difficile interrompere l’intera campagna. Anche se un sito viene pulito, gli altri restano operativi; anche se un profilo Steam viene rimosso o moderato, gli attaccanti possono spostare i payload su un altro profilo. La strategia è particolarmente efficace contro siti con manutenzione debole, plugin obsoleti e monitoraggio assente del traffico outbound. Molti amministratori WordPress concentrano l’attenzione sulle richieste in ingresso e sugli accessi al pannello admin, ma raramente verificano che il server contatti piattaforme esterne come Steam Community durante il rendering delle pagine. Questa lacuna operativa permette al malware di restare invisibile per mesi.

Gli indicatori tecnici permettono di rilevare l’infezione

Gli indicatori pubblicati da GoDaddy Security offrono una base concreta per identificare siti compromessi. Tra i segnali più rilevanti compaiono la funzione Ce8d26cADf211699, l’uso di transient WordPress con prefisso caption_, richieste cURL verso Steam Community, parsing del div commentthread_comment_text, hook su template_redirect, controllo di cookie specifici nelle richieste POST, codice PHP codificato in base64 e riferimenti allo script handle asahi-jquery-min-bundle. I proprietari di siti devono inoltre cercare caratteri Unicode invisibili nei dati recuperati, controllare eventuali modifiche recenti nei file di plugin e temi, verificare script esterni caricati tramite wp_enqueue_script() e analizzare traffico outbound verso steamcommunity.com. La detection deve combinare ricerca statica e analisi comportamentale. Una semplice scansione antivirus può non bastare se il payload principale viene recuperato dinamicamente da Steam e decodificato solo a runtime. È utile controllare i log web per richieste POST anomale con cookie sospetti, confrontare i file del sito con versioni pulite, disabilitare temporaneamente plugin non essenziali e rimuovere transient malevoli dal database. Gli amministratori dovrebbero anche verificare utenti WordPress, chiavi API, cron job, permessi di scrittura e modifiche non autorizzate ai temi attivi. In presenza di backdoor PHP capaci di riscrivere file, la bonifica più sicura può richiedere il ripristino da backup pulito, seguito da aggiornamento completo di CMS, plugin e temi. L’analisi deve includere anche il database, perché transient e opzioni possono contenere cache malevole o configurazioni persistenti.

La difesa richiede aggiornamenti, controllo outbound e integrità dei file

La mitigazione della campagna passa da una combinazione di aggiornamenti, hardening e monitoraggio. Gli amministratori devono aggiornare WordPress, plugin e temi alle versioni più recenti, rimuovere componenti inutilizzati, cambiare tutte le password, rivedere gli account amministrativi e controllare permessi filesystem per limitare la possibilità del web server di modificare file PHP non necessari. È consigliabile implementare un Web Application Firewall, attivare strumenti di file integrity monitoring, controllare le modifiche ai file di plugin e temi, cancellare transient sospetti e bloccare o limitare richieste cURL verso domini esterni non indispensabili. Il traffico outbound deve diventare parte della sicurezza WordPress: un sito che non ha ragione di contattare Steam Community non dovrebbe generare chiamate server-side verso profili Steam durante il caricamento delle pagine. Dopo la rimozione dell’infezione, è necessario invalidare credenziali potenzialmente esposte, rigenerare chiavi sali di WordPress, controllare accessi FTP/SFTP, pannelli hosting e database. La prevenzione resta decisiva perché la bonifica di un malware con backdoor server-side e C2 dinamico può essere complessa. Plugin abbandonati, temi pirata, password deboli e hosting non segmentati aumentano enormemente il rischio. La campagna mostra inoltre che la reputazione delle piattaforme terze non deve essere considerata garanzia di sicurezza: Steam non è compromessa nel senso tradizionale, ma i suoi profili pubblici vengono abusati come spazio di archiviazione per comandi malevoli. Questo modello potrebbe essere replicato su altre piattaforme con contenuti utente pubblici, commenti, bio o descrizioni modificabili.

Steam come C2 dimostra l’evoluzione dell’abuso di piattaforme legittime

La campagna analizzata da GoDaddy Security dimostra come gli attaccanti stiano spostando il comando e controllo verso piattaforme legittime difficili da bloccare senza generare falsi positivi o impatti sugli utenti. L’uso dei commenti Steam Community come contenitore di payload nascosti con Unicode invisibile rappresenta un’evoluzione creativa dell’abuso di servizi pubblici. La piattaforma di Valve non è responsabile della compromissione dei siti WordPress, ma diventa un elemento della catena offensiva perché consente agli attaccanti di pubblicare contenuti accessibili, aggiornabili e ospitati su un dominio ad alta reputazione. Per i siti infetti, le conseguenze possono includere furto di dati, redirect verso landing page malevole, infezione dei visitatori, alterazione dei file PHP e persistenza a lungo termine. Per la comunità di sicurezza, il caso indica una direzione più ampia: controllare soltanto domini sconosciuti non basta più. Bisogna analizzare comportamenti anomali anche quando coinvolgono servizi legittimi, soprattutto se un server WordPress effettua richieste insolite verso profili social, piattaforme gaming, repository pubblici o servizi di paste. La combinazione tra steganografia, crittografia, cURL, cache WordPress, iniezione JavaScript e backdoor PHP autenticata tramite cookie rende questo malware uno degli esempi più interessanti di abuso C2 su piattaforme pubbliche nel 2026. La lezione operativa è chiara: ogni sito WordPress deve essere trattato come infrastruttura applicativa critica, non come semplice CMS da aggiornare occasionalmente.