PEAP-MSCHAPv2: Por qué sigue siendo común, por qué es riesgoso y cómo avanzar

Una guía de referencia técnica exhaustiva que detalla las vulnerabilidades críticas de seguridad de PEAP-MSCHAPv2, incluidos los ataques de evil twin y la captura de credenciales. Proporciona una hoja de ruta práctica y neutral respecto al proveedor para que los equipos de TI migren las redes WiFi empresariales a una autenticación segura basada en certificados EAP-TLS.

📖 5 min de lectura📝 1,170 palabras🔧 2 ejemplos prácticos❓ 3 preguntas de práctica📚 8 definiciones clave

Escuchar esta guía

Ver transcripción del podcast

Hola y bienvenidos a esta sesión informativa técnica de Purple. Soy su anfitrión, y hoy abordamos un tema que se sitúa en la intersección de la arquitectura de red, el cumplimiento de la seguridad y, francamente, la deuda técnica heredada. Estamos hablando de PEAP-MSCHAPv2.

Específicamente, analizaremos por qué sigue siendo el método de autenticación más común en el WiFi empresarial, por qué es fundamentalmente riesgoso en el panorama de amenazas actual y, lo más importante, cómo puede trasladar de manera práctica a su organización hacia algo mejor.

Comencemos con el contexto. Si es director de TI o arquitecto de redes en un hotel, una cadena de tiendas o un gran recinto público, es muy probable que la red WiFi de su personal (y quizás sus dispositivos corporativos) se estén autenticando mediante PEAP-MSCHAPv2. Ha sido el estándar por defecto para las redes WPA2-Enterprise durante casi dos décadas. ¿Por qué? Porque es increíblemente fácil de desplegar. Se conecta directamente a Active Directory a través de un servidor RADIUS y los usuarios solo tienen que introducir su nombre de usuario y contraseña habituales de Windows. Sin certificados que gestionar, sin una compleja infraestructura de clave pública que construir. Simplemente funciona.

Pero que "simplemente funcione" ya no es suficiente. La arquitectura de seguridad que sustenta a PEAP-MSCHAPv2 está, por decirlo sin rodeos, rota.

Sumerjámonos en la realidad técnica. MSCHAPv2 se basa en el algoritmo de hashing MD4 y el cifrado DES. Ambos estándares criptográficos se diseñaron en la década de 1990 y se consideran débiles desde hace más de diez años. Ya en 2012, en la conferencia de seguridad DEF CON, el investigador Moxie Marlinspike demostró que el intercambio de MSCHAPv2 podía descifrarse de forma determinista. Lanzó una herramienta que reducía el proceso de descifrado a un único descifrado de clave DES, lo que significa que un atacante con una potencia informática modesta (o acceso a un servicio de descifrado en la nube) podría recuperar la contraseña de Active Directory en texto plano de un usuario a partir de un intercambio capturado en cuestión de horas, si no de minutos.

Entonces, ¿cómo captura realmente un atacante ese intercambio en el mundo real? Esto nos lleva al ataque "Evil Twin".

Imagine una oficina corporativa o la zona interna de un hotel. Un atacante entra con un punto de acceso no autorizado, a menudo algo tan pequeño como un Wi-Fi Pineapple en su mochila. Configura este AP no autorizado para que transmita exactamente el mismo SSID que su red corporativa, por ejemplo, "Staff-WiFi". Aumenta la potencia de la señal para que los dispositivos cercanos lo prefieran de forma natural frente a sus puntos de acceso legítimos.

Cuando el portátil o el teléfono de un empleado intenta conectarse, el AP no autorizado actúa como autenticador y apunta a un servidor RADIUS falso controlado por el atacante. El dispositivo del empleado inicia el túnel PEAP. Aquí está el punto crítico de fallo: PEAP depende de que el dispositivo cliente verifique el certificado digital del servidor para asegurarse de que está hablando con el servidor RADIUS corporativo real. Sin embargo, en la gran mayoría de los despliegues, los dispositivos clientes están mal configurados o a los usuarios simplemente se les muestra una ventana emergente que dice "¿Confía en este certificado?" y hacen clic en "Sí" solo para conectarse.

