L'8 settembre SophosLabs ha pubblicato l'analisi tecnica di un impianto Linux trovato in ambienti F5 BIG-IP Access Policy Manager compromessi. ESET lo chiama PoisonedRefresh, Sophos lo traccia come Linux/Agnt-IC, e F5 associa l'attività a un cluster che segue internamente come c05d5254.

La capacità finale non è nuova: è una webshell PHP, la stessa categoria di strumento che i difensori cercano da vent'anni. Quello che cambia è il modo in cui arriva a destinazione, ed è il motivo per cui vale la pena leggere il report per intero anche se non si gestisce un BIG-IP.

Il punto d'ingresso: una CVE già nota e già sfruttata

L'accesso iniziale avviene tramite CVE-2025-53521, una vulnerabilità di esecuzione di codice remoto non autenticata nel BIG-IP APM che si attiva quando un access policy è configurato su un virtual server. Il dato che conta, per chi deve valutare la propria esposizione, è la storia di questa CVE: era stata originariamente classificata come denial of service, e solo a marzo 2026 F5 ne ha confermato la natura di RCE, portando il punteggio a CVSS 9.8 (v3.1) e 9.3 (v4.0). Sono interessate le versioni 15.1.0–15.1.10, 16.1.0–16.1.6, 17.1.0–17.1.3 e 17.5.0–17.5.1, anche in Appliance mode.

Quella riclassificazione è il vero problema operativo. Chiunque abbia triato la vulnerabilità quando era un DoS l'ha ragionevolmente messa in coda dietro a cose più urgenti. Le patch erano già disponibili e restano valide, ma il processo interno che avrebbe dovuto imporne l'installazione era stato calibrato su una severità sbagliata. Shadowserver ha censito oltre 14.000 istanze BIG-IP APM esposte su internet e vulnerabili nel periodo di divulgazione — circa 4.750 in Europa — e ne contava 795 ancora raggiungibili e vulnerabili al momento della riclassificazione.

Come funziona l'impianto

Il primo stadio si nasconde dentro un binario umount modificato: infetta /usr/sbin/httpd, altera la configurazione SELinux e si inserisce nelle immagini di upgrade del BIG-IP per sopravvivere agli aggiornamenti del dispositivo. Questo dettaglio, da solo, dovrebbe far riconsiderare il piano di risposta di chiunque pensi che un upgrade sia una forma di bonifica.

Il secondo stadio è un ELF Linux autonomo che porta con sé il proprio loader invece di affidarsi a quello di sistema. All'avvio intercetta __libc_start_main, la funzione che normalmente lancia Apache: questo gli consente di eseguire la propria inizializzazione prima che Apache inizi a lavorare, prima che i sistemi di logging siano pienamente attivi e prima che alcuni strumenti di sicurezza inizino a monitorare il processo.

Poi aspetta. Aggancia apr_dso_load, la funzione con cui Apache carica i moduli condivisi, e attende che venga caricato il modulo PHP. A quel punto legge /proc/self/maps per localizzare libphp in memoria, modifica temporaneamente i permessi di quella regione, dirotta le chiamate a open, close e mmap, e ripristina le protezioni originali.

Da qui in avanti l'impianto controlla il modo in cui PHP legge i file all'interno del processo Apache. E arriva la parte che rende l'analisi notevole.

L'impianto sorveglia l'apertura di tre specifici script legittimi del webtop BIG-IP APM — apm_css.php3, full_wt.php3 e webtop_popup_css.php3. Quando PHP apre uno di questi file e lo mappa in memoria, l'impianto intercetta la mmap() e restituisce una vista alterata: il contenuto originale dello script, preceduto dalla webshell PHP. Il file su disco non viene mai modificato.

Il processo in esecuzione vede quindi un contenuto diverso da quello che riporterebbero ls, un cat, un hash o uno scanner di integrità dei file. Non esiste un artefatto su disco da trovare, perché non ne è mai stato scritto uno.

La webshell iniettata legge i dati grezzi da php://input, cerca un prefisso specifico (BSOHAzPB), decifra il resto con un cifrario a flusso ed esegue. Per mimetizzare il traffico risponde con HTTP 201 e Content-Type: text/css, così che la richiesta assomigli al caricamento riuscito di un foglio di stile su un BIG-IP APM — cosa che su quel dispositivo è perfettamente ordinaria.

In parallelo l'impianto crea un socket UNIX locale in /run/bigtlog.pipe. Dopo un breve passaggio di autenticazione con un token statico, collega input, output ed error di una /bin/bash al socket: l'attaccante ottiene una shell interattiva senza aprire alcuna porta TCP in ascolto, il che la sottrae al monitoraggio di rete e alle scansioni di postura. Il worker del socket viene avviato in ritardo, usando apr_time_now di Apache come innesco, per non disturbare la fase di startup del server. Le stringhe operative sono cifrate in RC4 con chiave hardcoded e decifrate solo all'uso: l'analisi statica del binario restituisce poco più che nomi di funzioni.

