Threat Hunt Plan: Check Point Quantum VPN Certificate-Path Exploitation — Unauthenticated RCE on Security Gateway and Security Management Server

Version 1.0 — September 11, 2026

Hunt Objective and Scope

This hunt determines whether an unauthenticated attacker has reached, exploited, or established post-exploitation access through the VPN certificate-handling path of a Check Point Quantum Security Gateway, Quantum Security Management Server, or Spark Firewall appliance. Two vulnerabilities disclosed on September 9, 2026 are in scope: CVE-2026-85102, an improper certificate trust validation flaw during VPN negotiation, and CVE-2026-85103, a heap-based buffer overflow in VPN certificate ASN.1 decoding. Both carry a CVSS v3.1 base score of 9.8, both are reachable pre-authentication from the network, and both yield arbitrary code execution on the affected device. The vendor reports no known in-the-wild exploitation and has published no indicators of compromise, so this hunt is evidence-driven rather than indicator-driven: it looks for the behavioral and crash-record traces that exploitation of a pre-authentication parser defect would leave.

Environment in scope: every Check Point Quantum Security Gateway and Spark Firewall terminating Remote Access VPN or Site-to-Site VPN; every Quantum Security Management Server and its management network; the VPN client address pool and the internal segments those pools can reach; the administrative workstations running SmartConsole; and any IT/OT demarcation where a Check Point gateway enforces the boundary between an enterprise network and a process, plant, or substation network. Affected builds are R82.10 with Jumbo Hotfix Take 43 or below, R82 with Take 125 or below, and R81.20 with Take 165 or below; devices at or below those levels are the priority population, and devices already remediated remain in scope for retrospective hunting.

Time window: September 1, 2026 through the present as the primary window, extended to 180 days for the external-exposure leg and for any gateway whose patch state cannot be confirmed. The extension matters because two earlier 2026 Check Point vulnerabilities — CVE-2026-50751 and CVE-2026-16232, both authentication weaknesses and both reported as exploited in the wild — establish that this device population has been under active attack for months; a hunt bounded to the disclosure date of the current pair would miss an actor who arrived through the earlier pair and is already resident. Where gateway log retention is shorter than the window, record the retention limit as a coverage bound on every negative finding.

Out of scope: exploitation attempts against non-Check Point VPN concentrators, and active scanning or probing of any internet-facing asset. The external-exposure leg is strictly passive and uses third-party scan indices only.

Hypotheses and Hunt Procedures

Hypothesis 1: an external actor can reach an internet-facing Check Point Quantum Security Gateway, Spark Firewall, or Security Management Server instance in the affected build range, observable as an exposed service in passive internet-scan indices. Execute FIRST; its output scopes the internal hypotheses.

MITRE ATT&CK: Reconnaissance | T1595 Active Scanning (defender-side: passive discovery of what an actor would enumerate) · Initial Access | T1133 External Remote Services · ICS | T0883 Internet Accessible Device — the vulnerable code path is reachable from any host that can complete IKE negotiation with the gateway, so internet reachability is the first-order determinant of exposure.

Collection Queries — passive external indices (STRICTLY passive; never probe target infrastructure):

Shodan — author unscoped first to prove the filter matches the product, then scope with ONE ownership anchor per query (anchors are never AND-ed together):

Censys — CenQL form only (`host.services.*`); the legacy CSL form returns zero rows with no error:

Netlas — tie-breaker for the two engines above:

Cross-reference every exposed service and version banner against the CISA Known Exploited Vulnerabilities catalog (https://www.cisa.gov/known-exploited-vulnerabilities-catalog) and against CVE-2026-85102, CVE-2026-85103, CVE-2026-50751 and CVE-2026-16232. A KEV match on the earlier pair is a presumptive initial-access risk on the same device, independent of the current pair. Rank findings by ransomware ratio, not by entry count.

API keys are referenced by environment-variable name only — SHODAN_API_KEY, CENSYS_API_SECRET, CENSYS_ORG_ID, NETLAS_API_KEY. A missing key is non-blocking: skip that engine and record the coverage gap.

Analysis Queries — attribution and triage:

Attribute every hit with at least two independent ownership signals (PTR record, ASN registration, certificate CN or SAN, WHOIS/RDAP registrant, the organization's own public IP and cloud asset inventory) before reporting it. Shared hosting, CDN fronting and carrier NAT break attribution in both directions, so an unattributable hit is inconclusive, never negative.

Version-triage each banner against the affected build list (R82.10 Take 43 or below, R82 Take 125 or below, R81.20 Take 165 or below) and record the index scan timestamp alongside it. Check Point gateways frequently present no build string at all, so treat a version-silent banner as unresolved and verify the build from the device itself rather than reading the silence as safe.

Corroborate every candidate in at least two of Shodan, Censys and Netlas before escalating. Absence from one index means only that the index did not observe the host.

Historical pivot: establish whether the exposure spans September 9, 2026 and, for the extended window, whether it spans the June and July 2026 disclosures. Continuous exposure across a disclosure date means the instance was presumptively enumerated.

Pivot into the internal hypotheses: every confirmed-owned, in-range instance becomes a priority target for Hypotheses 2, 3 and 4, hunted exhaustively rather than sampled. Where an exposed gateway also enforces an IT/OT boundary, escalate to the OT analysis leg and document the blast radius — internet reachability of a device that mediates access to a control environment is a finding in its own right under IEC 62443 and NERC CIP, independent of confirmed exploitation.

Hypothesis 2: an unauthenticated actor has exploited the certificate path during IKE negotiation against a Check Point gateway, observable as malformed-certificate and ASN.1 decode failures, VPN daemon faults and unexpected service restarts in gateway telemetry forwarded to the SIEM.

MITRE ATT&CK: Initial Access | T1190 Exploit Public-Facing Application — the negotiation endpoint is the exploited interface; Initial Access | T1133 External Remote Services — the VPN service is the entry vector; Impact | T1499.004 Endpoint Denial of Service: Application or System Exploitation — a failed heap-overflow attempt commonly manifests only as a daemon crash.

Collection Queries:

CrowdStrike Falcon LogScale (CQL) — Check Point gateway and management-server syslog forwarded into NG-SIEM as third-party data. Field names for third-party feeds are parser-dependent and vary by tenant: confirm the parsed field names in the tenant's own data before running these at scale, and treat a zero result from an unconfirmed parser as non-conclusive rather than negative.

BPF packet capture — capture IKE negotiation at the gateway's external interface for the hunt window. `-G` requires a strftime pattern in the output filename or each rotation overwrites the previous file:

Datadog Log Search — the same events where Check Point syslog is forwarded to Datadog rather than to the SIEM:

Datadog Live Process Monitoring (Infrastructure > Processes — not a log source, no `source:` filter):

Data source gaps to declare explicitly before running this leg: Check Point syslog is frequently forwarded at a severity threshold that drops the informational certificate-parse lines this hypothesis depends on, VPC flow logs are often not forwarded for the gateway's own subnets, and Live Process Monitoring is rarely enabled on a Gaia appliance. Where any of these holds, fall back to the `source:windows` and `source:checkpoint` log searches above and record the gap as a bound on the result.

Windows Event IDs to collect on the Security Management Server where it runs on Windows:

OT Data Collection: Claroty xDome — Devices → All Devices → Advanced Filters: filter to the boundary-enforcing firewall population and export CSV to seed the target list; then Risk & Exposures → Vulnerabilities → All Vulnerabilities filtered to CVE-2026-85102 and CVE-2026-85103 to enumerate affected devices the platform already sees.

OT Data Collection: Dragos Platform — In Assets, scope to the network-security appliance population at Purdue Level 3.5 with an active Now-flagged CVE and carry it forward as the Hypothesis 2 population; triage Notifications filtered to ATT&CK-ICS Initial Access (T0866, T0822) across the L3/L3.5 boundary.

OT Data Collection: Nozomi Guardian — Open the asset view for each gateway and record its peer set, protocol mix and open vulnerabilities before dispositioning; use Time machine / replay to replay the hunt window against the current rule set and establish whether a detection would have fired at the time.

OT Data Collection: Armis Centrix — enumerate the appliance population and its external connection surface:

OT Data Collection: Tenable OT Security — Inventory → All Assets: filter to the firewall and network-appliance asset types and the Check Point vendor, and export as the hunt population; Risks → Findings: filter to the advisory's plugin or CVE and carry every affected asset forward as a priority target.

OT Data Collection: Forescout eyeInspect — In Command Center → Asset Inventory, filter `purdue_level` in (3,4) and `main_vendor_model` matching Check Point and export the host list as the hunt population; pull Alerts filtered to the hunt window and group by `event_type_names` and `src_ip`.

SNMP polling — device-facing switch port and the appliance itself:

Poll at 60-second intervals across the hunt window and diff successive values; an error burst or a traffic spike on the gateway-facing port that correlates with a daemon restart is corroborating evidence. Any `-v1` or `-v2c` community-string access to an OT-adjacent asset is itself a finding — those credentials transit essentially in the clear. Collect trap-receiver logs for the window and flag coldStart (1.3.6.1.6.3.1.1.5.1) and warmStart (1.3.6.1.6.3.1.1.5.2) traps from gateway addresses, which indicate a device restart the change record should explain.

YARA file-system scan — staged tooling on the gateway filesystem after code execution:

Analysis Queries:

CrowdStrike Falcon LogScale (CQL) — rate and rarity analysis over the collected negotiation records:

Wireshark display filters — certificate payload analysis on the captured IKE traffic:

A certificate payload markedly larger than the population norm, a certificate payload that fails dissection, or a negotiation that terminates immediately after the certificate payload with no subsequent exchange are the three shapes worth pulling on.

Datadog Log Analytics — same base query, aggregated:

Datadog Monitor — Check Point certificate-parse failure burst:

Windows Event Log analysis on the management server:

Cluster the crashes by hour and compare against the change record and the maintenance calendar. A single crash during a patch window is expected; a cluster of crashes on an unpatched, internet-reachable gateway outside any window is the finding.

OT network and protocol analysis: where the gateway enforces an IT/OT boundary, establish for each crash or restart event whether the outage had a process consequence — correlate the gateway's restart timestamps against historian gaps, SCADA alarm bursts and HMI communication-loss alarms for the same minute. A gateway restart that produced a control-network communication alarm is an availability impact that must be reported whether or not exploitation is confirmed.

YARA memory scan — the VPN daemon's address space, where an ASN.1 heap-overflow payload would land. Process-memory scanning passes the PID as a positional argument; there is no `-p` flag for that purpose:

Where direct shell access to a Gaia appliance is not permitted by the operating model, run the equivalent scan on the Security Management Server instead, and use CrowdStrike Custom IOAs or Falcon Real Time Response (RTR) to execute the file-system and memory scans on the Windows management hosts remotely.

Hypothesis 3: an actor who achieved code execution on a Check Point gateway has used it as a network position, observable as outbound sessions originating from the gateway's own addresses to destinations outside the sanctioned baseline, or as inbound sessions from the VPN client pool to internal assets with no corresponding authenticated user session.

MITRE ATT&CK: Command and Control | T1071.001 Application Layer Protocol: Web Protocols — a gateway with egress to the internet is an ideal C2 host; Persistence | T1133 External Remote Services — the compromised concentrator is itself the persistence mechanism; Lateral Movement | T1021 Remote Services — movement from the gateway or the VPN pool into internal segments; Credential Access | T1003 OS Credential Dumping — credential material harvested on the first internal host reached.

Collection Queries:

CrowdStrike Falcon LogScale (CQL):

BPF packet capture — egress from the gateway's own addresses, which in a healthy deployment is limited to updates, licensing and logging:

Datadog Log Search:

Datadog Live Process Monitoring:

Data source gaps: VPC and firewall flow logs for the gateway's own interfaces are the single most common omission and without them egress from the appliance is invisible; where they are absent, the `source:windows` and `source:kubernetes` searches above only show the internal half of each session, and the negative must be recorded as partial.

Windows Event IDs to collect:

OT Data Collection: Claroty xDome — Network → Communication → Communication Analysis: Side A Purdue Level 4, Side B Purdue Level 2, time frame Past Month, to enumerate every flow crossing from the enterprise side into the control network through the gateway; export the result as the candidate lateral-movement set.

OT Data Collection: Dragos Platform — Communications Hub: source-zone Level4 AND dest-zone Level2 AND protocol IN [RDP,SSH,VNC,SMB] over 30 days, then pivot each cross-Purdue session to its asset record and event PCAP.

OT Data Collection: Nozomi Guardian — Use the link view to confirm the peer pair and protocol for each flagged conversation, then open the alert detail and export the attached PCAP for offline analysis.

OT Data Collection: Armis Centrix — enumerate remote-access sessions crossing into the control-network device population:

OT Data Collection: Tenable OT Security — Network → Network Map: group by Purdue level and read which levels the gateway's addresses actually reached during the window.

OT Data Collection: Forescout eyeInspect — Retrieve the PCAP for each escalated `alert_id` and run it offline for function-code and JA3 analysis; add any confirmed C2 domain to the sensor domain blacklist and the client JA3 hash to the SSL client blacklist so the next occurrence alerts natively.

YARA file-system scan — staged tooling on the first internal hosts reached from the pool:

Analysis Queries:

CrowdStrike Falcon LogScale (CQL) — reconciliation and rarity:

Wireshark display filters — egress characterization:

A gateway that initiates TLS to a server name outside the vendor update, licensing and logging set is the finding; record the JA3 or JA4 fingerprint of each such handshake, because it installs directly as a detection on several OT monitoring platforms.

Datadog Log Analytics:

Datadog Monitor — gateway-sourced egress to a non-sanctioned destination:

Windows Event Log analysis:

Left-join this export against the VPN concentrator's own authenticated-session log by user and source address. A logon from the VPN pool with no matching authenticated VPN session is the highest-value single finding in this hunt: it means the pool address was used by something that did not authenticate through the portal.

OT network and protocol analysis: for every cross-boundary session surfaced above, decode the industrial protocol payload where one is present and classify the function codes. A read-only poll from an enterprise-side address is a segmentation finding; a write, a mode change or a program download from an enterprise-side address is an incident. Correlate each against the historian and the engineering change record for the same window.

YARA memory scan — credential tooling and injected modules on the internal hosts reached:

Scanning LSASS memory requires SeDebugPrivilege; where the hunt account does not hold it, execute the scan through CrowdStrike Falcon Real Time Response (RTR) instead, which runs in the sensor's context on the remote host.

Hypothesis 4: an actor who reached the Quantum Security Management Server has abused the management plane, observable as policy installations, administrator sessions or configuration changes that do not correlate to an approved change record, and as the distribution of those changes to managed gateways.

MITRE ATT&CK: Defense Evasion | T1562.004 Impair Defenses: Disable or Modify System Firewall — a permissive rule installed from the policy authority is both the evasion and the objective; Persistence | T1098 Account Manipulation — a new administrator or API key on the management server; Lateral Movement | T1021 Remote Services — the management server reaches every gateway by design; ICS | T0858 Change Operating Mode — where a distributed policy change opens a path into a control network.

Collection Queries:

CrowdStrike Falcon LogScale (CQL):

BPF packet capture — the management plane:

Datadog Log Search:

Datadog Live Process Monitoring:

Data source gaps: the Check Point management audit log is often retained only on the management server itself and not forwarded, which is precisely the log an actor on that server would be positioned to alter; where it is not forwarded off-box, treat the on-box copy as untrusted evidence, and fall back to the `source:windows` account-change search and the SmartConsole process telemetry above.

Windows Event IDs to collect:

OT Data Collection: Claroty xDome — Alerts & Threats → OT Activity: filter program-download and mode-change events outside approved windows and correlate each asset to its communication map, to establish whether a distributed policy change was followed by engineering activity in the control network.

OT Data Collection: Dragos Platform — Query the Industrial Protocols QFD for unauthenticated writes outside the maintenance window and pivot the Server Stats QFD PCR for peers trending toward −0.99, which identifies an exfiltration server.

OT Data Collection: Nozomi Guardian — Review process-variable trends for the affected controllers across the window and flag any excursion outside the learned band with no corresponding operator action.

OT Data Collection: Armis Centrix — enumerate management-plane reachability from outside the administrative population:

OT Data Collection: Tenable OT Security — Events: filter Event Category to Configuration Events with event types "Change in state" and "Change in firmware version" across the window, and correlate each against the change record.

OT Data Collection: Forescout eyeInspect — Export the host changelog for the hunt window filtered to the controller population and escalate any `firmware_version` or `os_version` transition with no corresponding maintenance work order.

YARA file-system scan — persistence artifacts on the management server:

Analysis Queries:

CrowdStrike Falcon LogScale (CQL):

Wireshark display filters — management-plane session analysis:

Datadog Log Analytics:

Datadog Monitor — policy installation outside a change window:

Windows Event Log analysis:

Reconcile every account creation and privileged group addition against the identity-management request record. On a management server the expected count for a 30-day window is usually zero.

OT network and protocol analysis: for every policy installation with no approved change record, diff the installed rule base against the prior revision and identify any rule that newly permits an enterprise-side source to reach a control-network destination. Where such a rule exists, treat the corresponding flow records as the exploitation evidence and hunt them exhaustively in the OT platform.

YARA memory scan — management-server process memory:

Threat Actor Profile

Opportunistic mass-exploitation actors are the most probable first movers and the reason this hunt is time-critical. Sophistication is moderate: they do not develop the primitive themselves but weaponize a published proof of concept or reverse the patch, then sweep the internet-facing population indiscriminately. Their access path is exactly the surface Hypothesis 1 measures — an internet-reachable IKE endpoint — and their TTPs are a scan-and-exploit loop followed by a web shell or reverse shell on the appliance, credential harvesting from the gateway configuration, and resale of the access. For the current pair no public proof of concept exists as of September 11, 2026, which is the only reason this actor class has not yet arrived; the earlier 2026 Check Point vulnerabilities show the interval between disclosure and mass exploitation for this product family is short.

Ransomware affiliates and initial-access brokers are the highest-impact actor class for an industrial operator. Sophistication is moderate to high in operations rather than in exploit development: they buy or borrow the access, then spend days to weeks on internal reconnaissance, credential theft and backup destruction before staging encryption. Their access path is a compromised edge device precisely because it grants a position inside the perimeter with no endpoint agent watching, and their TTPs run through T1133 external remote services, T1003 credential dumping, T1021 lateral movement over RDP and SMB, T1490 inhibit system recovery, and T1486 data encrypted for impact. An operator whose Check Point gateway also enforces an IT/OT boundary should assume that a successful compromise places the actor one hop from the control network.

Nation-state actors targeting critical infrastructure are the lowest-frequency and highest-consequence class, and they are the reason the extended 180-day window exists. Sophistication is high: they are the actor class that would exploit a certificate-path defect before disclosure, and they characteristically prioritize quiet persistence on network appliances over immediate effect, because an appliance has no endpoint agent, limited logging and an operator who reboots it without investigating. Their TTPs include living entirely in the device's own binaries, modifying the gateway's own logging to suppress evidence, and using the concentrator as a long-lived collection point rather than a springboard. For this class, the absence of noisy evidence is not evidence of absence, and the crash-and-restart record is often the only trace of the initial attempt.

Insiders and contractors with legitimate management access are in scope for Hypothesis 4 only. Sophistication varies and is usually irrelevant, because the access path is already granted: a legitimate SmartConsole session installing an unapproved permissive rule produces the same telemetry as a compromised administrator account, and the discriminator is the change record, not the technique.

Data Sources Required

Network: full packet capture at the gateway's external and management interfaces for the hunt window (IKE on UDP 500 and 4500; management on TCP 264, 18190, 18191, 18264 and 19009); NetFlow or IPFIX for the gateway's own subnets; firewall and VPC flow logs for the gateway's interfaces, without which egress from the appliance cannot be seen at all; and the VPN concentrator's authenticated-session log, which is the authoritative list the VPN-pool logon population must be reconciled against.

Endpoint: CrowdStrike Falcon telemetry (ProcessRollup2, NetworkConnectIP4, NetworkReceiveAcceptIP4, UserLogon) on the internal hosts the VPN pool can reach and on every administrative workstation running SmartConsole; Windows Security, System, Application and PowerShell Operational logs from the Security Management Server and the administrative workstations; Sysmon where deployed, for process and network events the native logs do not carry.

Vendor and device logs: Check Point gateway syslog at informational severity or lower, forwarded off-box — the certificate-parse and daemon-fault lines this hunt depends on are frequently filtered out by the export policy, so confirm the severity threshold before treating a zero result as meaningful; the Check Point management audit log, forwarded off-box, since the on-box copy is alterable by an actor on that server; the appliance's own crash and core-dump record; and the current Jumbo Hotfix Take level per device, which is what separates the vulnerable population from the remediated one.

OT and ICS: process historian data for the hunt window, to establish whether a gateway restart had a process consequence; SCADA and HMI alarm logs, particularly communication-loss alarms; PLC and controller event logs; and exports from every deployed OT monitoring platform — Claroty xDome device and communication-analysis exports, Dragos asset and Communications Hub data with event PCAPs, Nozomi asset, link and variable views, Armis device and connection queries, Tenable OT inventory and configuration events, and Forescout asset inventory, alerts and host changelog. Record any sensor in an unhealthy state or any stopped collection module before dispositioning: a clean result from an unhealthy sensor is non-conclusive, not negative.

External attack surface: the passive scan indices queried read-only — Shodan, Censys and Netlas; the CISA Known Exploited Vulnerabilities catalog; and the organization's authoritative public IP range, ASN and cloud asset inventories. The last of these is required for attribution and is the binding constraint on the whole external leg — where the public IP inventory is incomplete, the sweep is bounded exactly where it matters and the exposure determination cannot be made for the unlisted ranges. Missing API credentials for any engine are non-blocking; skip the engine and record the coverage gap.

Detection Signatures

SIGMA rule 1 — a shell or script host spawned by the Check Point management client, which is not a behaviour the console produces in normal use:

SIGMA rule 2 — an outbound session whose source is a Check Point gateway or management address and whose destination is neither internal nor a sanctioned vendor endpoint:

SIGMA rule 3 — an interactive shell on the gateway's own operating system, reached from the VPN daemon's process tree:

SIGMA rule 4 — management-API rule manipulation through PowerShell on an administrative workstation:

Snort/Suricata rule 1 — an oversized certificate payload in an IKE exchange, the wire shape a heap-overflow attempt against the ASN.1 decoder would present. This is a heuristic on payload size rather than a signature for a known exploit, so it carries a detection_filter to suppress the single-packet noise of normal large certificate chains:

Snort/Suricata rule 2 — external reconnaissance and access against the Check Point management and topology services, which should never be reachable from outside the management network:

YARA rule 1 targets the file artifacts an actor leaves on the appliance filesystem after reaching code execution: a reverse shell or a small staging script written into one of the few writable paths on a Gaia system. The condition requires a scripting-language marker together with either a reverse-shell construct or a Check Point-specific path reference, because either marker alone is common in legitimate vendor and support scripts; requiring the pair, and keeping the file-size ceiling low, holds the rule to the small dropped-tool shape rather than matching the vendor's own large maintenance scripts.

YARA rule 2 targets the in-memory shape of a successful ASN.1 heap-overflow against the VPN daemon: a certificate-decoding context holding shellcode-like structure alongside the decoder's own strings. The condition anchors on the decoder marker so the rule only fires inside the relevant process context, then requires either a heap-spray pattern or two independent shellcode indicators, which keeps a single coincidental byte sequence in a large address space from producing a hit.

YARA rule 3 is the standing credential-dumping rule, included because Hypotheses 3 and 4 both involve lateral movement and credential access on the internal hosts reached from a compromised gateway. Each branch pairs a tool-specific marker with the LSASS target so a bare tool name in an unrelated document does not fire, and the fifth branch catches unnamed tooling by requiring a memory-read API together with the LSASS target and one tool indicator. Scanning LSASS memory requires SeDebugPrivilege; where the hunt account lacks it, run the scan through CrowdStrike Falcon Real Time Response so it executes in the sensor's context.

Indicators of Compromise

Network indicators: repeated IKE negotiations from a single external source that terminate immediately after the certificate payload; IKE certificate payloads markedly larger than the deployment norm, or payloads that fail protocol dissection; any established session from an external source to TCP 264, 18190, 18191, 18264 or 19009; any outbound session whose source is a gateway or management-server address and whose destination is neither internal nor a sanctioned vendor endpoint; a TLS client hello from a gateway address to a server name outside the vendor update, licensing and logging set, recorded with its JA3 or JA4 fingerprint; and interactive logons sourced from the VPN client pool with no matching authenticated session in the concentrator's own log.

Host indicators: VPN daemon, firewall worker or management daemon faults, core dumps and watchdog restarts in the gateway log, particularly in clusters and particularly outside a maintenance window; a shell, interpreter or network utility whose parent is one of those daemons; a small scripted artifact in a writable Gaia path such as /tmp, /var/tmp or an administrator home directory; a policy installation with no approved change record; a new Check Point administrator, API key or local account on the Security Management Server; a SmartConsole process whose child is a command shell or script host; and credential-dumping tooling on any internal host that received a session from the VPN pool.

OT and operational indicators: a gateway restart that coincides with a historian gap or an HMI communication-loss alarm, which is an availability impact whether or not exploitation is confirmed; a newly installed firewall rule that permits an enterprise-side source to reach a control-network destination; an industrial-protocol write, mode change or program download whose source address sits on the enterprise side of the boundary the gateway enforces; and a controller firmware or configuration transition with no corresponding maintenance work order.

External exposure indicators: a Check Point management, topology or IKE service observable in a passive scan index and attributable to the organization by at least two independent ownership signals; a banner indicating a build at or below R82.10 Take 43, R82 Take 125 or R81.20 Take 165; continuous index observation of such an instance spanning September 9, 2026, or spanning the June or July 2026 disclosure dates, which means the instance was presumptively enumerated; and any exposed instance whose addresses also appear in the flow records reaching a control-network segment.

No network or file indicators have been published by the vendor or by any government authority for CVE-2026-85102 or CVE-2026-85103. This hunt is therefore behavioral throughout, and a negative result carries weight only to the extent that the data sources in Section 4 were actually present and healthy.

False Positive Baseline

Vendor hotfix installation and Check Point Live Patch application. The Live Patch rollout that began on September 9, 2026 legitimately invokes shell helpers from the daemon context and restarts services, producing exactly the parent-child process shape SIGMA rule 3 detects and exactly the daemon-restart record Hypothesis 2 hunts. Suppress by correlating every restart and daemon-spawned shell against the Live Patch and hotfix installation record for the same device and minute; what remains is the finding.

Legitimate certificate-chain size and certificate rotation. Site-to-Site peers using long certificate chains, and any deployment that has recently rotated its VPN certificates, produce large IKE certificate payloads and a burst of negotiation failures while peers are mismatched. Baseline the payload-size distribution per peer before treating a large payload as anomalous, and correlate failure bursts against the certificate-rotation record. The detection_filter on the Snort rules exists for this reason.

Sanctioned policy automation. Infrastructure-as-code pipelines and policy-compliance tooling invoke mgmt_cli and the management web API on a schedule, which is indistinguishable by technique from an actor using the same interface. Allowlist by host and service account, and reconcile the remainder against the change record rather than the technique.

Vulnerability scanners and the organization's own external testing. Authorized scanners generate connection attempts to the management and topology ports, malformed protocol traffic, and failed negotiations at a rate that will dominate every Hypothesis 2 query. Obtain the scanner source addresses and the authorized testing calendar before the hunt begins and exclude them explicitly, noting the exclusion in the report so a reader knows what was not examined.

Administrative jump-host and support-session activity. Vendor support cases involve diagnostic scripts run on the appliance and interactive sessions from a support jump host, both of which look like post-exploitation access. Reconcile against the open-case record; a session correlating to an open vendor case with a matching timestamp is expected, and one that does not is not.

Maintenance-window policy installations and cluster failovers. A cluster member taking over produces service restarts, log gaps and a burst of negotiation activity on the surviving member; a scheduled policy install produces the same audit records an actor's would. Configure monitor downtime for the standing maintenance windows and hold the hunt to out-of-window events, rather than triaging the same expected events every iteration.

External-exposure misattribution. A passive-index hit on shared hosting, behind a CDN, or inside a carrier NAT range can be attributed to the wrong organization in either direction, and a provider's ASN is not an ownership anchor. Require two independent ownership signals before reporting any external hit, and record an unattributable hit as inconclusive rather than as either a finding or a clean result.

Escalation Criteria

1. Any YARA hit on CheckPoint_Gaia_Staged_Shell_Artifacts against a Gaia appliance filesystem path. A scripted reverse-shell or staging artifact on a gateway is not explainable as a tuning artifact; engage incident response immediately and preserve the appliance state before any reboot.

2. Any YARA hit on CheckPoint_VPND_ASN1_Exploit_Memory_Artifacts against the VPN daemon, firewall worker or management-daemon address space. This is direct evidence of exploitation of the certificate-decode path; capture a memory image before restarting the daemon, because a restart destroys the only copy of the evidence.

3. Any YARA hit on Credential_Dump_Tool_Memory_Artifacts on a host that received a session from the VPN client pool or from a gateway address. Credential theft downstream of an edge-device compromise converts a device incident into a domain incident; escalate to full incident response and begin credential rotation.

4. Any interactive logon sourced from the VPN client pool with no matching authenticated session in the concentrator's own log, confirmed after reconciliation. The pool address was used by something that did not authenticate.

5. Any outbound session originating from a gateway or management-server address to a destination outside the sanctioned vendor-update, licensing and logging set, where the destination cannot be attributed to a known vendor service.

6. Any shell, interpreter or network utility whose parent process is the VPN daemon, firewall worker or management daemon, after the Live Patch and hotfix installation record has been excluded.

7. Any Check Point policy installation, administrator creation or API-key creation with no corresponding approved change record, on any management server.

8. Any newly installed firewall rule permitting an enterprise-side source to reach a control-network destination, or any industrial-protocol write, mode change or program download whose source sits on the enterprise side of the boundary the gateway enforces.

9. Any cluster of VPN daemon faults, core dumps or watchdog restarts on an unpatched, internet-reachable gateway outside a maintenance window, whether or not code execution can be demonstrated. Treat as presumptive exploitation attempt and patch on an emergency basis.

10. External exposure of a Check Point management, topology or IKE service confirmed in at least two passive indices, attributable to the organization by at least two independent ownership signals, and presenting a banner at or below the affected Take levels — or index observation of such an instance spanning September 9, 2026 or either of the June and July 2026 disclosure dates, which means presumptive enumeration.

11. Any exposed instance identified by Hypothesis 1 whose addresses also appear in flow records reaching a control-network segment. Internet reachability of a device that mediates access to a control environment is escalated on discovery, independent of confirmed exploitation.

12. Any KEV-listed Check Point vulnerability present on an in-scope device, including CVE-2026-50751 and CVE-2026-16232 from earlier in 2026, discovered during the sweep.

Hunt Completion Criteria and Reporting

The hunt is complete when the external-exposure sweep has run against the organization's full authoritative public IP and ASN inventory in at least two indices, with every in-range hit either attributed and triaged or explicitly recorded as inconclusive; when the Jumbo Hotfix Take level of every Check Point gateway, Spark Firewall and management server has been established from the device itself rather than from an inventory record; when the certificate-parse, daemon-fault and restart record has been examined across the primary window for every device whose logs reach the required severity, and the extended 180-day window for every device whose patch state could not be confirmed; when every interactive logon sourced from the VPN client pool has been reconciled against the concentrator's authenticated-session log; when every policy installation and administrator change on every management server has been reconciled against the change record; when the YARA file-system and memory scans have run on every device where the operating model permits it, and the exclusions are named where it does not; and when, for any gateway enforcing an IT/OT boundary, the cross-boundary flow records have been examined and every gateway restart has been correlated against historian and alarm data.

The report must contain: the device population with per-device software branch, Take level, remediation status and remediation date; the external-exposure result with per-hit provenance — which engines observed it, the index scan timestamps, the ownership signals used for attribution, and the version-triage outcome; the queries actually executed, per platform, with their time windows; the disposition of every finding as Positive, Negative or Non-Conclusive, with Non-Conclusive requiring the named missing input rather than a general caveat; and an explicit coverage statement recording every data-source gap encountered — gateway syslog severity filtering, absent flow logs for the appliance's own interfaces, unforwarded management audit logs, unhealthy OT sensors, stopped collection modules, retention shorter than the hunt window, and any engine skipped for want of a credential. A negative finding carries weight only in proportion to the coverage behind it, and a clean result from an unhealthy sensor is non-conclusive, not negative.

Two items belong in the recommendations regardless of outcome. First, the external-exposure sweep should become a recurring control rather than a one-off exercise: a Check Point management or topology service exposed to the internet is a finding on discovery, and the population changes as cloud deployments and firewall rules change. Second, where the hunt could not confirm a device's patch state or read its logs, the gap is itself the deliverable — name the device, name the missing input, and state what would have to be forwarded or retained for the next iteration to answer the question this one could not.

Advisory IoC Reference