A giugno 2026 ho fatto l’analisi forense di un’intrusione reale su un sito WordPress di un cliente. Non un walkthrough da lab, non una macchina di Vulnhub: un sito in produzione, compromesso tramite un plugin di terze parti — il Side Cart per WooCommerce. In questo articolo racconto il metodo che ho seguito: cosa guardare, in che ordine, e cosa ho imparato sulla gestione delle dipendenze in WordPress.
Perché i plugin WooCommerce sono un bersaglio ricorrente
WordPress core, di per sé, ha una superficie di attacco contenuta e un processo di patching abbastanza maturo. Il problema è l’ecosistema dei plugin: migliaia di sviluppatori terzi, qualità del codice molto variabile, e un meccanismo di aggiornamento che richiede comunque un intervento umano (o un cron ben configurato) per essere efficace.
I plugin e-commerce sono bersagli particolarmente attraenti perché spesso gestiscono funzionalità con superficie ampia: upload, gestione carrello, integrazioni con sistemi di pagamento, endpoint AJAX poco testati. Trovare un endpoint AJAX registrato con permessi scricchiolanti è più comune di quanto si vorrebbe.
Step 1: timeline prima di tutto
Il primo errore che si rischia di fare davanti a un’intrusione è iniziare a guardare i file modificati senza prima fissare una finestra temporale di riferimento. La prima cosa che ho fatto è incrociare tre fonti:
- I log del web server (access log e error log), filtrati per pattern sospetti sugli endpoint del plugin compromesso.
- I timestamp di modifica dei file sul filesystem.
- I log applicativi di WordPress e la cronologia delle revisioni dei post/pagine.
Incrociare queste tre fonti permette di costruire una timeline difendibile: non “qualcosa è successo a un certo punto”, ma una sequenza ordinata di eventi su cui costruire il resto dell’analisi.
Step 2: identificare il vettore d’ingresso
Stabilita la finestra temporale, il passo successivo è isolare il vettore. Nel caso specifico, l’analisi degli access log ha mostrato richieste anomale verso endpoint AJAX del plugin, con payload riconducibili a tentativi di file upload non autenticato. Un pattern classico: endpoint AJAX registrato, raggiungibile anche da utenti non autenticati.
Un punto metodologico importante: a questo stadio non serve (e spesso non conviene) fare il reverse engineering completo del codice del plugin per trovare la CVE esatta. Conta di più confermare in fretta se quell’endpoint è stato effettivamente sfruttato, guardando alla risposta del server e agli effetti collaterali: nuovi file, nuovi utenti, modifiche a opzioni critiche.
Step 3: cercare la persistenza
Trovato il vettore, la domanda successiva è: l’attaccante ha lasciato un modo per rientrare? Le aree che controllo sistematicamente:
- Utenti WordPress creati o promossi ad amministratore in finestre temporali sospette.
- File PHP nuovi o modificati fuori dalle directory attese dei plugin/temi — in particolare in
wp-content/uploads, dove l’esecuzione di PHP dovrebbe essere bloccata a livello di webserver (e spesso non lo è). - Modifiche a
wp-config.php,.htaccess, o ai file core di WordPress. - Cron job WordPress registrati per eseguire codice a intervalli — un meccanismo di persistenza elegante perché sopravvive alla rimozione del file malevolo iniziale.
Lezioni pratiche (trasferibili a qualunque sito WordPress)
- Disabilitare l’esecuzione PHP in
wp-content/uploadsa livello di webserver, indipendentemente da cosa fa il plugin. È una mitigazione difensiva indipendente dalla vulnerabilità specifica. - I plugin e-commerce vanno trattati come superficie ad alto rischio: aggiornamenti automatici dove possibile, o quantomeno un monitoraggio attivo degli avvisi di sicurezza specifici per quel plugin.
- I log vanno conservati più a lungo di quanto sembri necessario. Più di un’analisi forense fallisce non per mancanza di competenza, ma perché i log rilevanti sono già stati ruotati e cancellati.
- Backup verificati, non solo configurati. Un backup che non è mai stato testato in restore è un backup che non esiste.
Conclusioni
L’analisi forense su un sito reale è diversa da un walkthrough da lab: non c’è una flag da catturare, c’è un cliente che vuole sapere cosa è successo, da quando, e se è ancora a rischio. Il metodo però è lo stesso — timeline prima di tutto, vettore d’ingresso, ricerca sistematica della persistenza — con la pressione in più di dover essere accurati, non solo veloci.
Stay safe!