Una vez que se acepta ese certificado falso, el dispositivo envía el desafío-respuesta de MSCHAPv2 a través del túnel. El atacante lo captura, se marcha y descifra el hash sin conexión. Ahora tiene credenciales válidas de Active Directory, que puede utilizar para iniciar sesión en su VPN, su sistema de correo electrónico o cualquier otro servicio corporativo.

Este no es un riesgo teórico. Es un procedimiento operativo estándar tanto para los evaluadores de penetración como para los actores maliciosos. Y si está sujeto a marcos de cumplimiento como GDPR, confiar en un protocolo de autenticación comprometido es una responsabilidad significativa.

Entonces, si los riesgos son tan altos, ¿por qué no hemos avanzado todos?

La respuesta suele ser una mezcla de complejidad percibida y hardware heredado. Dejar atrás PEAP significa avanzar hacia la autenticación basada en certificados, específicamente EAP-TLS. EAP-TLS es el estándar de oro. Requiere que tanto el servidor como el dispositivo cliente presenten un certificado digital válido. No se transmiten contraseñas, ni en hash ni de ninguna otra forma. Es completamente inmune a los ataques de diccionario sin conexión y altamente resistente a los ataques de Evil Twin porque el cliente rechazará silenciosamente cualquier servidor RADIUS falso que no tenga un certificado firmado por su Autoridad de Certificación de confianza.

Pero desplegar EAP-TLS significa que necesita una infraestructura de clave pública, o PKI. Necesita una forma de generar certificados y distribuirlos de forma segura a cada portátil, teléfono y tableta de su flota. Hace cinco años, construir una infraestructura de Active Directory Certificate Services de Microsoft era un proyecto desalentador y costoso.

Hoy en día, sin embargo, el panorama ha cambiado. La ruta de implementación es mucho más clara.

Si está planeando una migración, este es el enfoque pragmático que recomendamos a nuestros clientes en Purple.

En primer lugar, no tiene que hacer un cambio drástico e inmediato. Los servidores RADIUS modernos (ya sea Cisco ISE, Aruba ClearPass o soluciones nativas de la nube) le permiten ejecutar PEAP-MSCHAPv2 y EAP-TLS simultáneamente en el mismo SSID.

El primer paso es desplegar su PKI. Ya no es necesario construir esto de forma local. Las soluciones de PKI en la nube se integran directamente con su proveedor de identidad (como Entra ID o Google Workspace) y sus plataformas de gestión de dispositivos móviles (MDM) como Intune o Jamf.

El segundo paso es utilizar su MDM para distribuir de forma silenciosa certificados de cliente a sus dispositivos gestionados. Puede configurar el perfil de WiFi a través de MDM para que prefiera EAP-TLS. Esto significa que sus portátiles corporativos cambiarán automáticamente al método seguro basado en certificados sin ninguna interacción del usuario.

El tercer paso es la fase de transición. Supervisa sus registros de RADIUS. Verá que sus dispositivos gestionados se autentican a través de EAP-TLS, mientras que los dispositivos no gestionados o heredados continúan utilizando PEAP.

Esto nos lleva al obstáculo común: los dispositivos heredados. ¿Qué hacer con los escáneres de códigos de barras de hace diez años en su almacén o los terminales de punto de venta más antiguos que simplemente no admiten EAP-TLS?

La solución es la segmentación. Nunca debe reducir la seguridad de su red principal de personal para adaptarse al mínimo común denominador. En su lugar, aísle esos dispositivos heredados en una VLAN dedicada. Puede utilizar la autenticación basada en MAC combinada con controles estrictos de acceso a la red, garantizando que esos dispositivos solo puedan hablar con los servidores internos específicos que necesitan, y absolutamente nada más.

Una vez que su flota gestionada se haya migrado por completo a EAP-TLS, finalmente podrá desactivar PEAP-MSCHAPv2 en su SSID corporativo principal, cerrando la ventana de vulnerabilidad para siempre.

Hagamos una ronda rápida de preguntas y respuestas basadas en las dudas más comunes que recibimos de los directores de TI.

