# 264/tcp - Pentesting Check Point Firewall

It's possible to interact with CheckPoint Firewall-1 firewalls to discover valuable information such as the firewall's name and the management station's name. This can be done by sending a query to port 264/TCP.

On modern deployments this is still useful because TCP/264 is the FW1_topo implied-rule service used for topology download by SecureClient / Endpoint Connect, so it often answers even when the policy is otherwise restrictive. A hit on this port is therefore both a fingerprint for Check Point and a clue that remote-access or management-related functionality is present somewhere behind the gateway.

Obtaining Firewall and Management Station Names

Using a pre-authentication request, you can execute a module that targets Check Point Firewall-1. The necessary commands for this operation are outlined below:

use auxiliary/gather/checkpoint_hostname
set RHOST 10.10.10.10

Upon execution, the module attempts to contact the firewall's SecuRemote Topology service. If successful, it confirms the presence of a Check Point Firewall and retrieves the names of both the firewall and the SmartCenter management host. Here's an example of what the output might look like:

[*] Attempting to contact Checkpoint FW1 SecuRemote Topology service...
[+] Appears to be a CheckPoint Firewall...
[+] Firewall Host: FIREFIGHTER-SEC
[+] SmartCenter Host: FIREFIGHTER-MGMT.example.com
[*] Auxiliary module execution completed

The leaked management hostname is usually the most valuable field. In real environments it often identifies the management domain, naming convention, site code, or the exact SmartCenter / Management Server to pivot into next.

Alternative Method for Hostname and ICA Name Discovery

Another technique involves a direct command that sends a specific query to the firewall and parses the response to extract the firewall's hostname and ICA name. The command and its structure are as follows:

printf '\x51\x00\x00\x00\x00\x00\x00\x21\x00\x00\x00\x0bsecuremote\x00' | nc -q 1 10.10.10.10 264 | grep -a CN | cut -c 2-

The output from this command provides detailed information regarding the firewall's certificate name (CN) and organization (O), as demonstrated below:

CN=Panama,O=MGMTT.srv.rxfrmi

In practice, CN is the gateway object / hostname and O commonly maps to the Internal CA / management naming context. That makes this response useful for building hostlists, targeted DNS brute-force, or prioritizing which management node to enumerate first.

Post-Discovery Enumeration

Once 264/TCP confirms a Check Point device, don't stop at the hostname leak. Use the leaked management name to prioritize the rest of the Check Point control plane:

Probe the management host and nearby gateway IPs for 443/TCP and Check Point control channels such as 18190/TCP (CPMI), 18191/TCP (CPD), 18210/TCP (ICA_PULL), 18211/TCP (ICA_PUSH), 18231/TCP (Policy Server login), and 18264/TCP (ICA_SERVICES).
These ports are frequently reachable only after landing on a VPN segment, jump host, or management VLAN, but FW1_topo gives you the names to look for.
If the environment enables Accept Control Connections, several of these services are opened automatically by design, so they are worth rescanning from every new foothold.

Quick sweep:

nmap -Pn -sT -p 264,443,18190,18191,18210,18211,18231,18264 <gateway-or-management-ip>

If valid administrator credentials are recovered, move from gateway fingerprinting to structured management enumeration. The Check Point Management API is scriptable via mgmt_cli or HTTPS web_api calls:

mgmt_cli login -u <user> -p '<pass>' -m <mgmt_ip> > id.txt
mgmt_cli show gateways-and-servers details-level full -s id.txt --format json | jq '.objects[] | {name, type, ipv4_address}'
mgmt_cli logout -s id.txt

The output commonly reveals gateway objects, cluster members, management IPs, and other pivot points that are much harder to infer from the firewall itself. Remember that the Management API lives on the management server, while the Gaia API is a separate HTTPS API for OS-level configuration on the gateway.

Recent Authenticated Management-Plane Abuse

A useful modern follow-up to 264/TCP discovery is testing whether the leaked management host exposes an outdated Gaia Portal.

In 2023, Check Point fixed an authenticated command-injection issue in the Gaia Portal Hosts and DNS page. The vulnerable flow passed the hostname field from /web/cgi-bin2/hosts_dns.tcl into a libdb set ... machine:hostname <value> command chain without sufficient sanitisation, so a user with write access to DNS / hostname settings could turn portal access into OS command execution.

Minimal reproduction pattern:

POST /cgi-bin/hosts_dns.tcl
hostname=test|`id`
domainname=lab.local
save=true

Why this matters during pentests:

264/TCP often tells you exactly which management host to target.
If that host exposes Gaia Portal and you later recover any delegated admin credential, hostname/DNS write access can become code execution on the appliance or management node.
Version triage matters here: Check Point states the fix is present in R82 and in later Jumbo Hotfix takes for R81.20 / R81.10 / R81 / R80.40.

Also keep internet-exposed Remote Access VPN / Mobile Access gateways in scope. In 2024, Check Point disclosed and observed exploitation around an information-disclosure issue affecting internet-connected gateways with remote access enabled. From an operator perspective, the practical lesson is to treat VPN portals and Gaia / management surfaces as a single attack chain: pre-auth leakage on the gateway can feed username discovery, credential attacks, and authenticated follow-on abuse against the management plane.

HTTP Security Server Format String Bug (CAN-2004-0039)

Affected builds: NG FCS, NG FP1, NG FP2, NG FP3 HF2, and NG with Application Intelligence R54/R55.
Requirement: The HTTP Security Server or AI HTTP proxy must be enabled and transparently inspecting the targeted port; if HTTP inspection is disabled the vulnerable code path is never reached.

Triggering the error handler

The proxy rejects malformed HTTP messages and builds its own error page with sprintf(errbuf, attacker_string);, letting attacker-controlled bytes act as the format string. Send an invalid request through the firewall and look for a proxy-generated error that reflects your payload:

printf 'BOGUS%%08x%%08x%%08x%%n HTTP/1.0\r\nHost: internal.local\r\n\r\n' | nc -nv [FIREWALL_IP] 80

If HTTP inspection is active, the firewall (not the backend server) answers immediately, proving the middlebox parsed and replayed the request line.

Exploitation

Format string primitive

Force the parser into the error routine (invalid method, URI, or headers).
Place attacker-controlled dwords up front so %x, %s, and %n directives treat them as stack arguments.
Use %x/%s to leak pointers, then %n/%hn to write the formatted byte count into chosen addresses, overwriting return pointers, vtables, or heap metadata before hijacking execution with injected shellcode or ROP.

Heap overflow primitive

The same unsafe sprintf() writes into a fixed-size heap buffer. Mix a long request body with oversized directives (e.g., %99999x) so the formatted output overruns the allocation and corrupts adjacent heap structures, letting you forge freelist pointers or function tables that are later dereferenced.

Impact

Compromise of the proxy grants code execution inside the firewall process (SYSTEM on Windows appliances, root on UNIX), enabling rule manipulation, traffic interception, and pivoting deeper into the management network.