PHP2Shell Vulnerabilities in Check Point Gateways Used to Deploy TSGA Backdoor

Starting on October 30, attackers began exploiting two distinct vulnerabilities in Check Point environments to gain and deepen access to compromised networks. The initial breach relied on the PHP2Shell flaws in Check Point Security Gateways, which allowed attackers to execute code remotely without authentication. Once inside, the threat actor leveraged a known local privilege escalation vulnerability in Gaia OS, the underlying operating system of Check Point appliances, to move from gateway-level access to system-level control. The first wave of targeting focused on Israeli organizations, followed by broader follow-up attacks against other regions. Check Point published details of the campaign, which is significant because it shows how multiple unpatched systems in a single vendor's stack can be chained together to achieve complete compromise.

PHP2Shell is not a single vulnerability but a category of flaws that allow attackers to upload or manipulate PHP files on web-facing systems, particularly in appliances that run web-based management interfaces. In the context of Check Point gateways, these vulnerabilities could allow an unauthenticated attacker to place malicious PHP code on the device, which then executes with the privileges of the gateway's web service. The PHP2Shell name itself derives from the practice of converting uploaded files into interactive shells that give attackers command-line access. Check Point gateways, being network security devices, often sit in high-trust network positions and can communicate with internal systems. Once an attacker gains shell access to a gateway, they can pivot deeper into the network or use the device itself to attack other infrastructure.

After obtaining initial access via PHP2Shell, attackers did not stop at gateway-level permissions. They immediately exploited a known local privilege escalation flaw in Gaia OS, the hardened Linux-based operating system that powers Check Point appliances. This second vulnerability allowed the attacker to escalate from web service privileges to root, meaning complete control of the device. The combination of remote code execution followed by privilege escalation creates what is called a full-chain exploit: an attacker can go from no access to total system compromise in a single attack sequence. Organizations that had patched one vulnerability but not the other remained vulnerable, a common scenario when patch management is inconsistent or when security teams are unaware of the severity of the dependencies.

Once the attackers achieved root access, they deployed a backdoor called TSGA, designed for long-term persistence and command-and-control access. The name and detailed technical capabilities of TSGA have been documented by Check Point, though the full source code or operational details have not been publicly released. Backdoors of this type typically allow attackers to maintain access even after the initial vulnerability is patched or the gateway is rebooted. Reports indicate that TSGA was used to perform destructive operations, including the wiping of ESXi files on connected virtualization infrastructure. This escalation from persistence to destruction suggests that the attackers may have had multiple objectives or that the campaign was reconnaissance-driven, with ESXi wipes serving as cover or distraction. ESXi is VMware's bare-metal hypervisor, widely used in enterprise data centers; wiping its files can disable entire virtual machine environments.

Vendor vulnerability chains are particularly dangerous because most organizations update a single appliance family on staggered schedules or across different approval gates. According to incident reports from security vendors responding to similar campaigns, attackers do not need to exploit dozens of flaws; they need to find two or three critical gaps in sequence that they can chain together. Check Point Gaia OS privilege escalation flaws have been disclosed over multiple years, and historical data shows that organizations often defer OS-level patches on appliances because they fear operational disruption. Meanwhile, web-facing vulnerabilities like PHP2Shell are discovered regularly in appliance web interfaces because developers sometimes reuse insecure patterns across different products. The implication for your infrastructure is clear: if your Check Point gateway was not patched for both the initial access vector and the privilege escalation path, you are at risk of full compromise.

If you run Check Point Security Gateways, watch for the following signs of potential compromise:

• Unexpected web service log entries showing PHP file uploads or suspicious requests to the gateway's management interface
• Unusual process execution from the gateway's web service user, especially commands that attempt to escalate privileges or spawn shells
• New or unexpected cron jobs or startup scripts on the Gaia OS system
• Outbound connections from the gateway to unknown or suspicious IP addresses
• ESXi systems connected to the gateway environment showing sudden file deletion or corruption
• Firmware or SSL certificate dates that do not match your maintenance records

Check Point and third-party vendors have published indicators of compromise (IOCs) and detection signatures; consult your security vendor for the latest rules and threat intelligence feeds.

Patching is not optional in this scenario. The vulnerability chain described here can result in complete loss of confidentiality, integrity and availability of your gateway and connected infrastructure. Begin by inventorying all Check Point Security Gateways in your environment and determining which version of firmware and Gaia OS you are running. Cross-reference your versions against Check Point security advisories for both the PHP2Shell vulnerabilities and the local privilege escalation flaws. Prioritize gateways that are internet-facing or that have direct network access to critical systems like hypervisors. If you cannot patch immediately, implement temporary controls such as restricting network access to the gateway's management interface, disabling remote management if not essential, and increasing monitoring of gateway logs and system behavior. After patching, review your change management and patch governance processes to ensure that vulnerabilities in critical appliances do not sit unpatched for extended periods.

What versions of Check Point gateways are affected by PHP2Shell?

PHP2Shell vulnerabilities can affect multiple versions of Check Point Security Gateway depending on the specific flaw. Check Point publishes detailed security advisories that list affected versions by product name and firmware release. You must check the official Check Point security portal or advisory documents to confirm which of your systems are vulnerable; do not assume that older versions are unaffected.

Can I detect TSGA backdoor if it is already installed?

TSGA, like most sophisticated backdoors, is designed to evade detection, but forensic investigation of compromised Check Point gateways has revealed its presence through process inspection, network traffic analysis, and file system artifacts. If you suspect compromise, engage a qualified incident response team and preserve logs and memory before making changes. Do not rely solely on signature-based antivirus scanning on the gateway itself.

Does patching Check Point remove TSGA if it is already installed?

Patching the underlying vulnerabilities does not automatically remove a backdoor that is already resident on the system. If you believe your gateway has been compromised, you must assume the backdoor is present and either perform deep forensic cleanup, reload the gateway from a trusted backup or image, or replace the device entirely. Patching alone is not sufficient for incident recovery in this scenario.

Are non-Israeli organizations at risk from this campaign?

The initial targeting focused on Israeli entities, but the vulnerabilities being exploited are not geographically limited. Follow-up waves were observed targeting other regions. Any organization running unpatched Check Point Security Gateways is potentially at risk from attackers using the same exploit techniques, whether or not they are part of the initial campaign.

Source: The Hacker News