Pregunta uno: "¿Resuelve WPA3 el problema de PEAP-MSCHAPv2?"
Respuesta: No. WPA3 mejora el cifrado inalámbrico, pero el método de autenticación EAP subyacente sigue siendo el mismo. Si utiliza WPA3-Enterprise con PEAP-MSCHAPv2, sigue siendo vulnerable a la captura de credenciales a través de un Evil Twin si el cliente no valida estrictamente el certificado del servidor.

Pregunta dos: "¿Qué pasa con EAP-TTLS?"
Respuesta: EAP-TTLS es mejor que PEAP porque canaliza la autenticación, a menudo utilizando PAP en lugar de MSCHAPv2, lo que evita las debilidades criptográficas específicas de MSCHAPv2. Sin embargo, sigue dependiendo de contraseñas y sigue siendo vulnerable si no se valida el certificado del servidor. Es un paso intermedio, pero el objetivo final debe ser EAP-TLS.

Pregunta tres: "¿Cómo afecta esto a nuestro WiFi de invitados de Purple?"
Respuesta: No afecta directamente. El WiFi de invitados suele utilizar redes abiertas con Captive Portals o WPA2/3-Personal, que son independientes de su autenticación empresarial 802.1X. Sin embargo, proteger la red interna de su personal es fundamental para proteger la infraestructura que sustenta todas las operaciones de su recinto, incluidos los servicios para invitados y las plataformas de análisis.

En resumen: PEAP-MSCHAPv2 nos ha servido bien, pero su tiempo ha pasado. Los fallos criptográficos son públicos y las herramientas de ataque están automatizadas. La migración a EAP-TLS ya no es un proyecto experimental; es una actualización estándar y alcanzable, facilitada significativamente por los MDM modernos y las soluciones de PKI en la nube.

El riesgo de no hacer nada (que una contraseña de Active Directory comprometida provoque una brecha de red más amplia) supera con creces el esfuerzo operativo de la migración. Comience hoy mismo con una auditoría de sus registros de RADIUS, identifique sus dispositivos heredados y empiece a planificar su transición a la autenticación basada en certificados.

Gracias por escuchar esta sesión informativa técnica de Purple. Para obtener guías de despliegue más detalladas y diagramas de arquitectura, asegúrese de leer la guía de referencia técnica completa que acompaña a este podcast.

Conclusiones clave

✓PEAP-MSCHAPv2 se basa en una criptografía obsoleta (MD4 y DES) que puede descifrarse fácilmente sin conexión.
✓El protocolo es muy vulnerable a los ataques de 'Evil Twin' si los dispositivos terminales no validan estrictamente el certificado del servidor RADIUS.
✓Las actualizaciones modernas de Windows (Credential Guard) están interrumpiendo activamente la autenticación MSCHAPv2 para evitar el robo de hashes.
✓EAP-TLS es el sustituto definitivo, ya que ofrece autenticación mutua mediante certificados digitales e inmunidad al descifrado sin conexión.
✓La PKI en la nube y las plataformas MDM modernas han reducido drásticamente la complejidad y el coste de desplegar EAP-TLS.
✓Los dispositivos heredados incompatibles con EAP-TLS deben segmentarse en VLAN dedicadas y restringidas en lugar de degradar la seguridad de la red principal.

Resumen Ejecutivo

A pesar de las vulnerabilidades criptográficas ampliamente documentadas, PEAP-MSCHAPv2 sigue siendo el método EAP más implementado para la autenticación WiFi empresarial en los sectores de hostelería, retail y público. Su continua prevalencia se debe a la facilidad de implementación —específicamente su integración nativa con Active Directory— más que a su eficacia en materia de seguridad. Sin embargo, el perfil de riesgo ha cambiado drásticamente. Las herramientas de explotación automatizadas han democratizado el ataque de "gemelo malvado" (evil twin), lo que permite a los actores de amenazas capturar y descifrar hashes de desafío-respuesta de MSCHAPv2 con un esfuerzo mínimo, lo que conduce directamente al compromiso de las credenciales de Active Directory.

