La sesión no vuelve a preguntar

A las 08:13 entró un correo con tema de revisión de un documento en SharePoint. A las 08:16 el usuario hizo clic. A las 08:19 completó el desafío de doble factor —aprobó la notificación en el teléfono, la que le habían enseñado a aprobar— y el registro de identidad anotó un éxito de MFA perfectamente normal. Ningún fallo, ninguna alerta de fuerza bruta, ninguna contraseña filtrada. La persona correcta, con el segundo factor correcto, desde el dispositivo correcto. A las 08:40 el SOC cortó el acceso, y para entonces el atacante llevaba veintiún minutos leyendo el buzón, había encontrado las instrucciones de la VPN y estaba enumerando el Active Directory desde adentro de la red corporativa.

El ataque no fue contra la pregunta, fue contra la respuesta.

No rompió el MFA. Esa es la parte que cuesta aceptar. El MFA funcionó exactamente como se diseñó: verificó que quien apretaba el botón era el dueño de la cuenta, en ese instante, y devolvió lo que devuelve siempre que la verificación sale bien —un token de sesión, una cadena criptográfica que el navegador guarda para no tener que volver a preguntar en cada clic—. El ataque no fue contra la pregunta. Fue contra la respuesta. El flujo de login pasó por un servidor intermedio del atacante, un adversary-in-the-middle que reenvió cada pantalla de Microsoft al usuario y cada respuesta del usuario a Microsoft, transparente, sin cambiar una coma, y en el momento en que Microsoft emitió la cookie de sesión, la copió. Después la inyectó en su propio navegador, desde otra IP y otro equipo, y el servicio la aceptó porque hacía exactamente lo que le pedían: reconocer una sesión ya abierta. La sesión no vuelve a preguntar. Ese es el punto entero.

Lo que llamamos autenticación resuelve una pregunta muy angosta: ¿eres quién dices ser, ahora? La contraseña, la huella, el código de seis dígitos, la notificación push —todo el aparato— existe para contestar eso una vez, en la puerta. Lo que viene después no es autenticación, es memoria: el sistema decide confiar en un estado durante un rato para no interrogarte cada vez que mueves el mouse. Esa confianza es el token. Y un token es una credencial portadora, bearer en el sentido más literal e incómodo del término: vale para quien lo lleva, no para quien lo ganó. Como un billete. El banco no te pregunta de dónde lo sacaste. SUNBURST, en su momento, no necesitó adivinar contraseñas de nadie: se movió con confianzas ya firmadas. Acá el mecanismo es más chico y más cotidiano, pero la forma es idéntica —lo caro de robar no es la identidad, es la sesión que la identidad dejó abierta.

El permiso que sobrevive a la contraseña.

Hay una versión todavía más limpia, que ni siquiera se molesta en interponerse en el tráfico. El abuso de consentimiento OAuth. El usuario recibe un enlace que lo lleva a una pantalla de autorización auténtica de Microsoft —no falsificada, la real— donde una aplicación de terceros pide permisos: leer el correo, leer los archivos, y offline_access, que es el permiso a seguir haciéndolo cuando el usuario no esté conectado. El usuario lee “aplicación de productividad”, ve el logo de siempre, y toca Aceptar. No entregó la contraseña. No la entregó porque no hizo falta pedírsela: entregó algo mejor, un token de aplicación con permisos delegados que sobrevive a los cambios de contraseña, a los cierres de sesión, y a buena parte de las revocaciones que un administrador apurado aplicaría por reflejo. La contraseña se puede rotar. El consentimiento hay que ir a buscarlo y borrarlo a mano, y primero hay que saber que está ahí.

Un sí genuino que no significa lo que la víctima cree.

El consentimiento OAuth es primo del engaño humano que ya toqué antes. Es un sí arrancado por diseño. No se le miente al usuario sobre lo que aprueba —los permisos están escritos en la pantalla, en su idioma, con el candado verde—; se apuesta a que va a aprobar igual, porque la interfaz que pide es indistinguible de las cien que aprobó esta semana, porque la autoridad de la marca cubre la pregunta, y porque nadie lee la letra de los alcances de una app cuando tiene cuarenta correos sin abrir. Es la misma mecánica de una secta que hace firmar el compromiso a plena luz: el problema no es que el sí sea falso, es que es genuino y de todos modos no significa lo que la víctima cree que significa. Un evento aislado de MFA exitoso no implica legitimidad. Un consentimiento otorgado tampoco. La firma es real; lo que firmó no era lo que leyó.

