Hacker scatenati contro WordPress e Joomla: come una singola falla regala il controllo del tuo server

🛡️ Executive Summary

• Gli aggressori sfruttano vulnerabilità note nei CMS per caricare webshell e mantenere accesso persistente ai server compromessi.
• La campagna colpisce plugin WordPress, Craft CMS, MaxSite, MetInfo e Joomla JCE, con forte impatto sulle PMI.
• Le difese richiedono patch immediate, verifica dell’integrità dei file, isolamento dei server compromessi e analisi dei log.

Una campagna di sfruttamento su larga scala sta prendendo di mira sistemi di gestione dei contenuti esposti su Internet, con attività osservate a livello globale e un impatto particolarmente rilevante sulle piccole e medie imprese australiane. Gli aggressori eseguono scansioni automatizzate alla ricerca di installazioni vulnerabili, sfruttano difetti già noti e distribuiscono webshell capaci di garantire accesso remoto persistente ai server. Le vulnerabilità coinvolte comprendono upload non autenticati, Remote Code Execution, Server-Side Request Forgery e deserializzazione insicura, tutte condizioni che possono consentire l’esecuzione di codice o il caricamento di file arbitrari. Dopo la compromissione, i server vengono utilizzati per defacement, furto di credenziali, distribuzione di malware, esfiltrazione di dati e movimenti laterali verso reti interne. L’operazione evidenzia la riduzione della finestra tra pubblicazione di una falla e sfruttamento attivo, fenomeno che le agenzie dei Five Eyes collegano anche all’impiego crescente dell’intelligenza artificiale per automatizzare ricognizione, sviluppo degli exploit e selezione dei bersagli.

Gli aggressori trasformano i CMS esposti in punti di accesso persistenti

I siti web rappresentano un bersaglio privilegiato perché operano all’esterno del perimetro aziendale, accettano input non fidato e spesso comunicano con database, sistemi di autenticazione, archivi documentali o applicazioni interne. La campagna sfrutta vulnerabilità pubblicamente documentate per ottenere un primo accesso e depositare una webshell nelle directory accessibili dal server web. Una webshell è uno script, frequentemente scritto in PHP, ASP, JSP o linguaggi equivalenti, che permette di inviare comandi al sistema operativo attraverso richieste HTTP. Una volta installato, il file può apparire come un componente legittimo del CMS, imitare nomi di plugin o essere nascosto in directory utilizzate per upload, cache e contenuti multimediali. L’attaccante può quindi eseguire comandi, caricare nuovi payload, modificare pagine, interrogare il database e creare ulteriori meccanismi di persistenza. La semplicità operativa rende le webshell particolarmente efficaci nelle campagne di massa: anche quando l’exploit iniziale viene corretto, il file malevolo già presente continua a garantire accesso finché non viene individuato e rimosso.

Upload arbitrario e RCE riducono drasticamente la barriera d’ingresso

Le vulnerabilità più sfruttate consentono il caricamento non autenticato di file o l’esecuzione remota di codice senza richiedere credenziali amministrative. Nei plugin vulnerabili, un endpoint destinato alla gestione di immagini, backup, file audio o moduli può accettare contenuti controllati dall’attaccante senza validare correttamente estensione, tipo MIME, percorso o autorizzazioni. Un file PHP caricato nella directory pubblica diventa immediatamente eseguibile dal server, trasformando una singola richiesta HTTP in una compromissione completa. Le vulnerabilità RCE producono un risultato simile attraverso command injection, template injection o chiamate insicure a funzioni di sistema. Anche la deserializzazione di oggetti non attendibili può attivare catene di gadget che portano all’esecuzione di codice, mentre una SSRF può essere utilizzata per raggiungere servizi interni, endpoint cloud o interfacce amministrative non accessibili da Internet. In una campagna automatizzata, gli aggressori combinano scanner, fingerprinting delle versioni e payload specifici per ogni componente, passando rapidamente dalla ricognizione al deployment della webshell.

WordPress concentra il maggior numero di plugin vulnerabili