Para los directores de TI y arquitectos de red, el mandato es claro: PEAP-MSCHAPv2 ya no es adecuado para su propósito en ningún entorno sujeto a marcos de cumplimiento como PCI DSS o GDPR. Esta guía proporciona un análisis crítico de los vectores de ataque específicos que se dirigen a PEAP-MSCHAPv2 y describe una ruta de migración pragmática y gradual a EAP-TLS. Al aprovechar las soluciones modernas de gestión de dispositivos móviles (MDM) y de infraestructura de clave pública (PKI) en la nube, las organizaciones pueden realizar la transición a una autenticación sólida basada en certificados sin interrumpir las operaciones comerciales ni alienar los dispositivos heredados.

Análisis Técnico Profundo: La Anatomía de la Vulnerabilidad

Para comprender por qué se debe retirar PEAP-MSCHAPv2, es necesario examinar su arquitectura criptográfica subyacente. MSCHAPv2 (Microsoft Challenge Handshake Authentication Protocol versión 2) se diseñó a finales de la década de 1990 y se basa en el algoritmo de hash MD4 y en el Data Encryption Standard (DES) [1]. Ambos se consideran obsoletos según los estándares criptográficos modernos.

El Fallo Criptográfico

La debilidad fundamental radica en cómo maneja MSCHAPv2 el hash NT de la contraseña del usuario. El protocolo divide una clave de 21 bytes derivada del hash NT en tres claves DES de 7 bytes. Crucialmente, la tercera clave solo utiliza dos bytes significativos del hash, rellenando el resto con bytes nulos. Este fallo estructural reduce la complejidad criptográfica de forma exponencial.

En 2012, el investigador de seguridad Moxie Marlinspike demostró que el saludo (handshake) de MSCHAPv2 se podía descifrar de forma determinista reduciendo el problema al descifrado de una sola clave DES [2]. Utilizando servicios de descifrado basados en la nube o equipos de GPU modernos que ejecutan herramientas como hashcat, un atacante puede recuperar la contraseña de Active Directory en texto plano a partir de un saludo capturado en cuestión de horas, independientemente de la complejidad de la contraseña.

El Vector de Ataque del Gemelo Malvado (Evil Twin)

La debilidad criptográfica se explota en entornos reales mediante el ataque de "gemelo malvado". En un escenario típico en una oficina corporativa o en un espacio de Hospitality :

Despliegue de AP Falso: El atacante despliega un punto de acceso falso que emite el SSID corporativo objetivo (por ejemplo, "Staff-WiFi").
Dominancia de la Señal: El AP falso funciona a una potencia de transmisión más alta, lo que obliga a los dispositivos cliente cercanos a asociarse con él en lugar de con la infraestructura legítima.
Autenticación RADIUS Falsa: Cuando el cliente inicia el túnel PEAP, el AP falso actúa como proxy de la solicitud hacia un servidor RADIUS controlado por el atacante (como hostapd-wpe).
Fallo en la Validación del Certificado: El servidor RADIUS falso presenta un certificado digital autofirmado o no verificado. Si el dispositivo cliente está mal configurado para omitir la validación estricta del certificado del servidor —o si el usuario simplemente hace clic en "Aceptar" en un aviso de confianza—, el túnel se establece.
Captura de Credenciales: El cliente transmite el desafío-respuesta de MSCHAPv2 a través del túnel comprometido. El atacante captura el hash y finaliza la conexión.

Sin una validación estricta del certificado del servidor aplicada a nivel de endpoint, todos los dispositivos que utilizan PEAP-MSCHAPv2 son vulnerables a esta técnica de captura de credenciales. Esto es especialmente preocupante para los entornos de Retail , donde las redes internas a menudo comparten proximidad física con los espacios públicos.

Guía de Implementación: Migración a EAP-TLS

La mitigación definitiva para las vulnerabilidades de MSCHAPv2 es la migración a EAP-TLS (Extensible Authentication Protocol-Transport Layer Security). EAP-TLS exige autenticación mutua: tanto el servidor RADIUS como el dispositivo cliente deben presentar certificados digitales válidos. Dado que no se transmiten ni se aplican hashes a las contraseñas durante el saludo, EAP-TLS es completamente inmune a los ataques de diccionario sin conexión y altamente resistente a la suplantación de identidad por gemelo malvado.

