Gli attacchi a Check Point cancellano i server VMware ESXi: guida alla risposta

Una campagna contro i gateway Check Point è iniziata il 30 ottobre 2026: gli attaccanti sono entrati attraverso portali Mobile Access vulnerabili, hanno ottenuto i privilegi di root e, in alcuni casi, sono passati via SSH ai server VMware ESXi per eseguire il malware distruttivo destroy_v6. Check Point ha dichiarato che sono stati coinvolti «un paio di dozzine» di clienti; la prima ondata ha preso di mira organizzazioni israeliane e un'altra, il 2 novembre, ha raggiunto aziende di vari paesi e settori.

Chi deve controllare i propri gateway

La campagna ha preso di mira Check Point Security Gateways non aggiornati, in particolare quelli con il portale Mobile Access esposto a internet. Check Point Research ha descritto una prima ondata il 30 ottobre e un'altra il 2 novembre; nella seconda non ha rilevato attività distruttive. La seconda ondata ha raggiunto anche alcune organizzazioni israeliane già colpite nella prima, oltre a organizzazioni di altri paesi.

La catena ha combinato PHP2Shell, le vulnerabilità CVE-2026-109618 e CVE-2026-109619, con CVE-2026-123039, una vulnerabilità locale di escalation dei privilegi nell'interfaccia DynamicCLI di Gaia OS. Dopo aver ottenuto l'accesso iniziale tramite il portale, gli attaccanti hanno raggiunto i privilegi di root, installato web shell e la backdoor TSGA con il componente TSProxy e, da alcuni gateway, sono passati a ESXi tramite SSH.

Verifica se il tuo ambiente include Management Servers o Security Gateways e se Mobile Access era accessibile da internet durante la campagna. Network World elenca inoltre Firewall, Multi-Domain Security Management Server, Security Management Server e Scalable Platforms tra i prodotti interessati da CVE-2026-123039. The Hacker News include anche le versioni R82.20, R82.10, R82, R81.20, R81.10 e R81 nel suo elenco delle versioni interessate.

Cosa fare, nell'ordine

1. Installa il November Jumbo Hotfix su tutti i Management Servers e Security Gateways, dando la priorità ai dispositivi con Mobile Access esposto. Check Point dichiara che l'aggiornamento risolve PHP2Shell e la vulnerabilità DynamicCLI usata in questi attacchi. Non rimandare l'aggiornamento dei gateway accessibili da internet mentre controlli gli altri dispositivi.

2. Disattiva Mobile Access se non viene utilizzato e mantieni le interfacce di amministrazione fuori da internet. Se non è possibile applicare subito la patch, Check Point consiglia di arrestare il processo dynamic_server e impedirne il riavvio. Network World avverte che questa mitigazione potrebbe rendere indisponibili alcuni comandi CLI.

3. Esamina i gateway esposti dalla fine di ottobre, compresi quelli già aggiornati. Cerca file di sessione PHP con il marcatore upload_progress_pwn, processi o binari CPconfigdaemon inattesi e lacune inspiegabili nei registri del firewall. Check Point Research ha inoltre osservato ripetuti errori di segmentazione nei processi Apache/PHP del portale durante l'attività di sfruttamento.

4. Cerca tracce di persistenza nei sistemi che puoi ispezionare. Check Point Research documenta file zz*.tpl nella directory dei template di Mobile Access, oltre a /tmp/.bd.log, /tmp/.p_sock e /lib/libcpfwcommon.so. Descrive inoltre TSGA come slot_CPconfigdaemon e segnala che può sopravvivere nei backup e negli snapshot. Questi indizi giustificano un'indagine sul gateway; non considerarli un elenco esaustivo.

5. Correla i registri del gateway e di ESXi. Cerca attività SSH non autorizzate dal gateway verso gli host VMware; i ricercatori hanno identificato l'uso dell'account di servizio vpxuser. Sui dispositivi colpiti dalla fase distruttiva, il malware destroy_v6 ha eliminato ricorsivamente i file e lasciato note chiamate DREAM_ANNEXATION.txt.

6. Interrompi il percorso di fiducia verso ESXi da qualsiasi gateway sospetto. Network World consiglia di separare il firewall dall'hypervisor: un gateway potenzialmente compromesso non deve mantenere un percorso di fiducia verso VMware ESXi. Controlla anche la segmentazione della rete per limitare i movimenti laterali tra i due ambienti.

7. Invia i registri fuori dal gateway a un sistema che il dispositivo stesso non possa modificare. TSGA può alterare i registri binari del firewall, quindi un registro locale apparentemente privo di lacune non esclude da solo un'intrusione. Conserva e confronta la telemetria esterna con quella di ESXi e degli altri sistemi della rete.

8. Ricostruisci i sistemi compromessi da immagini attendibili quando l'indagine conferma un'intrusione o non consente di escluderla. Erik Avakian, di Infotech, avverte che applicare la patch non allontana gli attaccanti che hanno già stabilito la persistenza. Network World raccomanda di indagare e, quando necessario, ricostruire i dispositivi interessati.

Errori che possono lasciare aperta l'intrusione

Considerare risolto l'incidente dopo aver applicato la patch è il primo errore. L'aggiornamento corregge le vulnerabilità, ma non rimuove una backdoor già installata né dimostra che il gateway sia pulito; esamina i dispositivi esposti in precedenza anche se hanno già l'hotfix.

Affidarsi solo ai registri locali non basta: TSGA può manipolare i registri binari del firewall. Non considerare l'assenza di avvisi locali come prova che non ci sia stato accesso e confronta l'attività con i registri inviati a un altro sistema e con quelli di ESXi.

Infine, non lasciare Mobile Access o SSH esposti senza necessità e non consentire a un gateway sospetto di mantenere l'accesso di fiducia all'hypervisor. I segnali più concreti da usare per stabilire le priorità dei controlli sono il marcatore di sessione, i processi CPconfigdaemon inattesi e le connessioni SSH dal gateway a ESXi.

Fonti: Network World, BleepingComputer, The Hacker News, Check Point Research, Secure Blog