Check Point Research (CPR) published a technical write-up of attacks on Check Point gateways with unpatched Mobile Access portals. The chain: PHP2Shell for initial access, a local escalation to root, webshells and a backdoor on the gateway, then SSH to an ESXi host where a wiper was run. This playbook turns the artifacts CPR lists into hunts. CPR’s article gives no formal detection section, so everything below is our derivation from its reported artifacts, not vendor-supplied rules, and none of it has been validated against live traffic.
What CPR reported
- Waves. Wave 1 began on 30 October and targeted Israeli organizations, with destructive activity at some victims. Wave 2 on 2 November was broader scanning and exploitation across countries and sectors, with no destructive activity seen.
- CVEs. PHP2Shell is CVE-2026-109618 and CVE-2026-109619 (NVD scores 9.8 and 8.1; both are in CISA KEV, added 26 October). Root came from CVE-2026-123039, the DynamicCLI local escalation (KEV, added 13 November; Check Point advisory sk1000362).
- Chain. Portal exploit, root, webshell in the portal templates directory, TSGA backdoor and TSProxy library, the gogo scanner, SSH to ESXi as
vpxuser, then thedestroy_v6wiper. - Attribution. CPR links TSGA and TSProxy to PhiliKit, previously tied by ESET to UNC5221, but says the evidence “does not allow us to assess with high confidence the true nature of this operation”.
Hunt 1: webshell and staging files on the gateway
CPR reports webshells dropped as zz<random>.tpl in the portal templates directory, an upload staged at /tmp/.up.tpl, and a copy named challenge_render.tpl. The webshell uses a hardcoded key, zz2026.
title: Possible PHP2Shell webshell template on Check Point gateway
status: experimental
description: File names reported by Check Point Research
logsource:
category: file_event
product: linux
detection:
zz_tpl:
TargetFilename|contains: '/templates/'
TargetFilename|re: '/zz[^/]*\.tpl$'
staging:
TargetFilename|endswith:
- '/tmp/.up.tpl'
- '/challenge_render.tpl'
condition: zz_tpl or staging
level: high
In our experience gateway appliances rarely run an EDR agent (our note, not CPR’s). If you only have file-integrity monitoring or a periodic find, run find / -name 'zz*.tpl' -o -name '.up.tpl' -o -name 'challenge_render.tpl' 2>/dev/null and review the portal directory against a known-good baseline.
Hunt 2: backdoor names, ports and sockets
TSGA is dropped as /tmp/CPconfigdaemon, with a log file at /tmp/.bd.log, then relaunched as slot_CPconfigdaemon. TSProxy is written to /lib/libcpfwcommon.so. CPR gives TCP port 11072 and the Unix socket /tmp/.p_sock.
title: PhiliKit TSGA backdoor launch on Check Point gateway
logsource:
category: process_creation
product: linux
detection:
img:
Image|endswith:
- '/CPconfigdaemon'
- '/slot_CPconfigdaemon'
cmd:
CommandLine|contains: '/tmp/.bd.log'
condition: img or cmd
level: high
The image-name match can false-positive on a legitimate Check Point process whose path ends the same way; confirm against a known-good baseline before alerting.
For network telemetry, a Microsoft Sentinel or Defender query for the reported port and the two reported IPs (defanged in CPR’s article, 130.94.19.204 and 130.94.19.168):
CommonSecurityLog
| where TimeGenerated > ago(30d)
// Refanged from CPR's defanged IOCs; handle with care
| where DestinationPort == 11072 or SourcePort == 11072
or SourceIP in ("130.94.19.204","130.94.19.168")
or DestinationIP in ("130.94.19.204","130.94.19.168")
| project TimeGenerated, DeviceVendor, SourceIP, DestinationIP, DestinationPort, Activity
Port 11072 is an indicator from one build. A negative result on this port is weak evidence, since other builds may differ.
Hunt 3: gateway to ESXi
CPR reports SSH from the gateway to an ESXi host using the vpxuser account. vpxuser is a service account that vCenter uses to manage hosts (our background, not from CPR), so in our assessment an SSH login with it from a firewall address is anomalous.
Syslog
| where TimeGenerated > ago(30d)
| where ProcessName =~ "sshd" and SyslogMessage has "Accepted" and SyslogMessage has "vpxuser"
| extend SrcIP = extract(@"from (\d+\.\d+\.\d+\.\d+)", 1, SyslogMessage)
| where SrcIP !in (<vcenter_ips>)
| project TimeGenerated, Computer, SrcIP, SyslogMessage
Replace <vcenter_ips> with your vCenter addresses. ESXi logs live on a ramdisk and are lost on reboot unless forwarded, so confirm syslog forwarding before you rely on this. On hosts, search for DREAM_ANNEXATION.txt, a politically themed note CPR says uses the Dream Security brand; CPR says the evidence does not establish a clear motive and raises, without confirming, the possibility of retaliation for Dream’s PHP2Shell research on Palo Alto devices. CPR names the wiper destroy_v6 (its IOC table spells the file name “destory_v6”; search for both) and says it was staged at /tmp/des wiper and reports -f (fast delete) and -w (exclude list) flags.
Hunt 4: portal session artifacts
CPR reports PHP session files carrying the marker upload_progress_pwn under /opt/CPcvpn-R81.20/tmp/. CPR does not give a list of affected versions, so use a glob for other builds: grep -rl upload_progress_pwn /opt/CPcvpn-*/tmp/.
Triage and response
- CPR says activity began about a week after a security fix became available but, in the text we read, names no advisory for the PHP2Shell CVEs; we also found none as of 2026-11-14 in CPR, NVD or the KEV entries. Check Check Point’s support site for the current fix. sk1000362 covers CVE-2026-123039 only.
- If any hunt hits, preserve the appliance and ESXi logs before rebooting.
- Treat ESXi hosts reachable from the gateway as in scope, and rotate
vpxuserand related credentials only after evidence is collected.
CPR’s SHA-256 hashes are listed in its article; load them into your EDR and file-scanning tools from the source rather than copying from secondary summaries.