Históricamente, la barrera para la adopción de EAP-TLS era la complejidad de implementar una infraestructura de clave pública (PKI) local. Hoy en día, las integraciones de PKI en la nube y los MDM modernos han simplificado el proceso.

Fase 1: Auditoría e Inventario

Antes de modificar las políticas de autenticación, realice una auditoría exhaustiva de sus registros RADIUS actuales (por ejemplo, Cisco ISE, Aruba ClearPass o Windows NPS). Identifique todos los dispositivos que se autentican actualmente a través de PEAP. Categorice estos dispositivos en dos grupos:

Dispositivos Gestionados: Portátiles, tabletas y smartphones corporativos registrados en una plataforma MDM (por ejemplo, Intune, Jamf).
Dispositivos No Gestionados/Heredados: Sensores IoT, terminales de punto de venta más antiguos, lectores de códigos de barras o dispositivos BYOD que no admiten el registro de certificados.

Fase 2: Despliegue de PKI y Configuración de RADIUS

Despliegue una solución PKI para emitir certificados de cliente y servidor. Las plataformas PKI nativas de la nube pueden integrarse directamente con Entra ID o Google Workspace, eliminando la necesidad de una infraestructura local pesadae Microsoft AD CS footprint. Configure su servidor RADIUS para aceptar la autenticación EAP-TLS. Es fundamental que configure la política de red para admitir simultáneamente PEAP y EAP-TLS en el mismo SSID durante el período de transición.

Fase 3: Distribución de certificados a través de MDM

Aproveche su plataforma MDM para distribuir de forma silenciosa los certificados de cliente a los dispositivos gestionados utilizando protocolos como SCEP (Simple Certificate Enrollment Protocol). Al mismo tiempo, envíe una carga útil de perfil de WiFi actualizada a través de MDM que indique a los dispositivos que prioricen EAP-TLS para el SSID corporativo. Esto garantiza una transición sin intervención para los usuarios finales.

Fase 4: Gestión de dispositivos heredados

Los dispositivos heredados que no admiten EAP-TLS nunca deben condicionar la postura de seguridad de la red corporativa principal. En su lugar, segmente estos dispositivos en una VLAN dedicada. Implemente la omisión de autenticación basada en MAC (MAB) combinada con listas de control de acceso (ACL) estrictas para garantizar que estos dispositivos solo puedan comunicarse con los servidores internos específicos necesarios para su función.

Buenas prácticas y cumplimiento

Mantener un entorno inalámbrico empresarial seguro requiere el cumplimiento continuo de los estándares del sector.

Forzar la validación del certificado del servidor: Si debe mantener temporalmente PEAP-MSCHAPv2, utilice MDM para forzar la vinculación estricta de certificados de servidor en todos los endpoints. Evite que los usuarios confíen manualmente en certificados desconocidos.
Desactivar WPA2-Personal: Asegúrese de que todo el acceso corporativo dependa de 802.1X (WPA2/WPA3-Enterprise). Las claves precompartidas (PSK) deben limitarse estrictamente a redes IoT aisladas.
Alineación con PCI DSS: Para los establecimientos que procesan pagos, el requisito 4 de PCI DSS exige una criptografía sólida para la transmisión de datos de titulares de tarjetas a través de redes inalámbricas. El PCI Security Standards Council recomienda explícitamente EAP-TLS para una autenticación sólida [3].
Supervisar analíticas: Utilice plataformas como WiFi Analytics de Purple para supervisar el estado de la red, identificar patrones de conexión anómalos y asegurarse de que los dispositivos heredados no intenten acceder a subredes restringidas.

ROI e impacto empresarial

El retorno de la inversión de la migración a EAP-TLS se mide principalmente en la mitigación de riesgos. Un ataque de gemelo malvado (evil twin) exitoso contra PEAP-MSCHAPv2 obtiene credenciales válidas de Active Directory, lo que proporciona a los actores de amenazas un acceso inicial a la red corporativa. El impacto financiero de una brecha de datos resultante, el despliegue de ransomware o una multa regulatoria (como las contempladas en el GDPR) supera con creces el coste operativo de desplegar una PKI en la nube y actualizar los perfiles de MDM.

