Rilevamento e risposta
Oltre all’applicazione delle patch, il SOC raccomanda un’analisi retroattiva dei sistemi esposti almeno a partire dal 17 ottobre 2026, laddove esista telemetria. Correli gli accessi sospetti con l’esecuzione di processi, le modifiche ai file, le connessioni in uscita e gli eventi di autenticazione. L’assenza di telemetria o di alert non dimostra che lo sfruttamento non sia avvenuto.
1. Telemetria dei processi / EDR
Generi un alert per qualsiasi processo avviato da php-fpm, php-cgi, httpd o apache2 che lanci una shell o strumenti di download (sh, bash, dash, curl, wget, nc, python, perl). In condizioni normali questo comportamento è raro e va trattato come una possibile compromissione.
2. Log web e PHP
• Raffiche di richieste POST multipart/form-data dalla stessa origine, in particolare con un numero insolito di parti o di header.
• Nomi di campo annidati in profondità o richieste che includono PHP_SESSION_UPLOAD_PROGRESS, anche verso endpoint che non dovrebbero accettare upload.
• Risposte HTTP 500 ripetute, crash o riavvii imprevisti dei worker PHP.
• Cookie PHPSESSID malformati o insolitamente lunghi ed errori ripetuti (SIGSEGV, AH00052, zend_mm_heap corrupted, "Allowed memory size … in Unknown on line 0") nei log di PHP, Apache o FPM.
3. File system e persistenza
• File PHP nuovi o modificati nelle directory di upload, di cache o accessibili via web; verifichi timestamp, proprietario e contenuto.
• Nuovi cron job per l’utente del server web, chiavi SSH o account aggiunti di recente; connessioni in uscita insolite avviate dai worker web.
4. Come utilizzare gli indicatori di compromissione (IOC)
Tratti gli IOC come punti di partenza per la correlazione, non come prove a sé stanti: alcuni indirizzi potrebbero appartenere a infrastrutture di anonimizzazione o comparire nel traffico legittimo. Una corrispondenza non conferma una compromissione e non giustifica un blocco automatico. Convalidi la fonte, la data e il contesto di ciascun indicatore, confrontandolo con la telemetria host/di rete.
Risposta agli incidenti: se vi sono segnali credibili di compromissione
1. Isoli il sistema interessato e limiti l’accesso di rete senza distruggere le evidenze.
2. Conservi i log e, ove possibile, un’immagine del disco e gli artefatti rilevanti di memoria/processi.
3. Ruoti tutte le credenziali accessibili al processo web: password dei database, chiavi API, token e segreti .env.
4. Prosegua l’indagine alla ricerca di persistenza, esfiltrazione e movimento laterale. Il solo aggiornamento di PHP non rimuove l’accesso di un attaccante se il sistema era già stato compromesso.
5. Effettui l’escalation al team SOC/IR e valuti gli obblighi di notifica applicabili (GDPR, NIS2).
Per PHP 8.1 e versioni precedenti, verifichi se il Suo distributore fornisce patch con backport documentati. Se non esiste una correzione supportata, pianifichi una migrazione. Ricostruisca le immagini container a partire da immagini di base aggiornate e le ridistribuisca; aggiornare l’host non aggiorna PHP all’interno del container.
