Entradas de blog de ' 2026 ' ' noviembre '

La amenaza presente...

La principal amenaza es la vulnerabilidad CVE-2026-76418, un fallo en la función VPN SSL de acceso remoto de Cisco Secure Firewall ASA y FTD. Cuando se habilita la autenticación secundaria, como RADIUS, LDAP o Duo, en un grupo de túneles VPN, un atacante remoto puede enviar una solicitud de conexión especialmente diseñada a la página de inicio de sesión VPN pública sin un nombre de usuario o contraseña válidos.

El procesamiento de la solicitud provoca que el Firewall se recargue, interrumpiendo el acceso VPN y otro tráfico que depende del dispositivo. Los atacantes pueden repetir el proceso para crear una condición de denegación de servicio (DoS) continua.

Los dispositivos son vulnerables si ejecutan una versión afectada de ASA o FTD, exponen el servicio VPN de acceso remoto SSL y tienen configurada la autenticación secundaria en cualquier grupo de túneles, incluido el predeterminado DefaultWEBVPNGroup. No se requiere un inicio de sesión VPN exitoso. Cisco ha confirmado la explotación activa, lo que significa que los firewalls con acceso a internet ya están siendo atacados.

¿Por qué es digno de mención?

Esta vulnerabilidad afecta directamente a los firewalls perimetrales y a las pasarelas VPN, elementos cruciales para el acceso remoto y la disponibilidad de la red. Dado que la explotación no requiere autenticación, cualquiera que logre acceder a una página de inicio de sesión VPN SSL vulnerable podría provocar fallos repetidos en el dispositivo.

Dado que ya se han detectado casos de explotación en entornos reales, esto representa una amenaza real para las organizaciones que no han implementado parches de seguridad. Además, junto con otras actividades de elusión de la autenticación SD-WAN, pone de manifiesto el creciente interés de los atacantes en la infraestructura de seguridad y redes de Cisco.

¿Cuál es la exposición o el riesgo?

Las organizaciones quedan expuestas si utilizan versiones vulnerables de ASA o FTD, permiten el acceso remoto a servicios VPN mediante SSL desde redes no confiables y emplean autenticación secundaria en un grupo de túneles. Un atacante podría forzar de forma remota la recarga del firewall, interrumpiendo el acceso VPN y, potencialmente, otro tráfico gestionado por el dispositivo.

Para las organizaciones que dependen de un único firewall o de configuraciones de alta disponibilidad (HA) deficientes, la explotación de vulnerabilidades podría provocar una pérdida generalizada de conectividad para trabajadores remotos, sucursales y aplicaciones con acceso a internet. Incluso con alta disponibilidad implementada, las fallas repetidas podrían desencadenar conmutaciones por error, inestabilidad y un rendimiento degradado.

Los atacantes también podrían usar el ataque de denegación de servicio (DoS) como parte de una campaña más amplia para distraer a los defensores o interrumpir la monitorización mientras atacan otros sistemas. Las organizaciones con numerosos dispositivos expuestos, incluidos los proveedores de servicios gestionados (MSP) y los entornos multiusuario que dan soporte a múltiples clientes, pueden enfrentarse a un mayor riesgo operativo.

En combinación con la explotación de la vulnerabilidad de omisión de autenticación de Cisco SD-WAN, esta actividad pone de relieve el riesgo más amplio de que la infraestructura de enrutamiento, VPN y plano de control se convierta en objetivo de actores maliciosos sofisticados.

¿Cuáles son las recomendaciones?

Las recomendaciones siguientes buscan reducir el riesgo de explotación y proteger la infraestructura crítica:

• Actualizar los dispositivos ASA y FTD a versiones corregidas: Actualice los dispositivos Cisco Secure Firewall ASA y FTD a las versiones corregidas recomendadas por Cisco. Priorice las puertas de enlace VPN y los firewalls que manejan tráfico de producción y programe las actualizaciones lo antes posible.
• Verifique las configuraciones de VPN SSL y autenticación secundaria: Identifique dónde está habilitada la VPN de acceso remoto SSL y qué grupos de túneles la utilizan secondary-authentication-server-group. Verifique DefaultWEBVPNGrouptambién, incluso si las listas de grupos de túneles están deshabilitadas. Elimine la autenticación secundaria donde no sea necesaria.
• Aplique medidas provisionales si no es posible aplicar parches de inmediato: Si DefaultWEBVPNGroupno utiliza autenticación secundaria, desactive la lista de grupos de túneles. De lo contrario, elimine la autenticación secundaria de los grupos que no la requieran. Siempre que sea posible, restrinja el acceso al inicio de sesión de la VPN SSL a las redes de origen previstas. Considere estas medidas como temporales hasta que se pueda actualizar el software.
• Refuerce la protección de VPN y SD-WAN: Limite la exposición de las interfaces de administración y VPN a lo estrictamente necesario. Restrinja el acceso administrativo, utilice políticas sólidas de autenticación multifactor (MFA) y acceso condicional, y aplique el parche CVE-2026-20127 en los controladores Cisco SD-WAN Catalyst cuando corresponda.
• Supervise los fallos y la actividad anómala de la VPN: Reciba alertas sobre reinicios inesperados del dispositivo, intentos repetidos de inicio de sesión en la VPN desde direcciones IP inusuales y caídas repentinas de la conectividad. Correlacione los eventos de reinicio con picos en el tráfico SSL de la VPN para identificar posibles intentos de explotación.
• Revise el diseño de alta disponibilidad y conmutación por error: confirme que los pares de alta disponibilidad estén configurados correctamente y pruebe el comportamiento de la conmutación por error bajo carga. Aplique parches a ambos dispositivos de alta disponibilidad, ya que un código vulnerable en ambos podría permitir a un atacante interrumpir el funcionamiento de las unidades activa y de reserva.
• Refuerce la gestión de vulnerabilidades y parches: priorice los avisos de seguridad que afecten a firewalls, SD-WAN, VPN e infraestructura de identidad. Incorpore los avisos de Cisco en los procesos de gestión de vulnerabilidades y establezca responsabilidades claras para la revisión y aplicación de actualizaciones críticas.

Un inicio de sesión legítimo: una intención maliciosa

La autenticación mediante código de dispositivo tiene una finalidad completamente legítima. Se utiliza cuando una aplicación necesita que el usuario complete el inicio de sesión desde otro equipo, por ejemplo, cuando un dispositivo muestra un código que debe introducirse en el navegador de una computadora o un teléfono.

El problema aparece cuando un atacante manipula este procedimiento.

El proceso suele comenzar con un correo electrónico que parece habitual: una invitación para consultar un documento compartido, revisar una factura, escuchar un mensaje de voz o responder a una solicitud de propuesta.

El empleado sigue las instrucciones y recibe un código de verificación. Después, es dirigido a una página auténtica de inicio de sesión, donde introduce el código y completa la autenticación multifactor.

Todo parece correcto. Sin embargo, hay un detalle que cambia por completo la situación: la solicitud de autenticación no fue iniciada por el empleado, sino por el atacante.

Al introducir el código y aprobar el proceso, el usuario termina autorizando la sesión del ciberdelincuente.

De esta manera, el atacante puede obtener tokens de acceso y actualización que le permiten utilizar los servicios disponibles para la cuenta comprometida, como el correo electrónico, el almacenamiento en la nube y otras aplicaciones empresariales, mientras los tokens continúen siendo válidos.

¿Por qué la autenticación multifactor no siempre es suficiente?

La autenticación multifactor (MFA) representa una capa importante de protección, pero este ataque demuestra que no todos los procesos de autenticación son igualmente resistentes al phishing.

En un ataque tradicional, el usuario suele ser redirigido a una página falsa que intenta imitar un servicio legítimo. La dirección web, el diseño o ciertos detalles del sitio pueden revelar el engaño.

El phishing mediante código de dispositivo elimina buena parte de esas señales de alerta.

La víctima puede:

• Acceder a un dominio legítimo.
• Introducir el código de verificación siguiendo las instrucciones.
• Completar correctamente la autenticación multifactor.
• No proporcionar su contraseña a una página controlada por el atacante.
• Recibir una aprobación normal del sistema de autenticación.

El engaño no está necesariamente en la página que el usuario visita, sino en la solicitud que está autorizando.

Por eso, revisar la URL y completar la MFA no garantizan, por sí solos, que el inicio de sesión sea legítimo. También es necesario comprobar qué aplicación o dispositivo solicita la autorización y por qué se está realizando ese proceso.

De una técnica específica a campañas cada vez más sofisticadas

El phishing mediante código de dispositivo dejó de ser únicamente una técnica experimental.

En febrero de 2025, Microsoft reveló una campaña que utilizaba este mecanismo para capturar tokens de autenticación y obtener acceso a cuentas comprometidas.

A principios de 2026, los atacantes comenzaron a combinar esta técnica con automatización, señuelos generados mediante inteligencia artificial y códigos de dispositivo generados dinámicamente.

Este último elemento representa un avance importante.

