In breve: una webshell si riconosce da file PHP nuovi o modificati in posizioni insolite, da processi estranei dell'utente del server web e da connessioni anomale. Metta al sicuro le tracce prima di cancellare qualsiasi cosa e ripristini il codice da una fonte pulita. Una patch da sola non rimuove una backdoor.
Perché le webshell sono un tema dopo PHP2Shell
Le vulnerabilità CVE-2026-109618 e CVE-2026-109619 in PHP stesso consentono l'esecuzione di codice dannoso da remoto senza autenticazione. Un obiettivo ovvio dopo un attacco riuscito è una backdoor permanente, cioè una webshell. Questa resta anche se nel frattempo PHP è stato aggiornato.
Secondo i media, un primo tentativo di attacco è stato osservato già il 17/10/2026, le patch sono seguite il 21/10. Chi in questo periodo era vulnerabile dovrebbe controllare in modo mirato. Finora non sono stati pubblicati Indicators of Compromise confermati. La ricerca si basa quindi su anomalie del comportamento, non su un elenco già pronto.
Se trova una webshell su un server con dati dei clienti: non cancelli nulla in modo precipitoso. Prima metta al sicuro le prove, poi isoli il server e pianifichi la gestione successiva.
Come riconoscere una webshell: controllare i file
La maggior parte delle webshell sono file PHP nella directory web. Sono sospetti i file creati o modificati dopo il 17/10, i file PHP nelle cartelle di upload e di cache e i file con codice offuscato. I comandi seguenti non modificano nulla, si limitano a elencare:
# File PHP modificati dal 17/10/2026
find /var/www -type f -name "*.php*" -newermt "2026-10-17" -ls
# File PHP nelle cartelle di upload, cache o tmp
find /var/www -type f -name "*.php*" \( -path "*upload*" -o -path "*cache*" -o -path "*tmp*" \) -ls
# Offuscamento tipico: eval in combinazione con decodifica
grep -rlE "eval\s*\(\s*(base64_decode|gzinflate|str_rot13|gzuncompress)" /var/www --include="*.php"
# Righe insolitamente lunghe indicano spesso codice compresso
grep -rlE ".{3000,}" /var/www --include="*.php"
I riscontri sono indizi, non prove. Alcuni plugin usano legittimamente codice codificato. Confronti i file sospetti con il pacchetto originale del produttore. Il metodo più affidabile è il confronto con checksum o con un sistema di controllo di versione come Git:
# Differenze rispetto all'ultimo stato noto nel repository Git
git -C /var/www/projekt status --porcelain
Un timestamp può essere falsificato. Non si affidi quindi alla sola data di modifica di un file.
Quali caratteristiche rendono sospetto un file
| Caratteristica | Perché è sospetta |
|---|---|
| File PHP in una cartella di upload o di immagini | Lì dovrebbero esserci solo contenuti multimediali |
Doppia estensione come .jpg.php o .php.png |
Mimetizzazione da file innocuo |
| Righe molto lunghe senza a capo | Tipico di codice compresso o cifrato |
| Nome di file simile a un file del core, ma non presente nel pacchetto originale | Mimetizzazione in un ambiente noto |
| Proprietario o permessi diversi dai file vicini | Il file è stato creato in un altro modo |
Quante più caratteristiche si sommano, tanto più alta è la probabilità di un ritrovamento. Apra i file sospetti solo come testo, mai tramite il browser, perché una richiesta tramite il sito eseguirebbe il codice.
Controllare processi, connessioni e cronjob
Una webshell attiva lascia spesso tracce anche fuori dal file system. L'utente del server web, ad esempio www-data, apache o nginx, di norma non avvia shell, strumenti di rete o compilatori.
# Processi degli utenti tipici del server web
ps -eo user,pid,ppid,lstart,cmd | grep -E "^(www-data|apache|nginx)"
# Connessioni di rete aperte con il processo corrispondente
sudo ss -tunap | grep -E "php|www-data|apache|nginx"
# Attività pianificate dell'utente del server web
sudo crontab -u www-data -l
ls -la /etc/cron.d /var/spool/cron 2>/dev/null
Sono sospette le connessioni in uscita persistenti verso destinazioni sconosciute, i processi con nomi criptici e i cronjob che scaricano file da Internet. Controlli inoltre i log di accesso per richieste a file che prima non esistevano. Come farlo è descritto nella guida Analizzare i log del server web dopo un attacco.
Mettere al sicuro le tracce prima di rimuovere
Chi cancella per primo perde la risposta alle domande più importanti: come è entrato l'aggressore, che cosa ha visto, quali dati sono coinvolti? Queste risposte servono per un'eventuale notifica GDPR, per gli assicuratori e per decidere se altri sistemi siano a rischio.
Ordine sensato:
- Documentare lo stato: elenco dei processi, connessioni di rete, utenti connessi.
- Copiare i file sospetti e i log con checksum, senza aprirli né eseguirli.
- Se possibile, creare un'immagine del sistema o uno snapshot della macchina virtuale.
- Scollegare il server dalla rete o limitare fortemente l'accesso.
Per i sistemi con dati sensibili o con una possibile controversia legale, il salvataggio dovrebbe avvenire in modo forense corretto. Approfondimenti si trovano in Analisi forense IT dopo un attacco a un server web.
Rimuovere le webshell in modo pulito
Cancellare un singolo file raramente è la fine. Gli aggressori creano spesso più accessi: altri file in posizioni nascoste, voci in file di configurazione come .htaccess o .user.ini, nuovi account amministratore nell'applicazione o cronjob. Una bonifica affidabile segue questi passi:
- Portare PHP a uno stato corretto (8.5.12, 8.4.27, 8.3.36, 8.2.35 o backport confermato) e riavviare tutti i processi PHP.
- Reinstallare il codice dell'applicazione da una fonte pulita, invece di riparare singoli file.
- Riprendere solo contenuti verificati come upload e database e cercarvi in modo mirato codice introdotto.
- Cambiare tutte le credenziali: database, SSH, FTP, account amministratore, chiavi API.
- Limitare i permessi di scrittura del server web allo stretto necessario e impedire l'esecuzione di PHP nelle cartelle di upload.
Per WordPress esistono nascondigli tipici propri, descritti nella guida Trovare le backdoor in WordPress. Dopo, il sito dovrebbe essere monitorato più da vicino per un certo periodo, per accorgersi presto di un nuovo accesso.
Come aiuta concretamente PHP SOS?
- Mettiamo al sicuro log, file e stato del sistema in modo tracciabile, prima di modificare qualsiasi cosa.
- Cerchiamo backdoor in file, database, cronjob e configurazione e classifichiamo i ritrovamenti.
- Reinstalliamo l'applicazione da una fonte pulita, cambiamo gli accessi e rafforziamo il server.
- Documentiamo l'incidente fino alla chiusura, come base per notifiche e assicuratori.
Il procedimento di una bonifica è descritto nel servizio Far rimuovere malware e webshell.
Domande frequenti
Che cos'è una webshell?
Una webshell è un file introdotto di nascosto, di solito in PHP, tramite il quale gli aggressori possono controllare il server da remoto. Spesso si maschera da file innocuo con un nome non sospetto e resta attiva anche dopo un aggiornamento.
Un antivirus trova ogni webshell?
No. Gli scanner riconoscono schemi noti, le varianti nuove o molto offuscate passano inosservate. Per PHP2Shell, inoltre, non esistono Indicators of Compromise pubblicati e confermati, quindi l'analisi del comportamento conta più di un elenco di firme.
Basta cancellare il file trovato?
Di solito no. Gli aggressori creano spesso più accessi, ad esempio altri file, cronjob o nuovi account amministratore. Senza analisi delle cause e cambio di tutte le credenziali, un nuovo accesso è probabile.
Devo segnalare qualcosa se trovo una webshell?
Se possono essere coinvolti dati personali, può sussistere un obbligo di notifica ai sensi del GDPR, in genere entro 72 ore. Lo chiarisca con il Suo responsabile della protezione dei dati o con un avvocato; questa non è consulenza legale.