Er duiken opnieuw PHP2Shell wiper-aanvallen op: dreigingsactoren zouden Check Point Gateway-appliances hebben gehackt en vervolgens organisaties met een wiper hebben beschadigd. Volgens Check Point verliepen de aanvallen in twee rondes en combineerden ze initiële toegang via kwetsbaarheidsexploitatie met privilege-escalatie en destructieve payloads.
Omdat wipers expliciet bedoeld zijn om systemen onbruikbaar te maken, is dit geen ‘afwachten’-scenario. In dit artikel zetten we de kern van het incident op een rij en vertalen we dat naar praktische maatregelen voor beheerders en securityteams.
Wat is PHP2Shell en waarom is het zo schadelijk?
PHP2Shell verwijst naar twee kritieke kwetsbaarheden, CVE-2026-109618 en CVE-2026-109619. De issues leiden tot remote code execution (RCE) en raken alle versies van PHP vanaf PHP 5. Dat maakt de impact breed: als een omgeving PHP gebruikt op een manier die exploiteerbaar is, kan een aanvaller via de serverkant controle krijgen.
Check Point meldt dat er op 21 oktober patches beschikbaar waren, maar dat misbruik al dagen ervoor begon. Kort daarna volgde massale exploitatie. Dat patroon zie je vaker bij kritieke RCE’s: zodra de eerste werkende exploit circuleert, versnelt de dreiging meestal snel.
Twee aanvalsgolven: van initiële schade naar wereldwijde uitbreiding
De campagne bestond uit twee waves.
- Eerste golf startte op 30 oktober en richtte zich volgens de rapportage op Israëlische organisaties.
- Tweede golf startte op 2 november en betrof organisaties in meerdere landen, met daarbij ook een deel van de entiteiten die eerder in Israël waren geraakt.
Bijzonder is dat in de tweede golf geen destructieve activiteit werd waargenomen. Met andere woorden: de eerste wave bevatte een duidelijke vernietigingscomponent (wiper), terwijl de tweede wave daar mogelijk omheen opereerde.
Hoe verliep de aanval? Exploiteren, privileges ophalen en persistente toegang bouwen
Volgens Check Point werd PHP2Shell gebruikt voor initial access. Daarna ging de aanvaller door naar CVE-2026-123039, een local privilege escalation binnen het DynamicCLI-proces. Daarmee verkregen ze roottoegang.
Vervolgens werden PHP webshells ingezet en werd persistentie ingericht. Webshells zijn in dit soort scenario’s berucht omdat ze aanvallers een herbruikbare beheer-achtige toegang geven, vaak met de mogelijkheid om commando’s uit te voeren zonder telkens opnieuw de initiële exploit te hoeven herhalen.
Check Point Mobile Access: webshells in login-constructiedirectory
In late oktober zouden aanvallers Check Point Mobile Access gateways hebben aangevallen binnen meerdere Israëlische organisaties. Ze plaatsten PHP webshells in een directory die het Mobile Access-portaal gebruikt om loginpagina’s te bouwen.
Dat maakte het mogelijk om commando’s te sturen en zo een sterkere positie binnen de omgeving op te bouwen. Praktisch gezien betekent dit dat de aanvaller niet alleen toegang kreeg, maar ook een kanaal om die toegang verder uit te bouwen.
Achterdeur en laterale beweging: PhiliKit-varianten en malware-infrastructuur
Na initiële compromittering rapporteert Check Point dat er varianten van een malwareframework werden ingezet, namelijk TSGA en TSProxy. Deze zouden voortkomen uit PhiliKit, eerder gezien bij een campagne die gelinkt werd aan UNC5221 en waarbij ook producten van Ivanti werden getroffen.
Met TSGA/TSProxy zou de aanvaller backdoor-toegang hebben verkregen en ook interceptie van netwerkfuncties hebben uitgevoerd. Dat wijst doorgaans op meer dan alleen ‘spelen met een webshell’: het gaat om het observeren of omleiden van verkeer binnen het doelnetwerk.
Van compromitteren naar vernietigen: VMware ESXi en de wiper
De aanvallers voerden interne asset discovery uit en gingen vervolgens lateraal naar een VMware ESXi-host. Daar zouden ze een wiper hebben ingezet en uitgevoerd.
Na de destructieve stap plaatsten ze een notitie waarin Dream Security werd genoemd.
Dit soort “opmaak” (notities, tags of verwijzingen) kan bedoeld zijn om de aandacht af te leiden of een verhaal te creëren rond de herkomst van de operatie.
Over attribution: werken ‘tijden van de regio’ zeggen niet alles
Check Point stelt dat de hackers opereerden tijdens typische Chinese werktijden. Ook werd China-gelinkte malware en infrastructuur gebruikt. Toch concludeert het rapport dat het destructieve karakter niet goed past bij bekende Chinese cyberoperaties.
Belangrijk: Check Point zegt dat er onvoldoende bewijs is om de ware aard van de operatie met hoge zekerheid vast te stellen. Er blijven meerdere scenario’s plausibel, zoals:
- de geïdentificeerde actor voerde de volledige campagne zelf uit;
- de actor fungeerde vooral als initial access broker (iemand die toegang levert aan anderen);
- er is mogelijk sprake van een false-flag scenario, waarbij signalen bewust verkeerd worden geïnterpreteerd;
- het wiper-achtige gedrag kan ook dienen als rookgordijn.
Voor organisaties is dit vooral een waarschuwing: laat je incidentanalyse niet sturen door attributie alleen. Richt je op feiten: welke kwetsbaarheden zijn misbruikt, welke indicatoren zijn gevonden en welke systemen zijn geraakt.
Was er sectorvoorkeur? Volgens Check Point niet
In beide waves werd geen duidelijke voorkeur voor een bepaalde sector gezien. Dat wijst erop dat aanvallen mogelijk opportunistisch waren: zodra er ergens exploiteerbare blootstelling werd gevonden, werd die gebruikt voor initiële toegang.
Voor defenders is dat goed nieuws en tegelijk reden tot alertheid: het betekent dat jouw omgeving net zo goed doelwit kan zijn als je software en configuraties kwetsbaar waren.
Wat je nu kunt doen tegen PHP2Shell wiper-aanvallen
Hoewel dit artikel vooral het incident schetst, kun je met dezelfde logica direct maatregelen nemen. Hieronder staan praktische stappen die logisch aansluiten op de beschreven aanvalsketen (RCE → privilege escalation → webshell → persistente toegang → laterale beweging → wiper).
1) Controleer patchstatus en voorkom nieuwe RCE
Aangezien PHP2Shell op 21 oktober is gepatcht maar eerder werd misbruikt, moet je vandaag nog nagaan of jouw Check Point gateways en relevante componenten op de juiste versies draaien. Als je dat niet kunt verifiëren, behandel de systemen als ‘mogelijk kwetsbaar’ en activeer een versnelde beoordelingsflow.
2) Zoek naar webshell-indicaties in Mobile Access gerelateerde paden
Check Point noemt het plaatsen van PHP webshells in een directory die betrokken is bij het opbouwen van loginpagina’s. Besteed daarom extra aandacht aan webroot-achtige locaties, directorystructuren rond Mobile Access en eventuele onverwachte PHP-bestanden of verdachte scriptparameters.
3) Onderzoek privilege-escalatie en rootcompromis
Omdat CVE-2026-123039 is gebruikt om roottoegang te krijgen via DynamicCLI, is het verstandig om te controleren op sporen van misbruik van CLI-gerelateerde processen, ongebruikelijke systeemcalls en logfragmenten die wijzen op een escalatiepad.
4) Ga na of er laterale beweging naar virtualisatiehosts was
De aanvalsketen bevatte een stap richting VMware ESXi waar de wiper is ingezet. Controleer daarom ook hypervisor-logs en managementinterfaces op onverwachte acties, scripts of werkende malwareprocessen.
Als je wilt verdiepen in de aanpak rond wipers en destructieve incidenten, is ook het bredere onderwerp van (post-)exploitatie en snelle containments nuttig. Een vergelijkbare context rond snelle exploitatie en response vind je bijvoorbeeld in artikelen over zero-days en concrete exploit-risico’s, zoals exploit-gevallen in N-central.
Conclusie: behandel dit als een urgente RCE-wintercap
PHP2Shell wiper-aanvallen laten zien hoe snel een kritieke RCE kan escaleren naar volledige compromittering en zelfs destructie. Check Point beschrijft een keten met initial access via PHP2Shell, daarna privilege-escalatie, webshells, backdoor/traffic-interceptie en uiteindelijk een wiper op een VMware ESXi-host in de eerste golf.
De kernboodschap is eenvoudig: check patchstatus, zoek gericht naar webshell- en root-indicaties, en beoordeel ook virtualisatiehosts op tekenen van laterale beweging. Wacht niet op extra signalen—bij wipers is tijd vaak het verschil tussen schade beperken en herstelkosten maximaliseren.
Bron: https://www.securityweek.com/php2shell-exploited-in-destructive-check-point-gateway-attacks/