Además, la autenticación basada en certificados reduce significativamente el volumen de incidencias en el servicio de soporte técnico relacionadas con la expiración y el bloqueo de contraseñas. Al migrar a EAP-TLS, los equipos de TI eliminan las fricciones del acceso a la WiFi basado en contraseñas, ofreciendo una experiencia de conectividad fluida y segura que respalda las arquitecturas modernas de red de confianza cero (zero-trust).

Referencias

[1] Microsoft Security Response Center. "Weaknesses in MS-CHAPv2 authentication." Agosto de 2012. [2] Marlinspike, Moxie. "Defeating PPTP VPNs and WPA2 Enterprise with MS-CHAPv2." DEF CON 20, 2012. [3] PCI Security Standards Council. "Information Supplement: PCI DSS Wireless Guidelines."

Definiciones clave

PEAP (Protected Extensible Authentication Protocol)

Un método EAP que encapsula el proceso de autenticación dentro de un túnel TLS seguro para proteger las credenciales de autenticación internas de ser interceptadas de forma inalámbrica.

Ampliamente utilizado porque solo requiere un certificado en el lado del servidor, lo que facilita su despliegue en comparación con los métodos de autenticación mutua.

MSCHAPv2

El protocolo de autenticación interno comúnmente utilizado dentro de un túnel PEAP, que se basa en un mecanismo de desafío-respuesta utilizando el hash NT de la contraseña del usuario.

La principal fuente de vulnerabilidad en los despliegues de PEAP debido a su dependencia del hashing MD4 y el cifrado DES obsoletos.

EAP-TLS

Un método EAP que requiere autenticación mutua, donde tanto el servidor RADIUS como el dispositivo cliente presentan certificados digitales para demostrar su identidad.

El estándar de oro de la industria para la seguridad WiFi empresarial, inmune a los ataques de diccionario sin conexión y de evil twin.

Evil Twin Attack

Un ataque inalámbrico en el que un punto de acceso no autorizado imita un SSID corporativo legítimo para engañar a los dispositivos clientes para que se conecten, lo que permite al atacante interceptar el tráfico o capturar credenciales de autenticación.

El vector principal utilizado por los atacantes para capturar intercambios de MSCHAPv2 de despliegues vulnerables de PEAP.

RADIUS (Remote Authentication Dial-In User Service)

Un protocolo de red que proporciona una gestión centralizada de autenticación, autorización y contabilidad (AAA) para los usuarios que se conectan y utilizan un servicio de red.

La infraestructura de servidor principal (como Cisco ISE o NPS) que procesa las solicitudes de autenticación 802.1X de los puntos de acceso.

PKI (Public Key Infrastructure)

Un conjunto de roles, políticas, hardware, software y procedimientos necesarios para crear, gestionar, distribuir, utilizar, almacenar y revocar certificados digitales.

La infraestructura fundamental requerida para desplegar EAP-TLS, que se ofrece cada vez más a través de plataformas SaaS nativas de la nube.

MDM (Mobile Device Management)

Software que permite a los administradores de TI controlar, asegurar y aplicar políticas en teléfonos inteligentes, tabletas y terminales.

Esencial para las migraciones a EAP-TLS, ya que se utiliza para distribuir de forma silenciosa certificados de cliente y perfiles de WiFi estrictos a los dispositivos corporativos.

MAB (MAC Authentication Bypass)

Un método de control de acceso basado en puertos que autentica los dispositivos en función de su dirección MAC en lugar de requerir un nombre de usuario/contraseña o certificado.

Utilizado como mecanismo de respaldo para autenticar dispositivos heredados sin interfaz de usuario (como impresoras) que no admiten protocolos 802.1X.

Ejemplos prácticos

Una cadena hotelera de 400 habitaciones utiliza actualmente PEAP-MSCHAPv2 para la red de su personal interno. El director de TI desea migrar a EAP-TLS, pero le preocupan 50 escáneres de inventario portátiles heredados que ejecutan un sistema operativo obsoleto y no admiten la inscripción de certificados. ¿Cómo debería el arquitecto de red gestionar esta migración sin interrumpir las operaciones de inventario?

