Sesiones y tokens, lo que sobrevive a la contraseña

En un incidente de nube, lo que el atacante conserva no es una máquina: es una sesión. Cuando alguien inicia sesión, el proveedor de identidad entrega un token de acceso (vale poco tiempo) y, casi siempre, un token de actualización que sirve para pedir tokens nuevos sin volver a escribir la contraseña. La sesión se apoya en esos tokens, no en la contraseña que se usó para abrirla.

Por eso restablecer la contraseña no es lo mismo que cortar el acceso: según el proveedor y su configuración, las sesiones y los tokens ya emitidos pueden seguir valiendo. Es una propiedad que se comprueba en la configuración del proveedor, no se supone.

El registro de inicios de sesión dice quién, cuándo, desde qué dirección, con qué aplicación y desde qué dispositivo. Además trae cómo se cumplió el segundo factor: una persona que lo aprueba en su teléfono deja «aprobado», pero hay un caso distinto, el de una sesión que hereda la comprobación porque alguien se llevó su cookie ya validada. El segundo factor no falló: nunca se le pidió a quien estaba usando la sesión.

Un acceso exitoso desde un dispositivo que la empresa no tiene registrado, con el segundo factor heredado, es una combinación que se separa del patrón normal de la persona.

El martes a las 10:30 soporte restableció la contraseña de la cuenta. Una sesión es sospechosa si nació antes de ese restablecimiento y siguió usándose después, desde fuera de la oficina. Esa es la señal de que el restablecimiento no tocó la sesión del atacante. La tabla de sesiones guarda, para cada una, cuándo se creó y cuándo se usó por última vez.

Identificar la sesión exacta importa porque revocar de verdad es revocar por identificador y por cuenta; y porque el informe tiene que decir cuál era.

Un atacante con una sesión viva no necesita la contraseña: necesita no perder el acceso. Una forma es registrar un método de segundo factor propio, para poder superar la comprobación aunque la sesión caiga. Si ese método sigue registrado después de revocar sesiones y cambiar la contraseña, el atacante vuelve a entrar con un acceso «legítimo».

Los cambios de cuenta se leen con el mismo cuidado que los inicios de sesión: quién los hizo, desde dónde y qué detalle trae.

Contener una cuenta comprometida es una secuencia, y el orden importa. Hay que preservar los registros (exportar el registro de inicios de sesión antes de tocar nada), revocar sesiones y tokens, quitar los métodos de segundo factor que la persona no registró, restablecer la contraseña y, solo entonces, devolver la cuenta a su dueña con una verificación. Si se hace solo el restablecimiento, es lo que ya pasó en este caso: la sesión sobrevivió.

La razón de preservar primero es la misma de todo el ciclo: lo que se cambia sin copiar ya no se puede reconstruir.