Detect Check Point Security Gateway Improper Authentication (CVE-2026-50751) in Microsoft Sentinel
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
KQL Detection Query
let timeWindow = 1h;
let suspiciousIKE = CommonSecurityLog
| where TimeGenerated > ago(timeWindow)
| where DeviceVendor == "Check Point"
| where Activity has_any ("IKE", "VPN", "IPSec")
| where Message has_any ("IKEv1", "ikev1", "phase1", "aggressive mode")
| where Message has_any ("auth", "authentication", "identity", "failed", "bypass", "invalid")
| project TimeGenerated, DeviceAction, SourceIP, DestinationIP, Message, Activity, DeviceName;
let authAnomalies = CommonSecurityLog
| where TimeGenerated > ago(timeWindow)
| where DeviceVendor == "Check Point"
| where Activity has "VPN"
| where DeviceAction in ("Accept", "Allow")
| where Message has_any ("unauthenticated", "no credentials", "pre-shared", "certificate")
| project TimeGenerated, SourceIP, DestinationIP, DeviceAction, Message, DeviceName;
union suspiciousIKE, authAnomalies
| summarize EventCount=count(), Messages=make_set(Message, 10), Actions=make_set(DeviceAction) by SourceIP, DeviceName, bin(TimeGenerated, 5m)
| where EventCount > 2
| extend RiskScore = case(EventCount > 20, "High", EventCount > 5, "Medium", "Low")
| order by EventCount descDetects anomalous IKEv1 authentication patterns on Check Point Security Gateways that may indicate exploitation of CVE-2026-50751. Correlates IKEv1 negotiation events with authentication anomalies from the same source.
Data Sources
Required Tables
False Positives & Tuning
- Legitimate IKEv1 VPN clients connecting to gateway before hotfix disables deprecated protocol
- Network scanning tools performing VPN fingerprinting in authorized penetration tests
- Legacy VPN clients that have not been updated and still negotiate IKEv1
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.
- 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.
- 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.
- 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
- 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`.
- 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.
- 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.
- 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
- 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.
- 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
- 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.
- 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.
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 descindex=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_eventsAtomic Red Team Tests
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
ike-scan --aggressive [email protected] --auth=1 --trans=5,2,1,2 <GATEWAY_IP>Cleanup
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.
Generate multiple IKEv1 authentication failure events against the gateway by sending IKE proposals with invalid pre-shared keys, simulating an authentication bypass probe.
Command
for i in $(seq 1 10); do ike-scan --aggressive --id=bypass_test_$i --pskcrack --auth=1 <GATEWAY_IP>; sleep 2; doneCleanup
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.
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
strongswan_ikev1_test() { sudo ipsec up lab-ikev1-conn --ike=aes128-sha1-modp1024! --ikeversion=1 2>&1; }; strongswan_ikev1_testCleanup
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.