File PHP in wp-content/uploads: sono malware? Come verificarli

Un file PHP in wp-content/uploads merita una verifica, ma la sua estensione non basta a dichiararlo malware. Il percorso è normalmente destinato ai media; alcuni componenti possono però creare file accessori. Occorre attribuire il file a una funzione legittima oppure documentarne il comportamento sospetto.

Se un report del provider indica un percorso preciso, conservalo integralmente. Se indica soltanto una firma, il decoder dei segnali di compromissione aiuta a capirne il significato; non sostituisce l'analisi del file.

Perché uploads è una posizione da controllare

WordPress usa una directory di caricamento configurabile, spesso suddivisa per anno e mese. La documentazione di wp_upload_dir() descrive percorso, URL e possibilità di personalizzazione. Non presumere quindi che tutte le installazioni usino la stessa posizione.

Un eseguibile collocato tra le immagini può essere poco visibile a chi controlla soltanto plugin e temi. Il rischio dipende anche da come il server tratta quel percorso: un file potrebbe essere eseguito tramite una richiesta diretta oppure incluso da altro codice.

Il fatto che non compaia nella Libreria media non risolve il dubbio. La Libreria mostra elementi registrati nel database; non è un inventario completo dei file presenti sul disco.

1. Raccogli un inventario senza aprire gli script

Annota percorso, dimensione, proprietario, permessi, data osservata e impronta del file. Conserva il report che lo ha segnalato. Prima di spostare o cancellare qualcosa prepara una copia verificata di file e database, fuori dall'area pubblica.

Se hai SSH e conosci il percorso effettivo, questi sono esempi di sola lettura, da eseguire dalla directory corretta:

find wp-content/uploads -type f -iname '*.php' -print
sha256sum wp-content/uploads/percorso/file-sospetto.php

Il secondo percorso è un segnaposto: sostituiscilo soltanto dopo aver individuato il file. Non eseguire il contenuto con PHP e non richiamarne l'URL dal browser.

La ricerca per estensione trova candidati, non certifica che il resto sia pulito. Possono esserci altre estensioni eseguibili, nomi ingannevoli, collegamenti o contenuti richiamati da altri file. Una scansione deve dichiarare il proprio perimetro.

2. Attribuisci il file prima di classificarlo

Per ciascun candidato rispondi a quattro domande:

• Chi lo ha creato? Plugin, tema, sistema di backup, manutentore o sorgente ancora sconosciuta?
• Dove dovrebbe trovarsi? Il produttore documenta quel percorso e quella funzione?
• È identico all'originale? Esiste un pacchetto ufficiale della stessa versione con cui confrontarlo?
• Che cosa fa? Gestisce una funzione attesa oppure permette operazioni non autorizzate?

Un index.php che contiene soltanto un commento può avere uno scopo diverso da uno script che riceve parametri e modifica file. Anche un nome rassicurante può però nascondere contenuti alterati: leggi l'intero file come testo, senza avviarlo, e segui le dipendenze pertinenti.

Le date non dimostrano da sole l'origine. Un ripristino può modificarle e un attaccante può alterarle. Se non trovi un produttore o un riscontro nei log, classifica l'attribuzione come “non determinabile”.

3. Valuta codice e comportamento insieme

Elementi che richiedono approfondimento includono comandi ricevuti da richieste esterne, scrittura arbitraria di file, gestione di account non prevista o connessioni non attribuite. Il giudizio deve considerare la funzione completa e il contesto.

Una stringa come base64_decode può essere usata anche da codice legittimo. Un file corto può essere dannoso; uno lungo e compresso può appartenere a un componente noto. Per questo una ricerca per parola chiave non equivale a una bonifica.

Confronta l'impronta del file con le evidenze raccolte, le richieste al suo percorso e gli eventi dell'account hosting. La sola presenza di una richiesta HTTP non prova che l'esecuzione sia riuscita: registra anche risposta e riscontri disponibili.

La nostra guida ai report degli scanner e ai falsi positivi spiega come separare un rilevamento da una conclusione verificata.

4. Contieni un file malevolo conservandone la copia

Quando la valutazione identifica codice malevolo, documenta l'evidenza prima della rimozione. Conserva una copia in un'area non pubblica, con accesso ristretto e senza possibilità di eseguirla nel normale sito.

Rinominare file.php in file.php.bak dentro uploads non è una quarantena adeguata: il contenuto potrebbe diventare scaricabile e un altro script potrebbe ancora includerlo.

Concorda il contenimento con chi gestisce il server e verifica che il percorso non serva più il codice. Non pubblicare il campione su servizi esterni senza valutare se contenga credenziali o informazioni riservate.

La rimozione del singolo file non chiude necessariamente l'incidente. Cerca il punto d'ingresso e gli altri elementi installati: componenti vulnerabili, credenziali esposte, utenti non autorizzati o copie dimenticate. Se il file ricompare, passa alla checklist su WP-Cron, mu-plugins e persistenze.

5. Valuta il blocco dell'esecuzione nella cartella

Impedire l'esecuzione di script nelle directory destinate ai media è una misura difensiva da valutare con il provider. Non incollare una regola generica senza conoscere il server: Apache, Nginx e diverse configurazioni PHP applicano regole differenti.

Chiedi al manutentore di verificare:

1. percorso reale di uploads e sue eventuali personalizzazioni;
2. estensioni e handler che il server considera eseguibili;
3. componenti che richiedono legittimamente funzioni in quel percorso;
4. comportamento dopo la regola, provato in un ambiente controllato;
5. continuità di immagini, documenti e caricamenti autorizzati.

Bloccare la richiesta diretta non impedisce necessariamente a un altro file PHP di includere codice dallo stesso percorso. È una difesa aggiuntiva, da accompagnare alla rimozione della causa e alla configurazione di hardening.

Come verificare il risultato

Conserva l'inventario iniziale e confrontalo con quello successivo. Verifica i file rimossi, i componenti sostituiti, i percorsi pubblici e i log pertinenti. Prova caricamento e visualizzazione di media legittimi; un sito che non mostra più immagini non è un esito accettabile della correzione.

Controlla anche il resto dell'installazione. I checksum del core confrontano i file di WordPress con quelli ufficiali, ma non certificano uploads, database o componenti personalizzati.

Se hai soltanto accesso alla Bacheca, chiedi al provider di preservare e verificare i file a livello hosting. Il servizio di bonifica malware può includere questa analisi e documentarne il perimetro nel report forense.