Cosa significa per le aziende italiane

Il BIG-IP APM non è un prodotto di nicchia nel panorama italiano. È lo strato di accesso davanti a portali di home banking, VPN aziendali, applicativi assicurativi, servizi della sanità regionale e portali della PA centrale e locale. Dove c'è un BIG-IP APM c'è, per definizione, un punto in cui transitano credenziali e sessioni autenticate di tutti gli utenti dell'organizzazione.

Questo determina la gravità reale. Una webshell su un server web qualsiasi è un problema. Una webshell persistente e invisibile su un concentratore di accessi è una posizione da cui osservare l'autenticazione di chiunque entri, per tutto il tempo in cui resta lì.

C'è poi una lezione metodologica che riguarda chiunque, non solo chi ha F5 in casa. Il modello mentale prevalente nel threat hunting sulle webshell è ancora file-centrico: si confrontano gli hash, si cercano file PHP anomali nelle webroot, si monitorano le scritture nelle directory servite. PoisonedRefresh dimostra che quel modello ha un punto cieco preciso. Come scrive Sophos, è del tutto possibile che il file PHP su disco appaia benigno mentre la mappatura in memoria contiene codice malevolo. Chi ha costruito il proprio rilevamento esclusivamente sull'integrità dei file ha, contro questa classe di minaccia, una copertura pari a zero — e non lo saprà, perché i controlli continueranno a dare esito positivo.

Va detto per correttezza che questo è un impianto costruito su misura. Punta a componenti specifici del webtop BIG-IP APM e ai flussi di upgrade del prodotto: non è un tool generico riutilizzabile ovunque, e la sua presenza suggerisce un attaccante con obiettivi selezionati e tempo a disposizione, non una campagna opportunistica di massa. Chi ha già applicato le patch di F5 e non ha mai esposto l'APM vulnerabile non deve considerarsi sotto attacco. Ma le tecniche — hooking del loader dei moduli, consegna del payload solo in memoria, canale di comando su socket locale — sono trasferibili ad Apache e PHP in generale, e da qui in avanti vanno messe in conto.

Sul piano normativo, per i soggetti essenziali e importanti ai sensi del d.lgs. 138/2024 che recepisce NIS2, un impianto con questa persistenza su un sistema di accesso configura con ogni probabilità un incidente significativo: notifica di preallerta al CSIRT Italia entro 24 ore dalla conoscenza, notifica completa entro 72 ore. Per banche e assicurazioni si aggiunge la classificazione DORA. E poiché il dispositivo intermedia sessioni autenticate di utenti identificati, va valutata in parallelo la notifica al Garante ex articolo 33 GDPR: in caso di compromissione confermata, l'ipotesi di accesso a credenziali e dati di sessione è quella prudenziale da assumere finché l'analisi forense non dimostri il contrario.

Cosa fare subito

  • Verificare la versione del BIG-IP APM e applicare le correzioni per CVE-2025-53521 se non già fatto. Se la vulnerabilità era stata valutata come DoS e rinviata, riaprire quel ticket oggi: le versioni corrette erano già disponibili prima della riclassificazione.
  • Seguire per prime le indicazioni di F5 contenute nell'articolo K000156741 per la remediation e il compromise assessment, prima di applicare hardening generico di Apache o PHP. Sophos è esplicito su questo ordine: l'hardening generico su un sistema già compromesso rischia solo di alterare gli artefatti.
  • Cercare il socket locale /run/bigtlog.pipe, presenza che è di per sé un indicatore forte.
  • Ispezionare il comportamento a runtime dei worker Apache: chiamate mmap() o mprotect() anomale poco dopo il caricamento di libphp, accessi a /proc/self/maps seguiti da cambi di permessi di memoria.
  • Cercare nei log web risposte HTTP 201 con Content-Type: text/css che non corrispondano a richieste legittime di asset. È un pattern innocuo in apparenza e proprio per questo raramente monitorato: vale la pena costruirci una regola di correlazione.
  • Controllare modifiche inattese alla configurazione SELinux e alle immagini di upgrade del dispositivo. Quest'ultimo punto è decisivo: se l'impianto è nell'immagine, l'aggiornamento non bonifica, reinstalla.
  • Non considerare l'upgrade del dispositivo una misura di bonifica. In caso di compromissione confermata la strada è il ripristino da un'immagine verificata pulita, con rotazione integrale di credenziali, certificati e segreti transitati dal dispositivo.
  • Estendere il rilevamento delle webshell oltre l'analisi dei file, includendo ispezione della memoria e comportamento dei processi. Vale per il BIG-IP e vale per qualunque stack Apache/PHP esposto: è la modifica strutturale che questa analisi suggerisce.