Una campaña de firewalls expuso 70.000 credenciales. Las sesiones VPN son el riesgo mayor.
Group-IB y NyxLab vinculan la campaña k0t contra FortiGate y GlobalProtect con 70.000 credenciales expuestas y con sesiones VPN que los parches no cierran.

En esta página
Puntos clave
- Group-IB y NyxLab publicaron el 21 de octubre de 2026 una investigación conjunta sobre la campaña k0t contra dispositivos Fortinet FortiGate y FortiWeb y puertas de enlace GlobalProtect de Palo Alto Networks.
- Los investigadores identificaron más de 70.000 credenciales expuestas y datos relacionados, incluidos volcados de LDAP, con un solapamiento mínimo respecto al conjunto de credenciales de FortiBleed.
- El actor, seguido como k0t con los alias CryptoFeel, Member19 y QazWsxShop, se detectó por primera vez en circulación el 22 de octubre de 2025.
- Muchos compromisos de FortiGate datan de febrero a junio de 2026; el 37,6 % de los dominios únicos del conjunto estaba en Asia-Pacífico, el 31,9 % en América Latina, el 15,8 % en Europa y el 12,7 % en Oriente Medio y el norte de África.
- Group-IB encontró 28 grupos de dispositivos MeshCentral activos con 84 dispositivos comprometidos, además de artefactos de otros 100 grupos que ya habían sido eliminados.
Group-IB y NyxLab publicaron el 21 de octubre de 2026 una investigación conjunta sobre una campaña que cosechó credenciales de firewalls y portales VPN expuestos a internet, sobre todo de la línea FortiGate y FortiWeb de Fortinet y de las puertas de enlace GlobalProtect de Palo Alto Networks. The Hacker News informó de los hallazgos el 23 de octubre. Los investigadores atribuyen la actividad a un alias criminal, k0t, que también aparece como CryptoFeel, Member19 y QazWsxShop, y contabilizan más de 70.000 credenciales expuestas y datos relacionados, incluidos volcados de LDAP.
Lectura relacionada: Leakers$ secuestró pantallas LED públicas en Egipto, Malasia y Brasil · La filial de internet de Sony en Japón dice que una brecha expuso 2,6 millones de registros.
La cifra se lee mal con facilidad. Setenta mil es un recuento de entradas de credenciales, no de organizaciones comprometidas, y Group-IB no ofrece ninguna cifra de víctimas para la campaña. Para los defensores importa la secuencia que hay detrás: un dispositivo que se puede encontrar desde un buscador, un archivo de configuración que se descifra con una clave que todo el mundo conoce y una sesión VPN que puede durar más que la credencial que la abrió.
Qué cuentan realmente los 70.000
El conjunto de datos que describe el informe de Group-IB y NyxLab es material operativo: credenciales de dispositivos de red y volcados de directorio del tipo que guarda un dispositivo cuando autentica al personal contra LDAP o Active Directory. Group-IB afirma que el conjunto apenas se solapaba con los datos de credenciales de FortiBleed divulgados a principios de 2026, lo que importa porque un defensor que limpió tras FortiBleed podría suponer que esta lista es la misma.
No es una lista de víctimas. Group-IB señala que los identificadores de víctimas van desde dominios públicos y direcciones de correo hasta direcciones IP internas, y que la atribución exacta no se puede verificar para todo el conjunto. Los dominios únicos hallados en el material dan un límite inferior de organizaciones afectadas. El reparto regional de esos dominios es del 37,6 % en Asia-Pacífico, del 31,9 % en América Latina, del 15,8 % en Europa y del 12,7 % en Oriente Medio y el norte de África. Los investigadores son explícitos en que esto refleja dónde se encontraron los dispositivos expuestos durante el escaneo, no un plan de atacar esas regiones.
Muchos de los casos de compromiso de FortiGate llevan fechas entre febrero y junio de 2026, la misma ventana que FortiBleed. Group-IB evalúa con confianza moderada que la actividad pertenece al clúster más amplio relacionado con FortiBleed, a la vez que dice que la evidencia no demuestra que los mismos operadores gestionaran ambos conjuntos. Las dos cifras que circulan sobre estas campañas también miden cosas distintas. Cryptopolitan resumió el recuento de FortiBleed como 86.644 dispositivos comprometidos, citando a SOCRadar. Sumar las credenciales de una campaña a los dispositivos de otra produce un número mayor y ninguna imagen útil.
Un recuento de credenciales no es un recuento de víctimas
Setenta mil entradas pueden describir una organización con un directorio grande o miles de organizaciones pequeñas. Group-IB no dice cuántas organizaciones fueron comprometidas, cuántos datos salieron ni cuántas de las credenciales siguen funcionando. Quien cita la cifra como número de empresas añade una afirmación que el informe no hace.
Un escáner, no un equipo de investigación
El reconocimiento explica la dispersión. k0t no parecía elegir víctimas por sector ni por rumores. Según el informe, el operador compró o pidió prestado acceso a motores de búsqueda de superficie de ataque, preguntó en un foro público por una cuenta premium de FOFA o por alguien que pudiera exportar listas de IP de FOFA, ZoomEye y Censys, y más tarde dijo haber encontrado socios para FOFA y ZoomEye. Se pedían resultados masivos en formato ip:port para que las herramientas automatizadas pudieran procesarlos.
Las búsquedas se concentraron en portales GlobalProtect, filtrados por características de la página de inicio de sesión, cabeceras de respuesta y certificados, primero en Norteamérica y después en Europa y Asia-Pacífico. Los sistemas FortiGate y FortiWeb también estaban en la cola, y las consolas SonicWall SMA1000, OPNsense y Cisco ISE aparecen en la monitorización del operador. El informe dice que no hay pruebas de un compromiso exitoso de un SMA1000.
«k0t parece seleccionar objetivos potenciales enumerando dispositivos de red expuestos a escala en lugar de investigar organizaciones concretas.» — Investigadores de Group-IB y NyxLab, 21 de octubre de 2026
Esa distinción importa porque fue la exposición, y no el sector, lo que decidió quién aparecía en el conjunto. Las herramientas encajan con ese enfoque: un escáner de FortiGate que ingiere un archivo de texto de direcciones, etiqueta cada una con un país desde una base de datos GeoIP incluida y ejecuta un grupo de hilos de trabajo sobre la lista. El informe menciona una lista de exclusión codificada para la región de la CEI y otras jurisdicciones que se puede desactivar con un indicador, y que algunas víctimas procedían de los países excluidos, lo que sugiere que el indicador se usó. Cybersecurity News también recorrió los dos scripts personalizados detrás de la operación.
La clave por defecto que hace confesar a un firewall
Una vez dentro de un FortiGate, la herramienta puede descargar la configuración del dispositivo y descifrarla localmente. La clave es la clave AES por defecto de FortiOS, una debilidad registrada como CVE-2019-6693. La solución de Fortinet fue añadir una opción de cifrado de datos privados. Si nadie la activó, el equipo sigue usando la clave conocida, y una copia de seguridad de la configuración se convierte en un archivo legible.
Una configuración de firewall contiene más que reglas. Contiene las credenciales que el dispositivo usa para enlazarse con LDAP o Active Directory, además de cuentas de administrador y de usuario local, porque el equipo necesita esos secretos para hacer su trabajo. Un atacante que puede descifrar el archivo hereda las relaciones que autorizan esos secretos. En ese punto no hace falta ningún exploit, solo una descarga y una rutina de descifrado.
Es el paso menos espectacular de la cadena y probablemente el más trascendente. Un dispositivo sin parchear es una exposición temporal que una ventana de mantenimiento puede cerrar. Una credencial de directorio copiada de un archivo de configuración sigue siendo válida hasta que alguien la cambie, y el dispositivo no da ninguna señal de que fue leída. Por eso mismo la guía defensiva de Group-IB trata un dispositivo de borde comprometido como un posible compromiso de credenciales de toda la empresa.
Dos formas de saltarse el inicio de sesión
Los métodos de acceso inicial varían según el producto.
En FortiWeb, la herramienta explota CVE-2025-64446, un recorrido de ruta relativo que puede permitir a un atacante no autenticado ejecutar comandos administrativos mediante peticiones HTTP o HTTPS manipuladas. La petición suplanta la cuenta integrada prof_admin con una cabecera falsificada y luego crea un nuevo administrador local con un nombre de usuario aleatorio de ocho caracteres y esa misma cadena como contraseña. La cuenta nueva recibe el perfil prof_admin y un rango de hosts de confianza 0.0.0.0/0, lo que significa que puede iniciar sesión desde cualquier lugar.
En FortiGate, donde esa vía no se aplica, el recurso es la fuerza bruta contra la API REST, con nombres de usuario como admin, fortinet y sysadmin y contraseñas como admin y fortigate. Cuando el equipo devuelve un código de bloqueo, la herramienta aparca el host 60 segundos y reintenta, lo que coincide con el temporizador de bloqueo predeterminado del administrador de FortiGate. El informe lee ese detalle como señal de que el autor de la herramienta conocía el producto.
La ruta de Palo Alto usa CVE-2026-0257, una omisión de autenticación en portales y puertas de enlace GlobalProtect de PAN-OS y Prisma Access, pero solo donde están activadas las cookies de anulación de autenticación y la configuración de certificados correspondiente. El exploit falsifica una cookie cifrando una cadena de sesión con una clave pública tomada del propio certificado TLS del objetivo y la envía con contraseña vacía al punto de conexión de inicio de sesión de GlobalProtect. Un dispositivo vulnerable la descifra, comprueba el formato de la sesión y no comprueba si la cookie fue alguna vez legítima. Desde ahí la herramienta abre una conexión VPN con OpenConnect. The Hacker News ya había informado de que operadores de Qilin e INC intentaban explotar la misma falla.
Ese último paso es la razón por la que «parchea el firewall» es una instrucción incompleta. La sesión ya está autenticada. No necesita la contraseña otra vez.
En qué se convierte el acceso
El manual de postexplotación es conocido, y en parte por eso funciona. OpenConnect proporciona el punto de apoyo. El descubrimiento abarca Active Directory, recursos compartidos SMB y antivirus instalados. La persistencia llega del software de gestión remota: agentes de MeshCentral, Atera, Teramind, AnyDesk, ngrok, además de AdaptixC2 como segundo canal de mando. La escalada de privilegios usa NetExec, Impacket, noPac, Kerbrute, PetitPotam y Mimikatz, y la exfiltración pasa por Rclone hacia cubos de Wasabi S3 y unidades de MEGA.
Las cifras de MeshCentral dan una idea de la escala. En el momento del análisis, Group-IB encontró 28 grupos de dispositivos activos con 84 dispositivos comprometidos, además de artefactos de otros 100 grupos que ya habían sido eliminados. El servidor no contenía archivos, lo que los investigadores leen como señal de acceso interactivo en vivo, con los datos preparados y movidos por separado.
Group-IB también evalúa que los operadores comparten conexiones con los grupos de ransomware Qilin y The Gentlemen, y que probablemente actúan como bróker de acceso inicial o afiliado. La base es el solapamiento de víctimas: muchas organizaciones de esta campaña aparecieron después en los sitios de filtraciones de esos grupos. El informe califica la relación de no confirmada, y la advertencia merece repetirse. El solapamiento de víctimas es prueba de que el acceso se movió, no de quién se lo vendió a quién.
Parchear cierra la puerta, no la sesión
Ambos CVE tienen correcciones del fabricante, y la campaña explota fallos conocidos y configuraciones débiles. Ni Fortinet ni Palo Alto Networks aparecen citados en el informe con una declaración nueva, así que no hay una evaluación reciente de los fabricantes sobre cuántos dispositivos siguen expuestos.
TechPastWeek ha cubierto este mes dos episodios comparables de dispositivos de borde: los zero-days de Citrix NetScaler y el fallo de escritura de archivos de FortiMail. Ambos terminaron con la misma instrucción de parchear, y ambos dejaron la misma pregunta sobre lo que el atacante ya se había llevado. En el lado de FortiBleed, las advertencias del Gobierno de EE. UU. a principios de octubre decían que la actividad seguía en marcha, un mal momento para tratar cualquier parche individual como cierre.
La lista de remediación que se desprende del informe es más larga que una cola de parches:
- Localice cada FortiGate, FortiWeb y portal GlobalProtect expuesto a internet. El propio consejo del informe parte de la exposición, no del sector.
- Compruebe el nivel de parche y la configuración. En GlobalProtect, los ajustes de anulación de autenticación y de certificados deciden si CVE-2026-0257 se aplica. En FortiOS, el cifrado de datos privados decide si una configuración robada es legible.
- Dé por comprometidos los secretos almacenados si se accedió a un dispositivo. Rote las credenciales de enlace al directorio y los administradores locales, y revoque las sesiones VPN en lugar de esperar a que caduquen.
- Busque cuentas que nadie creó: nuevos administradores locales, rangos de hosts de confianza modificados, exportaciones de configuración, patrones de bloqueo y reintento e inicios de sesión desde direcciones inusuales.
- Busque instalaciones de MeshAgent, Atera, Teramind, AnyDesk, ngrok y AdaptixC2, y Rclone escribiendo en almacenamiento en la nube.
El orden importa. Parchear primero sin rotar credenciales deja abierta la vía más fácil para el intruso, y una sesión abierta con una cookie falsificada no le importa que el fallo esté corregido.
Lo que sigue siendo desconocido es mucho. Group-IB ha prometido un informe técnico adicional. No hay cifra de víctimas, ni víctimas identificadas, ni atribución estatal en el material público, y la cifra de 70.000 se seguirá citando como si aportara las tres cosas. La pregunta más útil para un defensor es más modesta y tiene respuesta: cuáles de mis dispositivos se pueden encontrar desde un buscador y qué aprendería un atacante de su archivo de configuración.
Portada: «Fortinet FortiGate 6501F.png» de Premeditated, CC BY-SA 4.0, vía Wikimedia Commons. La imagen muestra un chasis FortiGate 6501F, una de las líneas de producto atacadas en la campaña.
Etiquetas
Preguntas frecuentes
- ¿Qué es la campaña k0t?
- Es una campaña, documentada por Group-IB y NyxLab el 21 de octubre de 2026, que explotó y atacó por fuerza bruta dispositivos de borde de Fortinet y Palo Alto Networks expuestos a internet para robar credenciales y mantener el acceso remoto. Los investigadores la vinculan con más de 70.000 credenciales expuestas, incluidos volcados de LDAP, y con persistencia mediante VPN y gestión remota dentro de las redes de las víctimas.
- ¿Significa la cifra de 70.000 que 70.000 empresas fueron comprometidas?
- No. La cifra cuenta entradas de credenciales y registros de directorio relacionados que obran en poder de los operadores, no organizaciones. Group-IB no publica un recuento de víctimas y dice que los dominios únicos del conjunto solo dan un límite inferior de organizaciones afectadas.
- ¿Qué vulnerabilidades explotó la campaña?
- Group-IB observó la explotación de CVE-2025-64446, un recorrido de ruta en FortiWeb, y de CVE-2026-0257, una omisión de autenticación que afecta a portales y puertas de enlace GlobalProtect en configuraciones vulnerables de PAN-OS. Los dispositivos FortiGate no son vulnerables a ese exploit de FortiWeb y se atacaron con fuerza bruta contra la API REST.
- ¿Es la campaña k0t lo mismo que FortiBleed?
- No. Group-IB halló un solapamiento mínimo entre los dos conjuntos de credenciales, a la vez que evalúa con confianza moderada que k0t está asociado al clúster de actividad más amplio relacionado con FortiBleed. La evidencia no demuestra que los mismos operadores controlaran ambos conjuntos.