Los códigos de dispositivo tienen un periodo de validez limitado. Anteriormente, esto obligaba a los atacantes a convencer a sus víctimas de actuar dentro de una ventana de tiempo relativamente corta.

Con la generación dinámica de códigos, los ciberdelincuentes pueden crear uno nuevo cuando la víctima llega a la etapa final del engaño. Así reducen los obstáculos operativos y facilitan la ejecución de campañas a mayor escala.

La automatización también permite coordinar mejor los diferentes pasos del ataque, desde el primer mensaje hasta la obtención de acceso.

El correo electrónico es el punto de partida, pero no el final del ataque

Para que esta técnica funcione, el atacante necesita una razón convincente para que el empleado complete el proceso de autenticación.

Ahí es donde entra el correo electrónico.

Un mensaje sobre un archivo compartido, una factura pendiente, una solicitud de propuesta o un mensaje de voz puede generar suficiente confianza para que el usuario siga las instrucciones sin cuestionar su origen.

Algunas campañas utilizan enlaces directos. Otras recurren a archivos PDF o HTML y a múltiples redirecciones mediante servicios en la nube legítimos o de buena reputación.

Esto dificulta la detección, porque analizar únicamente el dominio de destino puede dejar fuera información importante sobre el recorrido que llevó al usuario hasta la página de inicio de sesión.

Pero el riesgo no termina cuando el atacante consigue autenticarse.

Una cuenta comprometida puede convertirse en un punto de entrada para explorar aplicaciones conectadas, consultar información confidencial, suplantar la identidad del empleado o intentar avanzar hacia otros recursos de la organización.

Por eso, los equipos de seguridad necesitan observar lo que ocurre antes, durante y después de la autenticación.

Entre las señales que conviene investigar se encuentran:

• ¿Quién envió el mensaje original y qué contexto utilizó para generar confianza?
• ¿Qué enlaces, archivos adjuntos y redirecciones llevaron al empleado hasta la página de inicio de sesión?
• ¿Qué aplicación o dispositivo se estaba solicitando autorizar?
• ¿La actividad posterior corresponde al comportamiento habitual del usuario?
• ¿A qué aplicaciones, recursos o información accedió la cuenta?
• ¿Aparecieron nuevas reglas en el correo, permisos de aplicaciones o registros de dispositivos inesperados?

Conectar las señales del correo electrónico, la identidad, las aplicaciones en la nube y los dispositivos permite comprender mejor el alcance de una posible vulneración y responder antes de que una cuenta comprometida se convierta en un incidente de mayor impacto.

¿Cómo puede una organización reducir este riesgo?

La protección frente al phishing mediante código de dispositivo requiere una estrategia que vaya más allá del filtrado de correos o de la implementación de MFA.

Las organizaciones deben considerar medidas específicas en sus sistemas de identidad, políticas de acceso y herramientas de detección.

• Bloquear la autenticación mediante código de dispositivo cuando no sea necesaria.

Si la organización no tiene una necesidad empresarial legítima para utilizar este mecanismo, deshabilitarlo ayuda a reducir la superficie de ataque.

• Restringir su utilización cuando sea indispensable.

Las políticas de acceso condicional permiten establecer controles sobre cuándo y bajo qué circunstancias puede utilizarse este flujo de autenticación.

• Implementar autenticación resistente al phishing.

Las claves de seguridad y las credenciales FIDO2 ofrecen una protección más sólida frente a técnicas de phishing y robo de credenciales.

• Capacitar a los empleados para verificar lo que autorizan.

No basta con revisar la dirección del sitio web. Los usuarios deben aprender a identificar qué aplicación y dispositivo están solicitando la autorización, y cuestionar cualquier proceso que no hayan iniciado.

• Supervisar los eventos de autenticación y la actividad posterior.

Es importante detectar inicios de sesión inusuales mediante códigos de dispositivo, actividad sospechosa de tokens, registros inesperados de dispositivos, accesos anómalos a Microsoft Graph y nuevas reglas de bandeja de entrada.

• Actuar rápidamente ante una posible intrusión.

Cuando se identifica actividad maliciosa, los equipos de seguridad deben revocar los tokens de actualización y aplicar las medidas de contención correspondientes para impedir que el atacante conserve el acceso.

• Analizar el recorrido completo del correo electrónico.

Evaluar al remitente, el contexto del mensaje, los archivos adjuntos, las redirecciones y la solicitud de autenticación permite identificar señales que podrían pasar desapercibidas al revisar únicamente la página de destino.

Una página legítima no garantiza un acceso seguro