In breve: se un server sia stato hackerato tramite PHP2Shell non si legge da una singola caratteristica. Non esistono Indicators of Compromise pubblicati e confermati; il rilevamento si basa sull'analisi del comportamento. Segni tipici sono nuovi file PHP, cronjob sconosciuti e connessioni insolite. Prima di modificare qualsiasi cosa, salvi i log a partire dal 20 ottobre.
Esistono segni inequivocabili di un attacco PHP2Shell?
No, ed è la risposta onesta. Per molte vulnerabilità note, produttori o società di sicurezza pubblicano tracce concrete: nomi di file, checksum, indirizzi IP. Per PHP2Shell finora non esistono tali Indicators of Compromise confermati.
Ciò che è noto: secondo i resoconti dei media, un primo tentativo di attacco è stato osservato il 17 ottobre, quattro giorni prima delle patch del 21 ottobre. Cloudflare ha segnalato ulteriori tentativi. Secondo il BSI (l'Ufficio federale tedesco per la sicurezza informatica), inizialmente non erano noti attacchi riusciti su larga scala. Chi è stato raggiungibile senza protezione tra il 17 ottobre e la propria patch dovrebbe quindi verificare, anziché sperare.
Per la valutazione conta soprattutto il periodo. Tra il primo tentativo di attacco osservato il 17 ottobre e le patch del 21 ottobre non esisteva alcun aggiornamento ufficiale. Ogni server PHP raggiungibile pubblicamente era in quel periodo potenzialmente attaccabile. Per quanto tempo il Suo server sia rimasto aperto oltre a ciò dipende da quando l'aggiornamento è stato installato e PHP riavviato. Più lungo è questo periodo e più sensibili sono i dati, ad esempio account dei clienti, ordini o candidature, tanto più accurata dovrebbe essere la verifica.
Segni tipici che un server è stato hackerato
Dopo un'esecuzione di codice riuscita, gli aggressori di solito cercano di stabilirsi e di usare il server. Ne derivano segni che non sono specifici di PHP2Shell, ma contano in ogni verifica di intrusione:
- File PHP nuovi o modificati, soprattutto in directory di upload, di cache o di immagini, in cui di norma non ci sono file PHP.
- Cronjob sconosciuti o attività pianificate, ad esempio per l'utente del web server.
- Connessioni in uscita insolite verso indirizzi sconosciuti, carico di rete elevato o invio di posta che nessuno ha avviato.
- Nuovi account admin in CMS o shop, password modificate, chiavi SSH sconosciute.
- Carico anomalo: utilizzo costantemente alto della CPU da parte di processi sconosciuti, spesso un indizio di mining di criptovalute.
- Conseguenze visibili: reindirizzamenti verso siti estranei, pagine di spam nell'indice di Google, avvisi nel browser o nella Search Console.
Nessuno di questi segni dimostra da solo un'intrusione, e la loro assenza non dimostra il contrario. È decisivo il quadro d'insieme.
Prime verifiche senza distruggere le tracce
Prima di cancellare o riavviare qualsiasi cosa: salvi i log. La stampa specializzata consiglia di conservare i log del server a partire dal 20 ottobre. Copi i log del web server, di PHP e di sistema in un luogo sicuro fuori dal server.
Poi aiutano verifiche di sola lettura. Percorsi e nomi utente variano a seconda del sistema:
# File PHP modificati dal 17/10
find /var/www -type f -name "*.php" -newermt "2026-10-17" -ls
# File PHP nelle directory di upload (esempio WordPress)
find /var/www -path "*/uploads/*" -name "*.php" -ls
# Cronjob dell'utente del web server e a livello di sistema
crontab -l -u www-data
ls -la /etc/cron.d /etc/cron.daily /var/spool/cron 2>/dev/null
# connessioni di rete attive con processo
ss -tunp
# ultimi accessi
last -n 30
Tenga presente: gli aggressori possono falsificare i timestamp dei file. Un esito privo di anomalie di find non è quindi un'assoluzione. Come analizzare i log in modo mirato è descritto alla pagina Analizzare i log del web server dopo un attacco; come trovare le backdoor alla pagina Riconoscere e rimuovere le web shell.
Se trova indizi concreti, ad esempio un file PHP sconosciuto nella cartella di upload: non lo cancelli, non reinstalli, non «ripari in fretta» l'applicazione. Scolleghi o isoli il server dalla rete, salvi log e immagine del sistema e avvii una gestione strutturata dell'incidente.
Che cosa non dovrebbe fare
- Applicare solo la patch e andare avanti. Una patch non rimuove il malware già introdotto.
- Cancellare subito i file sospetti. Così spariscono le prove di che cosa sia successo e di quali dati possano essere coinvolti.
- Reinstallare il server prima del salvataggio. La causa resta poco chiara, e una backdoor nel database o nelle credenziali sopravvive alla reinstallazione.
- Ripristinare vecchi backup senza verifica. Anche un backup può già contenere la backdoor.
- Dimenticare le credenziali. Dopo un'esecuzione di codice, password del database, chiavi API e altre credenziali possono essere fuoriuscite dai file di configurazione. Le rinnovi dopo la bonifica, non prima, affinché un aggressore ancora attivo non legga subito anche le nuove.
Se il sospetto si conferma
In tal caso non si tratta solo di tecnica. Verifichi con il Suo responsabile della protezione dei dati se sia necessaria una notifica ai sensi del GDPR; il termine è di 72 ore dalla presa di conoscenza, dettagli alla pagina Obbligo di notifica GDPR. Informi presto il Suo assicuratore cyber, se presente, e chiarisca con un avvocato se presentare denuncia. Forniamo in proposito indicazioni generali, non consulenza legale.
Come aiuta concretamente PHP SOS?
Con la nostra incident response affrontiamo un sospetto in modo strutturato:
- Salvare: log a partire dal 20 ottobre e, dove serve, un'immagine del sistema, prima che venga modificato qualcosa.
- Indagare: analisi del comportamento di file, processi, connessioni e account; se necessario con valore probatorio tramite analisi forense IT.
- Bonificare e chiudere: rimuovere le backdoor, aggiornare PHP, rinnovare le credenziali, fare l'hardening del server.
- Documentare, finché l'incidente non è concluso e documentato, come base per protezione dei dati, assicurazione e direzione.
Domande frequenti
L'aggiornamento di PHP dimostra che il mio server è pulito?
No. Una patch chiude la vulnerabilità per il futuro, ma non rimuove il malware già introdotto. Non dice nemmeno se prima della patch qualcuno sia entrato.
Esiste uno scanner che riconosca con certezza gli attacchi PHP2Shell?
Finora no. Non esistono Indicators of Compromise pubblicati e confermati che uno scanner possa cercare in modo mirato. Gli scanner antimalware trovano le web shell note, ma la valutazione di un server si basa sull'analisi del comportamento.
Devo segnalare un sospetto all'autorità per la protezione dei dati?
Dipende dal fatto che possano essere coinvolti dati personali. Il GDPR prevede per le violazioni di dati soggette a notifica un termine di 72 ore dalla presa di conoscenza. Lo chiarisca presto con il Suo responsabile della protezione dei dati o con un avvocato; non forniamo consulenza legale.
Devo semplicemente reinstallare il server hackerato?
Non come primo passo. Salvi prima i log e, se possibile, un'immagine del sistema. Chi reinstalla subito perde le tracce che mostrano che cosa è successo e quali dati possono essere coinvolti.