Hacker prendono di mira i sistemi F5 BIG-IP APM con una web shell Linux fileless

Secondo quanto riferito, alcuni threat actor stanno compromettendo sistemi negli ambienti F5 BIG-IP Access Policy Manager e installando un rootkit Linux in grado di manipolare il caricamento dei file PHP. Il rootkit inietta una web shell direttamente in memoria, consentendo agli attaccanti di mantenere un accesso occulto senza salvare sul disco un normale file di web shell.

L’attività è stata segnalata l’8 settembre 2026. Tuttavia, le prime informazioni non identificano il vettore d’intrusione, una vulnerabilità associata, le versioni software interessate o il numero di organizzazioni compromesse.

Questa incertezza complica le attività di remediation. I difensori non possono ancora stabilire se l’installazione di uno specifico aggiornamento chiuda il punto d’accesso utilizzato dagli attaccanti, ma il comportamento osservato dopo la compromissione offre una base per avviare subito le indagini.

Quando un gateway di sicurezza diventa un punto d’appoggio per gli attaccanti

L’ambiente interessato è F5 BIG-IP Access Policy Manager, generalmente collocato davanti a risorse aziendali sensibili per applicare le policy di accesso. La compromissione di un sistema di questo tipo è più grave rispetto a un’infezione su un normale endpoint.

Un attaccante che controlla un’appliance per la gestione degli accessi può ottenere una posizione stabile in prossimità dei flussi di autenticazione e dei servizi di rete protetti. A seconda della configurazione e dei privilegi dell’appliance, questa può inoltre diventare una base di partenza per tentare di raggiungere i sistemi interni.

Il malware segnalato opera nel contesto Linux alla base dell’ambiente BIG-IP. Le sue principali funzionalità documentate sono:

• Intercettare il caricamento dei file PHP.
• Iniettare una web shell nella memoria del sistema.
• Evitare la creazione sul disco di un normale file di web shell.
• Nascondere l’esecuzione malevola attraverso funzionalità da rootkit.

Non sono state rese pubbliche evidenze che dimostrino il furto di dati, l’interruzione dei servizi, l’intercettazione di credenziali o il movimento verso le reti a valle. Questi scenari restano possibili conseguenze, non risultati confermati.

Anche la portata dell’attività è sconosciuta. Non è stato pubblicato alcun numero di appliance o organizzazioni interessate e non sono state individuate informazioni su obiettivi specifici per area geografica o settore. Non sono stati divulgati neppure gli operatori, il nome della campagna o quello del malware.

Come la web shell residente in memoria sfugge alle scansioni dei file

Le web shell tradizionali sono generalmente script lato server scritti in una directory accessibile dal web. L’attaccante invia quindi richieste appositamente predisposte allo script per eseguire comandi o compiere altre azioni non autorizzate.

Questo modello lascia un file sul sistema. Gli strumenti di sicurezza possono rilevarlo attraverso il confronto con firme note, il monitoraggio dell’integrità, l’individuazione di nomi di file sospetti, l’analisi dei contenuti o il confronto con un’installazione considerata integra.

La tecnica osservata sui sistemi BIG-IP APM elimina questa dipendenza. Anziché salvare il componente PHP malevolo come un normale file, il rootkit intercetta l’attività di caricamento di PHP e inietta la web shell nella memoria.

Si crea così una distanza tra ciò che il sistema sembra contenere sul disco e ciò che esegue durante il runtime. Una scansione del file system può non rilevare alcun file PHP sconosciuto, anche mentre la logica malevola della web shell continua a operare in memoria.

Il rootkit aggiunge un ulteriore livello di occultamento. I rootkit sono progettati per interferire con la visibilità ordinaria del sistema operativo su processi, file, attività di rete o altre risorse. I meccanismi precisi utilizzati in questa campagna non sono stati resi pubblici; per questo i difensori non dovrebbero presumere che il normale output degli strumenti amministrativi offra una visione completa di un’appliance interessata.

Allo stesso modo, le informazioni disponibili non spiegano come la persistenza sopravviva a un riavvio, come gli attaccanti comunichino con la shell iniettata o quale meccanismo di caricamento di PHP venga intercettato. Non sono state pubblicate infrastrutture di command and control, nomi di file, nomi di processo, indicatori di rete, hash crittografici o firme di rilevamento.

Versioni, vulnerabilità e vettore d’ingresso restano sconosciuti

La famiglia di prodotti interessata è F5 BIG-IP, in particolare gli ambienti che utilizzano Access Policy Manager. Non sono state identificate le versioni esatte di BIG-IP né i modelli di appliance coinvolti.

Nessuna CVE è stata associata alle compromissioni. Non è quindi noto se gli attaccanti abbiano sfruttato una vulnerabilità software non corretta, utilizzato credenziali amministrative rubate, abusato di un’interfaccia di gestione esposta o ottenuto l’accesso attraverso un altro percorso.

