Hay una frase que escucho seguido cuando reviso cómo está montada la identidad en una empresa: «nosotros tenemos doble factor». Casi siempre es verdad. Casi nunca es suficiente.
El doble factor protege un instante muy concreto: el momento en que alguien se identifica. Aprueba usted la notificación y el servicio le entrega un token de sesión. Ese token es la llave real. Mientras siga vivo, quien lo tenga es usted. Sin contraseña, sin código, sin preguntas.
Ya no le roban la contraseña, le roban la sesión
MITRE lo tiene catalogado desde hace años como robo de cookie de sesión web, y hay dos caminos que veo una y otra vez.
El primero es un infostealer en el equipo. Un instalador descargado de un resultado patrocinado, una extensión de navegador, un archivo que llegó por chat. El programa ni se molesta con las contraseñas: copia el almacén de cookies del navegador y lo manda fuera. Ahí van las sesiones del correo, del CRM, del panel de la nube, de todo lo que usted dejó abierto.
El segundo es un proxy en el medio: una página de inicio de sesión clonada que reenvía en vivo lo que usted escribe al sitio auténtico. Usted ve la pantalla de siempre, aprueba su segundo factor de verdad y entra de verdad. El intermediario se queda con la cookie que el servicio acaba de emitir.
La incomodidad es esta: el token no sabe que cambió de manos. Fue emitido correctamente, después de una autenticación legítima, a un usuario legítimo. Técnicamente no hay nada que reclamar.
¿Por qué el cansancio es una técnica de ataque?
La otra puerta es todavía más simple y no necesita malware. Se llama generación de solicitudes de MFA, aunque en la práctica todo el mundo la conoce como fatiga o bombardeo.
El atacante ya tiene la contraseña, normalmente de una filtración vieja que nadie rotó. Lo único que le falta es el segundo factor, así que lo pide. Una vez, diez veces, cincuenta veces, a las tres de la madrugada. Y en algún momento alguien acepta para que el teléfono deje de sonar.
Aquí no hay ninguna vulnerabilidad que parchear. El sistema preguntó lo que tenía que preguntar y el usuario contestó que sí. Por eso los formatos que más se doblan son justo los dos más cómodos: el código por SMS y la notificación de aprobar o rechazar.
Los 44.791 tokens que alguien publicó en Telegram
En agosto apareció en Telegram un volcado de 7 GB con datos robados de 5.871 máquinas en 162 países. Okta lo analizó y encontró 44.791 tokens JWT únicos. De esos, 1.843 seguían siendo válidos el día en que el archivo se hizo público, más 24 claves de API que aún funcionaban.
Un detalle que me parece peor que las cifras: el 17,7% de esos tokens llevaba datos personales en texto plano dentro del propio token. Nombre, correo, teléfono. No hizo falta ni usarlos para que hubiera fuga.
Lo que me preocupa de verdad son las identidades que no son personas
Aquí es donde esto se cruza con mi trabajo diario. En ese mismo volcado había cientos de tokens de servicios de inteligencia artificial y claves de proveedores de modelos.
Una cuenta de servicio no tiene teléfono y un agente automatizado no recibe notificaciones de nada. Son credenciales que viven meses, a veces años, con permisos amplios porque así fue más rápido hacer que la integración funcionara. Cuando alguien se lleva una de esas no hay segundo factor que consultar: hay un proceso que sigue trabajando, puntual y silencioso, para otro dueño.
Cada automatización que sumamos es una llave más. Conviene contarlas, porque normalmente nadie las mira hasta que hace falta. Eso, puesto en orden, es lo que se llama gestión de identidades y accesos.
¿Qué queda cuando la autenticación ya no opina?
Si el atacante entra con una sesión válida, la autenticación no tiene nada que decir. La única defensa que queda es notar que esa sesión se comporta distinto: el mismo token apareciendo desde otro proveedor de internet, dos ubicaciones imposibles en veinte minutos, una descarga masiva del buzón un domingo por la noche.
Eso ya no es trabajo de identidad, es trabajo de detección. Es lo que hace un SOC vigilando 24/7, y es la razón por la que Zero Trust insiste en que ninguna sesión se da por buena para siempre.
En lo práctico hay cuatro cosas que cambian el resultado. Pasar a llaves de seguridad o passkeys, que no se pueden reenviar a un proxy. Acortar la vida de los tokens y atarlos al dispositivo que los pidió. Vigilar el endpoint con EDR, porque el almacén de cookies vive ahí y no en la nube. Y revisar las credenciales de máquina, esas que nadie recuerda haber creado.
Hay una más, y es la que casi siempre se olvida cuando algo huele mal: cambiar la contraseña no cierra la sesión robada. Hay que revocar la sesión. Son dos botones distintos y el segundo es el que importa.
Si quiere saber qué tan expuesto está, empiece por mirar qué sesiones y qué claves siguen vivas ahora mismo. Nosotros lo revisamos en la evaluación de seguridad gratuita.
El doble factor no falló. Contestó bien la pregunta que le tocaba hacer. El problema es que el atacante dejó de hacer esa pregunta.