Adentro, deja de parecerse a un ataque.

Y una vez que el token existe, el resto del incidente deja de parecerse a un ataque y empieza a parecerse a un empleado trabajando. El atacante entra por la API de Graph con inicios de sesión no interactivos —sin pantalla de login, porque ya tiene el token, para eso lo robó— y busca en el buzón las palabras que importan: factura, pago, proveedor, VPN. Encuentra el correo donde IT le explicó al usuario, hace ocho meses, cómo conectarse a la red desde casa. Se conecta. Ahora está adentro del perímetro, con una cuenta válida, y el firewall lo saluda. Enumera el directorio con herramientas que ya vienen en Windows —living off the land, porque un binario firmado por Microsoft no dispara las alarmas que dispara un ejecutable raro—, barre los recursos compartidos por SMB, encuentra las carpetas administrativas, y antes de cifrar nada va por las copias de seguridad. El ransomware moderno no empieza cifrando; empieza asegurándose de que no puedas recuperar. Apagar el EDR, borrar las shadow copies, tocar la consola de backups: eso es el ataque. El cifrado es apenas la factura.

La huella que sí queda.

Cada uno de esos pasos deja una huella, y ninguna es la que uno vigila por instinto. El éxito de MFA no —ese se ve bien—. Pero el mismo token usado desde dos países en diez minutos sí; eso es imposible travel, y es una de las pocas señales que el robo de sesión no puede esconder, porque el atacante puede copiar la cookie pero no puede estar donde estás tú. El dispositivo y el user-agent que no coinciden con los tuyos, sí. La creación de una regla de buzón que mueve a una carpeta oculta todo lo que diga “pago” y lo marca como leído —New-InboxRule justo después de un acceso por API desde una IP nueva— es una de las señales más honestas que hay, porque casi nadie automatiza el ocultamiento de su propia correspondencia financiera por razones inocentes. El SOC de la simulación no detectó ninguna de esas cosas por separado. Las detectó cuando se correlacionaron en una historia: consentimiento anómalo, más acceso no interactivo desde IP inusual, más regla de ocultamiento, más picos de descarga en Graph. Ninguna alerta sola alcanzaba el umbral. Juntas eran un incidente crítico. Esto es lo mismo que vengo diciendo sobre el paso del alert al veredicto: la evidencia rara vez falta; lo que falta es el analista que junta cinco cosas tibias y ve que forman una sola cosa que arde.

El control contesta bien la pregunta que no importa.

La lección no es que el MFA sirva de poco. Sirve, y muchísimo: sube el piso, mata la reutilización de contraseñas filtradas, corta el noventa y pico por ciento de los intentos oportunistas que ni se molestan en montar un proxy. La lección es más incómoda que eso, y es sobre qué clase de garantía es. El MFA protege un instante —el del login— y a partir de ahí el sistema opera sobre un supuesto de continuidad: que quien tiene la sesión sigue siendo quien la abrió. Ese supuesto es cómodo, es lo que hace usable a una computadora, y es exactamente el lugar donde se mete el ataque. La pregunta que el control contesta bien no es la pregunta de la que depende la seguridad. Autenticar es un evento; seguir siendo el mismo es un estado, y nada en la arquitectura clásica vuelve a chequear el estado una vez que el evento salió bien. Por eso el modelo que no confía en la sesión no es paranoia de vendedor: es la única postura coherente con lo que un token realmente es. Never trust, always verify suena a eslogan hasta que entiendes que la alternativa —verify once, trust for eight hours— es literalmente el agujero por donde entró el que leyó el correo del usuario mientras el usuario almorzaba.

Es una copia de una copia. El token que el atacante inyecta es idéntico al legítimo hasta el último byte, porque es el legítimo; no hay forma de distinguirlos mirando el token, solo mirando el contexto alrededor —desde dónde, con qué dispositivo, a qué velocidad, para hacer qué—. Toda la defensa que queda, una vez emitido el token, es esa: dejar de preguntarle a la credencial quién es y empezar a preguntarle a la sesión si se está comportando como la persona que dice ser. La firma es perfecta. Hay que mirar todo lo demás.