Fatiga de MFA y la sesión robada

Una notificación de segundo factor solo se envía cuando alguien ya escribió bien la contraseña: es el segundo paso, nunca el primero. Por eso una ráfaga de notificaciones que la persona no pidió no es un problema del teléfono, es la prueba de que su contraseña está en otras manos. En el módulo del SIEM por tuberías aprendiste a contar ese bombardeo (en ATT&CK, T1621); aquí importa lo que viene después de la última fila, cuando alguien, a las dos de la mañana y con el teléfono sonando cada dos minutos, aprieta «aprobar» para que pare.

Esa aprobación no dice «la persona entró»: dice «alguien que tiene la contraseña consiguió una sesión». La respuesta, por tanto, no es solo cerrar esa sesión, porque la contraseña sigue sirviendo y mañana vuelve a empezar. Y la defensa que lo hace mucho más difícil también está en el registro: la columna del número en pantalla. Cuando la notificación exige escribir en el teléfono el número que aparece en la pantalla donde se está entrando, no se puede aprobar medio dormido sin estar delante.

Cada notificación lleva la dirección del inicio de sesión que la provocó, y esa dirección es el indicador que va al escalado, a la lista de bloqueo y a la búsqueda en el resto de cuentas: si desde ahí se probó una contraseña, puede que se hayan probado más. El registro de inicios interactivos lo confirma, porque la notificación aprobada abre una sesión con su identificador.

Cuando alguien inicia sesión con contraseña y segundo factor, el proveedor de identidad no vuelve a preguntarle en cada clic: le entrega un token, y el navegador lo guarda como cookie de sesión. A partir de ahí, cada vez que una aplicación necesita seguir trabajando, presenta ese token —en el registro aparece como un uso no interactivo: nadie escribe nada— y el proveedor lo acepta porque el token ya lleva dentro la prueba de que se hizo el segundo factor. Es lo que hace cómodo trabajar, y es lo que hace valioso robarlo.

Si esa cookie sale del equipo —por un programa que roba lo que guarda el navegador, o por una página falsa que se pone en medio del inicio de sesión real y se queda con el resultado—, quien la tenga no inicia sesión: continúa la de la persona. No escribe contraseña, no le llega ninguna notificación a nadie y, en muchas directivas, cumple el requisito de segundo factor sin tocar un teléfono. En ATT&CK, el robo es T1539 y su uso, T1550.004. El registro no dice cómo salió la cookie; dice desde dónde se está usando.

Busca en los inicios interactivos de sbecerra cuántas veces se autenticó de verdad ese día, y después mira sus usos no interactivos.

La señal más fiable de una sesión robada es que el mismo identificador de sesión aparece a la vez desde dos sitios. Una persona puede cambiar de dirección a media mañana —se conecta a la VPN, sale del edificio y sigue con el teléfono—, pero no alterna cada pocos minutos entre dos países, y su navegador no pasa de un sistema a otro por su cuenta. El agente de usuario —la cadena que dice qué navegador y qué sistema hacen la petición— no prueba nada solo, porque se puede falsificar; pero cuando cambia dentro de una misma sesión y vuelve a cambiar, son dos máquinas.

Agrupa los usos no interactivos por sesión y cuenta direcciones y agentes distintos en cada una.

En la misma tabla hay otra sesión que también sale desde dos direcciones, y no es ningún incidente. Antes de escalar una sesión robada hay que poder decir por qué no es la otra cosa.