La distinzione è importante ai fini del contenimento. Un aggiornamento software può rimuovere una vulnerabilità, ma non elimina necessariamente un rootkit da un dispositivo già compromesso. Al contrario, la sola rotazione delle credenziali non chiuderebbe una vulnerabilità sfruttabile ancora non identificata.

Non sono stati inoltre comunicati una versione corretta, una patch del fornitore o una soluzione alternativa confermata e specificamente collegata a questa attività. Le organizzazioni dovrebbero continuare ad applicare gli aggiornamenti di sicurezza e le indicazioni di hardening disponibili per F5, senza però considerare il normale aggiornamento delle patch come una prova che l’appliance sia integra.

Poiché non è stato fornito alcun identificativo di vulnerabilità, l’attività non può essere associata a una voce del catalogo Known Exploited Vulnerabilities della US Cybersecurity and Infrastructure Security Agency. Di conseguenza, non sono state indicate né una data di inserimento nel catalogo KEV né una scadenza per la remediation relativa a questo incidente.

Il rilevamento deve andare oltre il file system

La scansione convenzionale dei malware basata sui file non è sufficiente per questa minaccia. I difensori dovrebbero combinare i log dell’appliance, la telemetria di rete, l’ispezione del runtime, la revisione della configurazione e, quando disponibili, le attività di memory forensics.

Le priorità dell’indagine includono:

1. Esaminare gli accessi amministrativi. Analizzare i log di gestione e di sistema di BIG-IP alla ricerca di accessi inspiegabili, utilizzi anomali dei privilegi, modifiche alla configurazione, creazione di account o accessi provenienti da fonti inattese.

2. Esaminare il comportamento dell’esecuzione PHP. Cercare richieste insolite, modalità inattese di caricamento di PHP, percorsi di esecuzione che non corrispondono ai file presenti sul disco e discrepanze tra i contenuti applicativi distribuiti e il comportamento osservato durante il runtime.

3. Analizzare le attività residenti in memoria. Indagare processi e componenti caricati anomali. Poiché la web shell risulta iniettata nella memoria, le evidenze volatili possono essere fondamentali per stabilire se l’appliance è compromessa.

4. Esaminare le connessioni di rete. Individuare traffico in uscita inatteso, sessioni persistenti, destinazioni sconosciute e connessioni non coerenti con il ruolo operativo dell’appliance.

5. Cercare il comportamento tipico di una web shell, non solo i file di web shell. Modelli sospetti di esecuzione dei comandi o delle richieste possono restare visibili nei log o nei dati di rete anche quando sul disco non esiste alcuno script malevolo.

6. Verificare l’integrità del sistema. Confrontare la configurazione e lo stato software dell’appliance con baseline attendibili, utilizzando procedure amministrative o forensi F5 approvate.

L’assenza di indicatori pubblicati fa sì che questi controlli richiedano un’analisi comportamentale, anziché un semplice confronto con hash o indirizzi IP. Una scansione del disco senza risultati sospetti non dovrebbe, da sola, portare alla chiusura dell’indagine.

Le appliance sospette richiedono un contenimento che preservi le evidenze

Le organizzazioni che individuano segnali credibili di compromissione dovrebbero isolare il sistema BIG-IP interessato, preservando al contempo i log e la memoria volatile. Una ricostruzione o un riavvio immediati potrebbero alterare le evidenze necessarie per comprendere il rootkit e il suo payload in memoria.

I responsabili della risposta agli incidenti dovrebbero stabilire quando è iniziato l’accesso non autorizzato, quali account hanno interagito con l’appliance e quali sistemi interni o esterni hanno comunicato con essa. La verifica dovrebbe estendersi oltre il dispositivo BIG-IP, perché un gateway di accesso compromesso potrebbe essere stato utilizzato per raggiungere infrastrutture protette.

Le credenziali accessibili dal sistema interessato o utilizzate tramite esso dovrebbero essere ruotate dopo il contenimento. Gli account privilegiati, le credenziali impiegate dall’automazione, gli account di servizio e i percorsi di accesso amministrativo richiedono particolare attenzione.

Il ripristino dell’affidabilità può richiedere più della semplice eliminazione dei file sospetti, soprattutto quando non ne è presente alcuno. Le organizzazioni dovrebbero utilizzare le procedure supportate dal fornitore per il ripristino e la convalida dell’integrità, verificando che le modifiche malevole al runtime non possano sopravvivere o ripresentarsi dopo la remediation.

Finché non saranno rese note le versioni F5 interessate, un metodo di accesso iniziale e correzioni validate, i difensori dovranno affrontare due attività distinte: ridurre l’esposizione attraverso gli aggiornamenti di sicurezza disponibili e stabilire se gli attaccanti siano già operativi nelle appliance distribuite. La seconda attività non può essere risolta con il solo patching.