Contexto del incidente
El 8 de junio de 2026 Check Point publicó un hotfix de emergencia para CVE-2026-50751, una vulnerabilidad de improper authentication (CWE-287) con CVSS 9.3 que vive en el flujo de validación de certificados de IKEv1 sobre los blades Remote Access VPN, Mobile Access / SSL VPN y los appliances Spark Firewall. El vector completo es CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N: red, sin privilegios, sin interacción del usuario, alcance modificado.
El bug no es un memory corruption ni un RCE clásico. Es un error de lógica: el gateway llega a una conclusión equivocada al validar el intercambio IKEv1 y da por válida una sesión VPN que jamás presentó un password real. Resultado: un atacante remoto, no autenticado, establece un túnel hacia tu red interna sin haber tocado un teclado en tu endpoint. CISA lo agregó al KEV el mismo 8 de junio con plazo de remediación federal al 11 de junio, y la columna "Known To Be Used in Ransomware Campaigns" dice Known — no es una posibilidad, ya se observó.
Lo más incómodo es la ventana de exposición. Check Point arrancó la investigación el 4 de junio al ver tráfico sospechoso, pero los logs forenses retroceden al 7 de mayo de 2026: el actor tuvo un mes entero operando en silencio antes de que el vendor se enterara. Los blancos confirmados son unas pocas decenas de organizaciones globales, y al menos una tiene post-compromiso con un afiliado de Qilin ransomware. Check Point vincula la misma infraestructura (VPS en Kaupo Cloud HK, Shock Hosting y Vultr, con geolocalización elegida para mimetizarse con la víctima) a campañas paralelas contra GlobalProtect de Palo Alto, Fortinet y F5. No es un actor que se especialice en Check Point; es un afiliado que barre VPNs de todos los vendors grandes en simultáneo.
Una VPN sin password no es un fallo de autenticación: es una puerta sin cerradura. Y el barrio ya sabe que está abierta.
¿Cómo proteger tu infraestructura?
1. Aplicá el hotfix de Check Point sobre cada gateway afectado
El advisory sk185033 lista las versiones con parche para cada tren (R81.10.X, R81.20, R82, R82.00.X, R82.10). Para los trenes en End of Support (R80.20.X, R80.40, R81, R81.10) la solución de fondo es migrar a una release soportada; no te quedes en software EoS en el perímetro mientras hay explotación activa. El hotfix es la única remediación durable.
2. Si no podés parchear ya, forzá IKEv2-only y machine cert obligatorio
La vulnerabilidad vive específicamente en la rama IKEv1. En Global Properties → Remote Access → VPN Authentication dejá únicamente IKEv2 y activá machine certificate authentication as mandatory. Eso cierra el camino de ataque incluso con el código vulnerable, porque la rama IKEv1 deja de ser alcanzable. Conviene aplicar las dos cosas como defense-in-depth, no una sola.
3. Auditar logs hacia atrás hasta el 7 de mayo de 2026
Check Point recomienda explícitamente empezar la búsqueda forense el 7 de mayo, no el 4 de junio. En SmartLog o Log Exporter buscá: Phase 1 de IKEv1 que completa sin un XAUTH posterior, o un XAUTH que termina demasiado rápido; túneles desde geografías que no concuerdan con tu base de usuarios; procesos rclone o curl lanzados desde el gateway; y tráfico UDP en puertos efímeros con el patrón de handshake de Tox (que el actor usa para C2).
4. Habilitá IPS con firmas actualizadas y revisá IoCs de Qilin
El blade IPS de Check Point ya tiene firmas para los patrones de explotación de CVE-2026-50751. Asegurate de tenerlas al día. Adicionalmente, cruzá las IPs y hashes del advisory contra tus logs de firewall y VPN: el actor volvió a usar la misma infraestructura en junio 8, 9, 10 y 11 (la lista se actualizó tres veces en cinco días), lo que sugiere que no rota rápido. Un solo match positivo es razón suficiente para abrir un incidente.
Indicadores de compromiso (IoC)
Los IoCs que publica Check Point en su advisory y que Rapid7 replicó sirven para dos cosas: confirmar intrusión si los encontrás en tus logs, y bloquear preventivamente en el perímetro. Los IPs cubren VPS en Kaupo Cloud HK, Shock Hosting y Vultr Holdings; los hashes MD5 corresponden a binarios ELF (Linux) observados en la fase de post-explotación apuntando al propio gateway. Revisá también tráfico hacia tu Check Point desde cualquiera de estos rangos, y auditá tu postura en GlobalProtect / FortiGate / BIG-IP: el mismo actor está barriendo esos vendors en paralelo.
- IPs maliciosas (jun 8):
45.77.149[.]152,209.182.225[.]136,38.60.157[.]139,162.33.177[.]101,45.76.26[.]42,144.208.127[.]155,38.54.88[.]201,38.54.107[.]167,66.42.99[.]200 - IPs maliciosas (jun 9-11):
45.63.104[.]106,45.61.136[.]173,146.71.81[.]184,208.123.119[.]167,64.176.228[.]109,158.247.195[.]147,144.208.127[.]134 - Hashes MD5 (ELF Qilin):
52fda5c1b9704544f32ee98d9060e689,51d39aa39478beeac94f2d12f682ecce - Proveedores de infra del actor: Kaupo Cloud HK, Shock Hosting, Vultr Holdings
- Patrón C2: tráfico UDP en puertos efímeros con handshake característico del protocolo Tox
# Splunk SPL: sesiones IKEv1 sospechosas en Check Point
index=checkpoint sourcetype=cp_log action="IKE Phase 1 completed"
earliest="05/07/2026:00:00:00"
| join type=left src_ip
[ search index=checkpoint sourcetype=cp_log action="XAUTH completed"
earliest="05/07/2026:00:00:00" ]
| where isnull(xauth_time) OR (xauth_time - phase1_time) < 2
| stats count by src_ip, dst_ip, user, phase1_time
| where count > 0🛡 ¿Tu VPN empresarial sigue aceptando IKEv1?
Si administrás gateways de Check Point, Palo Alto, Fortinet o F5 expuestos a Internet, este es el momento de validar versiones, configuración de IKEv1/v2 y logs forenses. En IPSecureNetwork hacemos auditorías de superficie expuesta y threat hunting sobre appliances de perímetro — incluida la revisión de túneles VPN legacy que quedan olvidados. No esperes a que el Qilin afine el siguiente target.
SOLICITAR AUDITORÍA →