El arquitecto de red debería implementar un enfoque segmentado. En primer lugar, desplegar una PKI en la nube y configurar el servidor RADIUS central para que acepte tanto EAP-TLS como PEAP-MSCHAPv2. Utilizar la plataforma MDM del hotel para distribuir certificados de cliente y un perfil de WiFi EAP-TLS actualizado a todos los portátiles y tabletas modernos del personal. Para los 50 escáneres heredados, crear un SSID oculto y dedicado asignado a una VLAN aislada. Configurar la omisión de autenticación basada en MAC (MAB) para estas direcciones MAC de escáner específicas en el servidor RADIUS. Aplicar ACL de red estrictas a esta VLAN para que los escáneres solo puedan acceder al servidor de la base de datos de inventario y a nada más. Una vez que todos los dispositivos modernos utilicen EAP-TLS, desactivar PEAP-MSCHAPv2 en la red principal del personal.

Comentario del examinador: Este enfoque equilibra perfectamente una seguridad sólida para la mayor parte de la flota con la continuidad operativa para el hardware heredado. Al aislar los dispositivos heredados en una VLAN restringida, el arquitecto mitiga el riesgo de que dichos dispositivos se utilicen como punto de pivote si se ven comprometidos, al tiempo que elimina con éxito la vulnerabilidad de PEAP-MSCHAPv2 de la red corporativa principal.

Una organización de comercio minorista ha implementado Windows 11 22H2 en su flota corporativa. El servicio de asistencia de TI empieza a recibir repentinamente incidencias de usuarios que no pueden conectarse a la red WiFi corporativa WPA2-Enterprise, que utiliza PEAP-MSCHAPv2. ¿Cuál es la causa probable y cuál es la solución inmediata?

La causa probable es la introducción de Windows Defender Credential Guard, que está habilitado por defecto en Windows 11 22H2 y versiones posteriores. Credential Guard aísla y protege los hashes de contraseñas NTLM y los Ticket Granting Tickets de Kerberos. Dado que PEAP-MSCHAPv2 requiere acceso al hash NT para generar el desafío-respuesta, Credential Guard interrumpe intencionadamente este método de autenticación para evitar el robo de credenciales. La solución inmediata es acelerar la migración a EAP-TLS, que utiliza autenticación basada en certificados y es totalmente compatible con Credential Guard. Una solución temporal y menos segura sería desactivar Credential Guard mediante directivas de grupo, pero esto se desaconseja encarecidamente, ya que debilita la postura de seguridad general del sistema operativo.

Comentario del examinador: Este escenario destaca un factor operativo moderno y crítico para migrar fuera de PEAP. Las propias mejoras de seguridad del sistema operativo de Microsoft están dejando activamente obsoleta la necesidad de acceder a los hashes heredados que requiere MSCHAPv2. La solución identifica correctamente a EAP-TLS como la solución permanente en lugar de depender de degradaciones de seguridad inseguras en el sistema operativo.

Preguntas de práctica

Q1. Está auditando la red inalámbrica de una filial recién adquirida. Utilizan PEAP-MSCHAPv2. El responsable de TI afirma que están protegidos contra los ataques de evil twin porque han ocultado el SSID y han desactivado la difusión del SSID. ¿Está su red a salvo de la captura de credenciales?

Sugerencia: Considere cómo se comportan los dispositivos clientes cuando están configurados para conectarse a redes ocultas, y si ocultar un SSID evita que un AP no autorizado lo suplante.

Ver respuesta modelo

No, la red no es segura. Ocultar el SSID (desactivar las tramas de baliza) no proporciona ninguna seguridad criptográfica. De hecho, los dispositivos configurados para conectarse a redes ocultas transmiten activamente solicitudes de sondeo que contienen el nombre del SSID, anunciando eficazmente la red oculta a cualquier atacante que esté escuchando. Un atacante puede capturar fácilmente el nombre del SSID, levantar un AP evil twin que transmita exactamente ese SSID y ejecutar el ataque estándar de captura de credenciales de MSCHAPv2. La única defensa es una validación estricta del certificado del servidor o la migración a EAP-TLS.

