Il malware WordPress torna? Controlla WP-Cron e mu-plugins

Se il malware WordPress torna dopo una pulizia, registra esattamente che cosa è ricomparso e quando. Potrebbe esserci codice rimasto attivo, un accesso ancora utilizzabile o un componente vulnerabile. Un vecchio risultato di Google o una cache, invece, possono far sembrare attuale un problema già corretto.

Questa guida si concentra su tre controlli spesso trascurati: eventi WP-Cron, plugin obbligatori e altre installazioni nello stesso account. Integra il metodo completo di bonifica; una singola anomalia non identifica automaticamente la causa.

Prima prova: è tornato un file o soltanto il sintomo?

Annota il percorso completo del file, una sua impronta SHA-256 e l'orario della nuova osservazione, con fuso. Conserva il contenuto senza eseguirlo. Confrontalo con la copia precedente: stesso nome e stesso contenuto sono informazioni diverse.

Se osservi soltanto un redirect, ripeti il controllo fuori dalla sessione amministrativa e confronta le risposte di origine e cache con l'assistenza. Se il sintomo è uno snippet spam in ricerca, verifica la risposta attuale dell'URL come spiegato nella guida alle pagine spam su Google.

Le date dei file orientano l'indagine, ma possono essere alterate o cambiare durante un ripristino. Per attribuire una scrittura servono altre evidenze, come richieste HTTP, processi o log di accesso correlati.

Prepara una copia controllata

Prima di cancellare altro, conserva file, database e log con backup verificato. Evita di aprire un file sospetto attraverso il browser: se è eseguibile, la richiesta potrebbe attivarlo.

Lavora su una copia isolata quando devi caricare WordPress o analizzare comportamenti. Una normale copia di staging non è automaticamente isolata: potrebbe ancora inviare email, chiamare servizi esterni o usare chiavi di produzione. La guida allo staging per la bonifica descrive la preparazione dell'ambiente.

1. Elenca gli eventi WP-Cron senza avviarli

WP-Cron gestisce attività programmate di core e plugin. Secondo la documentazione WordPress, il suo funzionamento ordinario dipende dalle richieste al sito: una ricomparsa “dopo una visita” non prova da sola un legame con uno specifico evento.

Su una copia controllata, questo comando elenca gli eventi:

wp cron event list --fields=hook,next_run_gmt,recurrence --format=table

È un comando di elenco, non di esecuzione degli eventi. L'avvio di WP-CLI può però caricare codice del sito. Il parametro --skip-plugins non esclude i mu-plugins, come precisa la documentazione del comando. Non usarlo come garanzia di isolamento su un'installazione compromessa.

Per ogni evento che non riconosci chiedi:

• quale componente registra il nome dell'hook;
• quale funzione viene collegata a quell'hook;
• che cosa fa quella funzione e quali file include;
• se il componente è presente, autorizzato e della versione attesa;
• quali riscontri collegano l'attività al file ricomparso.

Un hook sconosciuto potrebbe appartenere a un plugin legittimo. La guida alla programmazione degli eventi segnala anche che eventi possono restare dopo la rimozione di un plugin. Un evento residuo privo della funzione che lo esegue non è, da solo, una backdoor.

Non premere “Esegui ora” per vedere cosa accade. Prima analizza il codice e gli argomenti in un ambiente adatto.

2. Controlla i mu-plugins e i loro file inclusi

I mu-plugins, o plugin obbligatori, vengono caricati automaticamente e non si disattivano dalla normale lista dei plugin. La documentazione ufficiale spiega che WordPress carica i file PHP direttamente nella cartella dedicata; un file principale può poi includerne altri in sottocartelle.

La posizione predefinita è wp-content/mu-plugins, ma può essere personalizzata. Fai l'inventario del percorso effettivo e segui gli include dei file principali. Per ciascun elemento registra chi lo ha installato, perché serve e dove reperire una copia originale.

Hosting e agenzie possono usare legittimamente questa cartella per cache, compatibilità e manutenzione. Non cancellarla in blocco: potresti interrompere servizi necessari.

Il nome “security”, “cache” o “optimizer” non certifica il contenuto. Confronta il file con la versione fornita dal manutentore e indaga eventuali scritture inattese, connessioni o codice non attribuito. Se trovi una modifica malevola, documenta anche come il file è arrivato in quella posizione.

3. Distingui cron di sistema e altre code

Un'attività pianificata dal pannello hosting non compare necessariamente nell'elenco WP-Cron. Controlla la sezione Cron Jobs dell'account e chiedi al provider quali pianificazioni aggiuntive siano pertinenti.

Annota comando, percorso, frequenza e proprietario. Un percorso verso un vecchio staging merita verifica; non basta che il nome contenga “backup” per considerarlo affidabile.

Su siti WooCommerce può essere presente Action Scheduler, con una propria coda di attività. La documentazione del progetto descrive esecuzione e registri delle azioni. La sua presenza non indica malware: verifica chi registra l'azione e che cosa esegue.

Sospendere indiscriminatamente cron e code può fermare pubblicazioni, sincronizzazioni o attività commerciali. Concorda un contenimento mirato e controlla poi la ripresa delle attività legittime.

4. Cerca copie dimenticate e accessi ancora validi

Una pulizia limitata al dominio principale lascia fuori possibili sorgenti nello stesso account. Elenca staging, sottodomini, copie di test e vecchie installazioni. Verifica quali sono raggiungibili e quali processi possono scrivere nei file del sito.

Non attribuire automaticamente la reinfezione a un altro sito: controlla separazione dei permessi e log. Se l'account è condiviso, coinvolgi il provider per ricostruire la portata effettiva.

Rivedi anche utenti WordPress, accessi hosting, SSH/SFTP, password applicative e integrazioni autorizzate. Per la parte amministrativa usa la guida agli utenti admin sconosciuti. Aggiornare i componenti e revocare accessi esposti deve accompagnare la rimozione delle persistenze individuate.

Una scheda per verificare la correzione

Per ciascun elemento investigato conserva quattro informazioni:

1. Evidenza: file, hook o richiesta osservata, con orario e impronta quando utile.
2. Attribuzione: componente o accesso responsabile, oppure “non determinabile”.
3. Correzione: modifica applicata e copia originale conservata.
4. Verifica: controllo successivo sul file e sull'attività che lo produceva.

Ripeti i controlli dopo visite, attività pianificate e operazioni ordinarie pertinenti. Non provocare l'esecuzione di codice sospetto in produzione. La sola assenza del sintomo per qualche ora non dimostra che tutti gli accessi siano chiusi.

Se la sorgente resta incerta, il servizio di bonifica malware permette di analizzare file, database e persistenze con un report documentato.