Una parte rilevante dell’attività interessa WordPress, soprattutto attraverso plugin con vulnerabilità note e installazioni rimaste prive di aggiornamenti. Tra i componenti osservati figurano Simple File List, WavePlayer, BerqWP, WPBookit, Ninja Forms, ThemeREX Addons, Breeze Cache, pay-uz, ACF Extended, Sneeit Framework, WPvivid Backup, Gravity Forms e GutenKit/Hunk Companion. La presenza di plugin differenti mostra che la campagna non dipende da una singola falla, ma da una strategia opportunistica basata sull’intero ecosistema. Gli aggressori cercano qualsiasi componente in grado di fornire upload arbitrario, bypass dell’autenticazione o esecuzione di codice, adattando il payload all’istanza rilevata. WordPress è particolarmente esposto perché molti siti utilizzano estensioni di terze parti mantenute con frequenze differenti e amministrate da organizzazioni prive di processi formali di vulnerability management. Un plugin inutilizzato ma ancora installato può rimanere raggiungibile e offrire lo stesso punto di ingresso di un componente attivo, rendendo essenziale la rimozione delle estensioni non necessarie oltre al semplice aggiornamento.

Craft CMS, MaxSite, MetInfo e Joomla ampliano la superficie della campagna

L’operazione non è limitata a WordPress. Gli aggressori prendono di mira anche Craft CMS, MaxSite CMS, MetInfo CMS e il componente Joomla JCE, dimostrando una capacità di adattamento verso piattaforme con quote di mercato inferiori ma spesso utilizzate in contesti aziendali specifici. I CMS meno diffusi possono presentare un rischio elevato quando vengono gestiti da fornitori esterni, installati per progetti legacy o esclusi dai normali processi di inventario. In molti casi l’organizzazione conosce il dominio pubblico ma non dispone di visibilità completa sulla versione del CMS, sui plugin installati o sul soggetto responsabile del patching. Questo divario operativo permette agli attaccanti di sfruttare vulnerabilità anche mesi dopo la pubblicazione della patch. La presenza di Joomla JCE conferma inoltre l’interesse verso editor e file manager che gestiscono upload e contenuti multimediali, componenti particolarmente sensibili perché devono scrivere direttamente nelle directory del sito. La campagna privilegia quindi software capace di modificare il filesystem o elaborare input complessi provenienti da utenti remoti.

Le webshell abilitano defacement, furto di credenziali e movimento laterale

Dopo l’accesso iniziale, gli aggressori possono utilizzare il server compromesso per attività differenti in base al valore del bersaglio. Nei casi più semplici modificano le pagine pubbliche per effettuare defacement, distribuire propaganda o reindirizzare gli utenti verso siti fraudolenti. In altri scenari raccolgono file di configurazione contenenti password di database, chiavi API, token SMTP, credenziali cloud o segreti utilizzati dalle applicazioni. I dati sottratti possono consentire l’accesso a pannelli amministrativi, servizi di posta, repository e infrastrutture esterne. Un server web connesso alla rete aziendale può inoltre diventare un punto di pivot verso sistemi interni, soprattutto quando non esiste una segmentazione rigorosa tra zona pubblica e backend. Gli attaccanti possono installare strumenti di tunneling, proxy, miner di criptovalute, bot per attacchi DDoS o payload ransomware. La webshell fornisce infine un’infrastruttura affidabile per ospitare phishing, malware e redirect, sfruttando la reputazione di un dominio legittimo per aggirare filtri e controlli di sicurezza.

I segnali di compromissione emergono nei file, nei log e nei processi

Il rilevamento richiede la correlazione di indicatori presenti su livelli differenti. Sul filesystem devono essere analizzati file nuovi o modificati nelle directory dei plugin, degli upload, della cache e dei temi, soprattutto quando utilizzano nomi insoliti, estensioni doppie o codice offuscato. Nei log del server web possono comparire richieste GET o POST verso percorsi mai osservati, file PHP all’interno di cartelle multimediali o parametri contenenti comandi, stringhe codificate e payload compressi. Un ulteriore indicatore è la generazione di processi figlio inattesi da parte di Apache, Nginx, PHP-FPM, IIS o dell’interprete applicativo. L’avvio di shell, utility di rete, strumenti di compressione, PowerShell, curl o wget da un processo web deve essere considerato altamente sospetto. Sul piano di rete, le connessioni in uscita verso indirizzi non autorizzati possono indicare comando e controllo, download di malware o esfiltrazione. Devono essere ricercati anche account amministrativi creati di recente, task pianificati, chiavi SSH non riconosciute e modifiche alle configurazioni del CMS.

Un server con webshell deve essere considerato completamente compromesso

