CVE-2026-50751 CrowdStrike LogScale · LogScale

Detect Check Point Security Gateway Improper Authentication (CVE-2026-50751) in CrowdStrike LogScale

Detects exploitation of CVE-2026-50751, an improper authentication vulnerability (CWE-287) in Check Point Security Gateway affecting deprecated IKEv1 VPN protocol. This vulnerability is actively exploited in the wild (CISA KEV) and may allow unauthenticated attackers to bypass authentication controls on the VPN gateway. Detection focuses on anomalous IKEv1 negotiation patterns, authentication bypass indicators, and suspicious gateway access following failed or malformed IKE exchanges.

MITRE ATT&CK

Tactic
Initial Access Credential Access

LogScale Detection Query

CrowdStrike LogScale (LogScale)
cql
#event_simpleName=NetworkConnectIP4 OR #event_simpleName=NetworkConnectIP6
| DestinationPort in (500, 4500)
| RemoteAddressIP4=* OR RemoteAddressIP6=*
| join(event_simpleName=ProcessRollup2, field=[TargetProcessId, aid], include=[FileName, CommandLine])
  {
    FileName in ("fwk.elg", "vpnd", "ike", "iked")
    OR CommandLine matches /ikev1|IKEv1|aggressive.mode/i
  }
| groupby([RemoteAddressIP4, ComputerName, FileName], function=[count(as=event_count), collect(CommandLine)])
| event_count > 2
| sort(event_count, order=desc)
critical severity low confidence

CrowdStrike Falcon CQL query detecting processes associated with IKEv1 VPN daemon activity on Check Point gateway hosts, surfacing hosts with elevated connection counts to IKE ports as potential exploitation targets or sources.

Data Sources

CrowdStrike Falcon EDRNetwork Connection EventsProcess Events

Required Tables

NetworkConnectIP4NetworkConnectIP6ProcessRollup2

False Positives & Tuning

  • Falcon sensors deployed on VPN gateway infrastructure generating high baseline IKE connection volume
  • Authorized network performance testing tools establishing bulk IKE sessions
  • Check Point gateway processes during normal high-availability failover events

Other platforms for CVE-2026-50751


Testing Methodology

Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1IKEv1 Aggressive Mode Probe — Check Point Gateway

    Expected signal: Check Point SmartLog IKE phase 1 event with protocol IKEv1, mode aggressive, from the test host IP. UDP/500 connection event in network logs.

  2. Test 2Repeated IKEv1 Auth Failure Simulation

    Expected signal: 10 IKEv1 negotiation attempts with authentication failure events in SmartLog. Source IP flagged in Check Point IPS/firewall blade logs.

  3. Test 3IKEv1 vs IKEv2 Protocol Downgrade Attempt

    Expected signal: StrongSwan IKEv1 initiation attempt visible in system logs; Check Point gateway logs showing inbound IKEv1 proposal from test host on UDP/500.


Response Playbook

Triage

  1. Confirm whether the affected Check Point Security Gateway has the vendor-released hotfix applied (sk185033). Check installed hotfix version via Check Point SmartConsole or CLI: `cpinfo -y all | grep -i hotfix`.
  2. Identify all IKEv1-configured VPN communities and tunnels on the gateway. In SmartConsole, navigate to IPSec VPN > VPN Communities and audit for any IKEv1-only or mixed-mode communities that may still be active.
  3. Review Check Point SmartLog or syslog for the alerting source IP. Determine whether the IP belongs to a known VPN peer, a remote access user, or an external/unknown host. Cross-reference with threat intelligence feeds.
  4. Check for any successful VPN tunnel establishment or authenticated sessions from the suspicious source IP within 30 minutes of the alert. A successful session post-anomaly is a strong indicator of exploitation.

Containment

  1. If exploitation is confirmed or the source IP is unknown/malicious, immediately block the source IP at the perimeter firewall or in Check Point's IPS policy. Create a deny rule in SmartConsole for the offending IP on UDP/500 and UDP/4500.
  2. Apply the vendor hotfix (sk185033) immediately on all affected Security Gateways. If patching is not immediately possible, disable IKEv1 in all VPN community configurations as a compensating control: SmartConsole > VPN Community > Encryption > IKE version → set to IKEv2 only.

Evidence Collection

  1. Export SmartLog entries for the alerting gateway covering the 2-hour window around the alert. Filter for IKE, VPN, and authentication events. Archive to SIEM or evidence store with chain-of-custody documentation.
  2. Collect `cpinfo` output and gateway configuration snapshot (`fw ctl pstat`, `vpn tu`, `ike debug`) from the affected gateway. Preserve kernel table state showing active IKE SAs: `vpn tunnelutil` → option to list all tunnels.

Escalation Criteria

  • !Escalate immediately to incident response if any successful authenticated VPN session is identified from the suspicious source IP, indicating a full authentication bypass has occurred.
  • !Escalate if the affected gateway protects critical network segments (production, OT/ICS, PCI, or credential stores), or if lateral movement indicators are observed from the gateway's internal network interface.