Q2. Durante un piloto de migración a EAP-TLS, distribuye certificados de cliente a 20 portátiles con Windows a través de Intune. Sin embargo, la autenticación falla en los 20 dispositivos. Los registros del servidor RADIUS muestran 'Certificado de cliente no confiable'. Los certificados de cliente fueron emitidos por su nueva PKI en la nube. ¿Qué paso crítico de configuración se omitió?

Sugerencia: Para que la autenticación mutua funcione, ambas partes deben confiar en la entidad que emitió el certificado de la otra parte.

Ver respuesta modelo

El servidor RADIUS no se ha configurado para confiar en la CA raíz de la nueva PKI en la nube. Aunque los portátiles tienen los certificados de cliente correctos, cuando los presentan al servidor RADIUS, este los rechaza porque no tiene los certificados raíz/intermedios de la PKI en la nube en su almacén de confianza local. Debe importar el certificado público de la CA raíz de la PKI en la nube en el almacén de autoridades de certificación de confianza del servidor RADIUS.

Q3. Su organización exige EAP-TLS para el WiFi corporativo. Un alto ejecutivo insiste en conectar su iPad personal no gestionado a la red corporativa para acceder a los paneles financieros internos. ¿Cómo responde a esta solicitud manteniendo la postura de seguridad de EAP-TLS?

Sugerencia: Considere los requisitos previos para EAP-TLS y la definición de un dispositivo 'gestionado'.

Ver respuesta modelo

No puede atender esta solicitud de forma segura en la red corporativa principal sin comprometer la arquitectura EAP-TLS. EAP-TLS requiere un certificado de cliente. Dado que el iPad no está gestionado (BYOD), el departamento de TI no puede distribuir un certificado de forma segura a través de un MDM. Permitir que el ejecutivo instale manualmente un certificado introduce un riesgo significativo y una gran carga administrativa. El enfoque correcto es denegar el acceso al SSID corporativo. En su lugar, el ejecutivo debe conectarse al WiFi de invitados y utilizar una VPN corporativa segura (que admita la autenticación moderna MFA/SAML) para acceder a los recursos internos, o bien el dispositivo debe registrarse en el MDM corporativo para recibir un certificado.

Continúe leyendo esta serie

Cómo configurar SCEP para el registro automatizado de certificados WiFi corporativos

Esta guía explica cómo configurar SCEP (Simple Certificate Enrollment Protocol) para el registro automatizado de certificados WiFi corporativos, abarcando toda la arquitectura desde PKI y NDES hasta el despliegue de perfiles MDM y la validación RADIUS. Está dirigida a directores de TI, arquitectos de red y CTO de hoteles, cadenas de retail, estadios, centros de conferencias y organizaciones del sector público que necesitan ir más allá de las claves precompartidas e implementar una autenticación 802.1X EAP-TLS escalable y basada en la identidad. La plataforma de superposición en la nube de Purple, que es independiente del hardware, se integra directamente con esta arquitectura, proporcionando la capa de WiFi para invitados y BYOD que coexiste junto a la red de personal autenticada por certificado.

La guía empresarial de SCEP: Despliegue de Simple Certificate Enrollment Protocol para la seguridad automatizada de WiFi en campus

Esta guía de referencia técnica proporciona un diseño arquitectónico definitivo y una estrategia de implementación paso a paso para el despliegue de certificados WiFi empresariales mediante SCEP. Cubre las diferencias críticas entre SCEP y PKCS, la secuencia exacta de despliegue requerida para el éxito y estrategias reales de mitigación de riesgos para líderes de TI.

Cómo implementar SCEP para el registro automatizado de certificados WiFi

Esta guía explica cómo implementar SCEP (Simple Certificate Enrollment Protocol) para el registro automatizado de certificados WiFi en entornos empresariales. Cubre el diseño arquitectónico completo, desde el diseño de PKI y la integración con MDM hasta la secuencia de despliegue obligatoria de tres pasos, y muestra a los responsables de TI y arquitectos de red cómo eliminar las credenciales compartidas, automatizar la gestión del ciclo de vida de los certificados y cumplir con los requisitos de PCI DSS y GDPR a escala.