Hackers hebben zich gericht op onpatchte Check Point Security Gateways via PHP2Shell Check Point-lekken. Na het verkrijgen van initiële toegang werd niet alleen extra controle opgebouwd, maar werd ook een backdoor (TSGA) ingezet én een wiper voor VMware ESXi-bestanden. Dat maakt deze aanval een dringende zaak voor organisaties die Check Point-apparatuur gebruiken.
Volgens Check Point begon de activiteit op 30 oktober 2026 en richtte die golf zich op organisaties in Israël. Een vervolgcampagne op 2 november 2026 breidde dit uit naar organisaties in meerdere landen en sectoren. In sommige gevallen ging het niet alleen om toegang en persistentie, maar ook om daadwerkelijke vernietiging van data.
Van PHP2Shell naar TSGA: zo bouwt de aanval op
De aanval draait om een keten van misbruik: PHP2Shell levert de eerste stap richting toegang tot de gateway. Daarna volgen verdere escalatie en het plaatsen van malware en persistentie.
Check Point beschrijft dat PHP2Shell initieel toegang gaf, waarna privilege-escalatie plaatsvond via de DynamicCLI-interface. Die stap wordt gekoppeld aan CVE-2026-123039 (CVSS-score 7,8), een missing authorization-fout. Hierdoor kan een gebruiker die al lokaal geauthenticeerd is, met één verzoek naar een socket willekeurige commando’s uitvoeren en escaleren tot root binnen het DynamicCLI-proces.
Vervolgens werd de aanval voortgezet met het installeren van PHP web shells en het uitrollen van een persistentieset: de TSGA backdoor. Daarbij hoort ook een tweede component, TSProxy, dat specifiek is ontworpen om communicatie af te handelen op een manier die normale netwerkstromen ongemoeid laat.
Wie werd geraakt en om welke versies ging het?
Check Point geeft aan dat de impact geldt voor meerdere producten, inclusief:
- Check Point Force Firewalls
- Check Point Management and Log Servers
- Multi-Domain Security Management en Multi-Domain Log Server
- Maestro Orchestrator
Voor CVE-2026-123039 worden onder meer versies genoemd zoals R82.20, R82.10, R82, R81.20 en R81.10 (binnen de genoemde productfamilies).
De stap naar VMware ESXi: wiper en sporen
Na het opbouwen van toegang en persistentie, pivotden de aanvallers vanuit de gateway naar een VMware ESXi-host. Dat gebeurde via SSH met behulp van het vpxuser-serviceaccount.
Daarna werd een Linux ELF-wiper ingezet met de naam destroy_v6. Check Point beschrijft dat deze component doelmappen recursief doorloopt en bestanden verwijdert ongeacht extensie. Daarnaast probeert de malware bestanden eerst met nullen te overschrijven voordat ze worden verwijderd.
Ook werden er duidelijke “note”-bestanden achtergelaten. In elke verwerkte directory verscheen een tekstbestand met de naam “DREAM_ANNEXATION.txt”, wat past bij een politiek getinte boodschap.
Waarom TSGA en TSProxy opvallend zijn
TSGA wordt door Check Point beschreven als een standalone passive backdoor die draait als een Check Point-specifieke gateway-implant. De backdoor werd in de beschrijving deployed als slot_CPconfigdaemon.
De functionaliteit omvat onder andere encryptie voor remote toegang, het stelen van configuratiegegevens, backup- en snapshot-persistentie, process-injectie en het tamperen van firewall-logbinnenwerk.
TSProxy is daarbij de networking-component: de injectiecode laadt een bibliotheek in geselecteerde processen en onderschept alleen verbindingen die speciaal zijn gemarkeerd door de aanvaller. Voor “normaal” verkeer zou de impact beperkt blijven, waardoor detectie lastiger kan worden.
PhiliKit-toolkit en mogelijke toeschrijving: wat we wel en niet weten
Check Point beoordeelt zowel TSGA als TSProxy als onderdelen van een toolkit die zij PhiliKit noemen. Die toolkit is eerder gedocumenteerd door ESET (juni 2026) en werd toen gekoppeld aan een China-nexus cyberespionagecontext met de naam Armory Castle (voorheen UNC5221).
Tegelijkertijd benadrukt Check Point dat er onvoldoende bewijs is om de nieuwste campagne met hoge zekerheid aan één specifieke actor te koppelen. Onder andere worden deze factoren genoemd:
- Gebruik van LightNode VPS-infrastructuur
- Scanmomenten tussen 12:00 en 09:00 UTC, passend bij typische Chinese werkuren
- Het gebruik van een wiper en de verwijzingen naar het Israëlisch-Palestijnse conflict in de wipernote
Dat zorgt voor meerdere plausibele scenario’s: de actor kan de campagne volledig hebben uitgevoerd, alleen als initial-access broker zijn opgetreden, of mogelijk “false flag” hebben toegepast waarbij destructieve stappen worden ingezet om aandacht af te leiden. Check Point geeft aan dat de bewijsvoering niet toelaat om de ware intentie en dader met hoge betrouwbaarheid vast te stellen.
Wat je vandaag kunt doen (gericht op PHP2Shell Check Point)
Ook als je omgeving niet in Israël ligt of niet dezelfde sectoren bedient, is de technische aanpak universeel genoeg om relevant te zijn. Pak daarom de volgende punten op als incident- en hardeningcheck.
1) Zorg dat je Check Point gateways gepatcht zijn
Omdat de aanval draait om misbruik van onpatchte PHP2Shell- en opvolgende privilege-escalatie, is patchen de eerste en belangrijkste stap. Volg daarbij de richtlijnen van Check Point voor de versies die binnen jouw beheeromgeving draaien.
2) Controleer op tekenen van web shells en persistentie
Check Point noemt expliciet dat de aanval PHP web shells achterlaat die commando-executie en bestandsupload ondersteunen. Zoek daarom naar afwijkende webshell-bestanden, ongebruikelijke scheduling, en onverwachte configuratiewijzigingen rond gateway-onderdelen.
3) Let op laterale beweging richting ESXi
De combinatie van gateway-compromis en daarna pivot via SSH naar ESXi met vpxuser is een sterke aanwijzing voor een campagnefase die je kunt afvangen. Controleer authentication events en verbindingspatronen van de gateway naar ESXi.
4) Denk aan detectie van wiper-gedrag
Het gedrag van destroy_v6 (recursief verwijderen, overschrijven met nullen, en “DREAM_ANNEXATION.txt” notities) kan helpen bij forensische checks. Wanneer je dit soort patronen ziet, behandel het als een actief of net afgerond destructie-incident.
Ben je benieuwd naar vergelijkbare exploit-ketens bij Check Point omgevingen? Lees dan ook N-able N-central: exploit 4EverAble2Shell en Agent2Shell en N-central zero-day: 4EverAble2Shell uitgelegd voor inzicht in hoe webshell-achtige toegang vaak wordt opgevolgd door privilege escalation en persistentie.
Conclusie
Deze campagne laat zien hoe snel een aanvaller kan escaleren als een PHP2Shell Check Point-kwetsbaarheid niet is verholpen: eerst initiële toegang via web-gestuurde exploit, daarna privilege-escalatie tot root via DynamicCLI, vervolgens TSGA en TSProxy voor duurzame toegang. Uiteindelijk wordt de aanval doorgezet richting VMware ESXi met een wiper die bestanden vernietigt.
Voor beheerders betekent dit: patchen, controleren op webshell/persistentie, en het bewaken van verbindingen richting ESXi. Hoe eerder je dit oppakt, hoe kleiner de kans dat je alleen “toegang” ziet—en niet ook de gevolgen van daadwerkelijke datavernietiging.
Bron: https://thehackernews.com/2026/11/hackers-exploit-php2shell-flaws-in.html