Investigation Guide

Related Techniques

Forensic Artifacts

  • >Check Point SmartLog IKE phase 1 negotiation records showing IKEv1 aggressive mode exchanges from external IPs not in the authorized peer list
  • >Gateway kernel IKE SA table entries (`vpn tunnelutil`) showing established SAs with unexpected identities or certificates
  • >System authentication logs on the gateway appliance (`/var/log/messages`, Check Point audit logs in SmartConsole) for any privilege escalation or configuration changes post-VPN connection

Tuning Guidance

Reduce false positives by building and maintaining an allowlist of authorized IKEv1 VPN peer IPs (site-to-site peers that have not yet migrated). Apply the allowlist as a filter in the detection logic. Once the vendor hotfix is applied and IKEv1 is disabled, any IKEv1 negotiation attempt becomes inherently high-fidelity and the confidence can be raised to high. Consider raising severity to critical and reducing the event count threshold to 1 post-remediation. Monitor vendor advisory sk185033 for updated affected version ranges and adjust product/version filters accordingly.


Hunting Queries

Threat hunt for IKEv1 connections from source IPs that have not previously used IKEv2, over the past 7 days. New IKEv1-only sources may represent exploitation attempts targeting CVE-2026-50751.

Hunting — KQL
kql
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where DeviceVendor == "Check Point"
| where Message has_any ("IKEv1", "ikev1", "aggressive mode")
| where SourceIP !in (toscalar(
    CommonSecurityLog
    | where TimeGenerated > ago(30d)
    | where DeviceVendor == "Check Point"
    | where Message has "IKEv2"
    | summarize make_set(SourceIP)
  ))
| summarize FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated), EventCount=count() by SourceIP, DeviceName
| where EventCount > 1
| order by EventCount desc
Hunting — SPL
spl
index=firewall sourcetype=cp_log earliest=-7d
| where match(message, "(?i)IKEv1|aggressive.mode")
| stats min(_time) AS first_seen, max(_time) AS last_seen, count AS total_events BY src_ip, host
| where total_events > 1
| eval new_source=if(first_seen > relative_time(now(), "-24h"), "YES", "NO")
| sort - total_events

Atomic Red Team Tests

Test 1 IKEv1 Aggressive Mode Probe — Check Point Gateway
linux

Simulate an IKEv1 aggressive mode probe against a Check Point Security Gateway to generate IKE negotiation telemetry. Uses ike-scan to initiate IKEv1 phase 1 aggressive mode exchange.

Command

bash
ike-scan --aggressive [email protected] --auth=1 --trans=5,2,1,2 <GATEWAY_IP>

Cleanup

bash
No cleanup required; ike-scan does not persist state. Ensure gateway logs are retained for analysis.

Expected Telemetry

Check Point SmartLog IKE phase 1 event with protocol IKEv1, mode aggressive, from the test host IP. UDP/500 connection event in network logs.

Expected Detection

Detection rule should fire within 5 minutes, grouping the IKEv1 aggressive mode events from the test source IP and generating an alert with severity critical.

Test 2 Repeated IKEv1 Auth Failure Simulation
linux

Generate multiple IKEv1 authentication failure events against the gateway by sending IKE proposals with invalid pre-shared keys, simulating an authentication bypass probe.

Command

bash
for i in $(seq 1 10); do ike-scan --aggressive --id=bypass_test_$i --pskcrack --auth=1 <GATEWAY_IP>; sleep 2; done

Cleanup

bash
Review and clear test-generated IKE SA entries on the gateway: `vpn tunnelutil` → delete SAs from test IP.

Expected Telemetry

10 IKEv1 negotiation attempts with authentication failure events in SmartLog. Source IP flagged in Check Point IPS/firewall blade logs.

Expected Detection

Aggregated alert triggering after threshold (>2 events in 5 minutes) is crossed, with source IP and device name populated in alert fields.

Test 3 IKEv1 vs IKEv2 Protocol Downgrade Attempt
linux

Attempt to force the Check Point gateway to negotiate IKEv1 by sending an IKEv1-only proposal, even if IKEv2 is preferred, to test whether the gateway accepts deprecated protocol negotiations before hotfix.

Command

bash
strongswan_ikev1_test() { sudo ipsec up lab-ikev1-conn --ike=aes128-sha1-modp1024! --ikeversion=1 2>&1; }; strongswan_ikev1_test

Cleanup

bash
sudo ipsec down lab-ikev1-conn; remove temporary connection config from /etc/ipsec.d/ if created.

Expected Telemetry

StrongSwan IKEv1 initiation attempt visible in system logs; Check Point gateway logs showing inbound IKEv1 proposal from test host on UDP/500.

Expected Detection

Detection rule surfaces the IKEv1 negotiation event from the test host. If the gateway is unpatched and accepts the IKEv1 proposal, a successful SA establishment event would trigger escalation criteria in the playbook.

Related Detections