La semplice eliminazione del file malevolo non garantisce il ripristino della sicurezza. Una webshell offre all’attaccante la possibilità di creare altri account, modificare il codice applicativo, installare backdoor aggiuntive, sottrarre credenziali e alterare i log. Qualsiasi server sul quale venga individuato un simile artefatto deve quindi essere isolato dalla rete, sottoposto ad acquisizione forense e ricostruito a partire da immagini o backup verificati. Le credenziali presenti sul sistema devono essere considerate compromesse e sostituite, incluse password del database, chiavi API, token di integrazione, account amministrativi e segreti cloud. Prima del ripristino è necessario identificare la vulnerabilità iniziale, applicare la patch e verificare che lo stesso difetto non sia presente su altre istanze. I backup devono essere controllati per evitare di reintrodurre file malevoli già esistenti al momento della copia. L’analisi dovrebbe inoltre estendersi ai sistemi interni raggiungibili dal server, cercando segnali di movimento laterale, autenticazioni anomale e connessioni originate dall’host compromesso.

Directory in sola lettura e application control riducono il rischio operativo

Oltre al patching, le organizzazioni possono limitare l’impatto configurando in sola lettura le directory che non richiedono modifiche durante l’esecuzione. I processi web dovrebbero avere permessi di scrittura esclusivamente sulle cartelle strettamente necessarie, evitando che un exploit possa depositare file eseguibili nell’intera document root. Le directory di upload dovrebbero impedire l’esecuzione di script attraverso configurazioni del server web, policy del sistema operativo o separazione su storage dedicato. Strumenti di application control possono bloccare la generazione di shell e processi non autorizzati da parte del web server, mentre soluzioni EDR e File Integrity Monitoring possono rilevare modifiche sospette al codice pubblicato. Una Web Application Firewall può ridurre l’esposizione a exploit noti, ma non sostituisce l’aggiornamento dei componenti e deve essere configurata tenendo conto delle specifiche applicazioni. La segmentazione di rete deve infine limitare le comunicazioni tra i server pubblici e i dispositivi interni, consentendo solo i flussi necessari verso database e servizi backend.

L’intelligenza artificiale comprime i tempi tra disclosure e sfruttamento

Le agenzie di cybersicurezza dei Five Eyes hanno evidenziato come l’AI possa accelerare diverse fasi delle operazioni offensive. I modelli possono aiutare a interpretare advisory, analizzare patch, generare varianti di exploit, adattare scanner e produrre payload per piattaforme differenti. L’impatto principale non consiste necessariamente nella creazione di tecniche completamente nuove, ma nella riduzione del tempo e delle competenze necessarie per automatizzare attività già note. Una vulnerabilità pubblicata può essere trasformata rapidamente in un modulo di scansione e sfruttamento distribuito su larga scala, comprimendo la finestra disponibile per gli amministratori. Le organizzazioni che applicano aggiornamenti con cadenza mensile o trimestrale rischiano quindi di rimanere esposte durante il periodo più critico. I CMS e i plugin accessibili da Internet devono essere inseriti in processi di patching prioritari, con inventario aggiornato, notifiche automatiche e procedure di emergenza per le vulnerabilità che consentono accesso non autenticato o esecuzione remota di codice.

Inventario e responsabilità dei fornitori diventano controlli essenziali

La campagna colpisce soprattutto le PMI perché molte affidano siti e applicazioni a provider esterni senza definire chiaramente chi debba gestire aggiornamenti, monitoraggio e risposta agli incidenti. È necessario mantenere un inventario dei domini, dei CMS, dei plugin, delle versioni e dei responsabili operativi, includendo anche siti promozionali, portali legacy e ambienti di test. I contratti con web agency e managed service provider dovrebbero stabilire tempi di patching, requisiti di logging, modalità di segnalazione degli incidenti e procedure di ripristino. Le organizzazioni che non amministrano direttamente il server devono inoltrare l’avviso al fornitore e richiedere una verifica documentata delle vulnerabilità, dei file sospetti e dei log. Senza una responsabilità esplicita, un componente obsoleto può restare online per anni e diventare un accesso permanente alle infrastrutture aziendali. La difesa efficace richiede quindi una combinazione di patch rapide, hardening, monitoraggio continuo e governance dei servizi esposti, perché una singola webshell può trasformare un sito periferico nel punto di partenza di una compromissione molto più estesa.