Hiciste todo bien. El doble factor está obligatorio en cada cuenta. Nadie reutilizó una contraseña de una filtración de 2019. Y aun así el atacante entró, leyó el correo del director financiero durante una semana y redirigió una transferencia.
Cuando esto pasa, el análisis posterior casi nunca encuentra una contraseña descifrada ni una solicitud de MFA vencida. Encuentra una sesión de navegador robada. El inicio de sesión ya ocurrió, en un dispositivo legítimo, hecho por el usuario real. El atacante simplemente entró cargando la prueba.
Por qué el 2FA dejó de alcanzar sin que nadie lo dijera
Esta es la parte que a casi ningún administrador le explicaron con claridad. La autenticación de dos factores protege el momento en que inicias sesión. Una vez adentro, tu navegador guarda una cookie de sesión. Esa cookie es la credencial que dice "sí, esta persona inició sesión", y tu navegador la presenta en cada solicitud para que no tengas que escribir la contraseña y tocar el teléfono cuarenta veces al día.
Un malware llamado infostealer va tras esa credencial. Corre en una laptop infectada, copia las cookies de sesión activas del navegador y se las lleva. El atacante carga esas cookies en su propio navegador y aterriza dentro de la cuenta ya autenticado. Sin solicitud de contraseña. Sin reto de MFA. No hay nada que retar, porque para el sistema la sesión ya estaba aprobada.
No es una técnica marginal. La investigación de identidad de Constella encontró que los infostealers procesaron 51,7 millones de paquetes en 2025, un salto del 72% frente al año anterior, y buena parte de por qué esos paquetes valen tanto es que llevan cookies de sesión activas que esquivan el MFA de plano. SpyCloud, trabajando con un conjunto de datos distinto, recapturó 8.600 millones de cookies y artefactos de sesión robados de infecciones de malware, y contabilizó 1,17 millones de registros de malware que contenían tanto credenciales corporativas como cookies de sesión activas. Las familias que hacen la mayor parte de esto a principios de 2026 son LummaC2, ACRStealer, StealC y Vidar. Una sola máquina infectada en tu organización puede convertirse en una sesión autenticada en manos ajenas.
Qué activó Google, y cuándo
El 28 de mayo de 2026, Google anunció que las Device Bound Session Credentials (DBSC) en el navegador Chrome sobre Windows ya están disponibles de forma general y activadas por defecto para los usuarios de Google Workspace. El despliegue empezó de manera gradual el 25 de mayo y puede tardar hasta 60 días en aparecer por completo entre Rapid Release y Scheduled Release.
La idea detrás de DBSC es simple una vez que le quitas el acrónimo. Cuando se crea una sesión, Chrome genera una clave criptográfica privada y la guarda dentro del TPM del dispositivo, un chip de seguridad integrado en el hardware de la máquina. La cookie de sesión queda atada a esa clave. A partir de ahí, cada vez que la sesión se renueva, Chrome tiene que demostrar que todavía posee la clave del dispositivo que corresponde. Una cookie copiada de esa laptop no trae la clave a la que estaba atada, así que en la máquina del atacante simplemente falla la validación. La credencial robada ya no abre la puerta.
Si el sistema detecta que una sesión no coincide con el dispositivo al que estaba atada, se le pide al usuario que vuelva a iniciar sesión. El usuario honesto se encoge de hombros y se reautentica. El atacante queda trabado.
Dos cosas importan para tu presión arterial aquí. Está activado por defecto, para todos los clientes de Workspace, los suscriptores de Workspace Individual y las cuentas personales de Google. No hay control de administrador para deshabilitarlo ni ajuste de usuario final que cambiar. No tienes que desplegar nada para obtener la protección base.
La letra chica: hasta dónde no llega DBSC
Es un control fuerte, no un campo de fuerza. Conocer sus bordes es todo el trabajo, porque los atacantes se mueven hacia cualquier cosa que dejaste sin cubrir.
- Solo Chrome y Windows. Necesita Chrome 146 o posterior sobre Windows, y un TPM para guardar las claves. El TPM es estándar en la mayoría del hardware con Windows 11, pero las máquinas viejas o sin gestionar pueden no calificar.
- macOS, móviles y otros navegadores siguen expuestos. Una sesión robada de Safari, de un teléfono, o de Firefox o Edge no recibe esta atadura al dispositivo. El análisis de Constella señala lo mismo: el alcance de Chrome sobre Windows deja sobre la mesa a macOS, a los móviles, a otros navegadores y al robo de tokens fuera del navegador.
- Los tokens fuera del navegador no están cubiertos. Los tokens OAuth y las credenciales de aplicaciones que viven fuera del navegador son un problema aparte que DBSC no toca.
Lee esa lista como un mapa de dónde todavía necesitas otras defensas, no como una razón para descartar DBSC. Para el lugar donde realmente ocurre la mayoría del robo de credenciales, la laptop corporativa con Windows corriendo Chrome, la cookie de mayor valor acaba de volverse mucho menos útil de robar.
Qué debería hacer realmente un administrador
No se requiere nada para activar DBSC. Pero "no se requiere nada" y "no hay nada que valga la pena hacer" son cosas distintas. Unos pocos movimientos convierten un valor por defecto pasivo en algo que puedes ver y dirigir.
Vigila los eventos de binding. En la herramienta de investigación de seguridad, DBSC escribe registros de auditoría que puedes revisar. Los eventos de registro de usuario muestran DBSC key binding y DBSC key validation como Succeeded o Failed. Los eventos de registro de Access Evaluation exponen solicitudes denegadas con códigos como DBSC_BOUND_COOKIE_MISSING, DBSC_BOUND_COOKIE_CORRUPTED y DBSC_BOUND_COOKIE_EXPIRED. Un pico de validaciones fallidas es una señal que vale la pena seguir, no ruido que silenciar.
Evalúa exigir sesiones atadas. DBSC funciona junto con Context-Aware Access. Si quieres ir más allá del valor por defecto, puedes usar Context-Aware Access para requerir una sesión atada y bloquear que las no atadas lleguen a aplicaciones específicas. Tiene sentido para tus sistemas más sensibles; pruébalo antes de apuntarlo a todo el mundo, porque puede dejar afuera a cualquiera que esté en un navegador, sistema operativo o dispositivo no compatible.
Estandariza la flota para que los dispositivos realmente califiquen. DBSC solo ayuda en máquinas que cumplen el listón. Chrome gestionado, más Windows 11 con un TPM funcionando y versiones actuales del navegador, es lo que hace que la protección sea real en lugar de teórica. Si tu flota es una colcha de retazos de laptops personales y versiones viejas de Chrome, esa es la brecha que hay que cerrar primero.
Sigue agregando capas. Passkeys resistentes al phishing para reforzar el inicio de sesión en sí, Context-Aware Access para condicionar por postura del dispositivo, e higiene básica de endpoints para que los infostealers ni siquiera puedan ejecutarse. DBSC le quita un arma de las manos al atacante. No se las quita todas.
La conclusión honesta
El robo de sesión era la brecha silenciosa detrás de muchos incidentes del tipo "pero teníamos MFA", y Google acaba de cerrar una buena porción de eso gratis, en la plataforma donde vive la mayoría de tus usuarios. Es una noticia genuinamente buena. También es el tipo de cambio que es fácil malinterpretar como "ya terminamos". No terminaste. Estás mejor protegido en Chrome y Windows, y ahora tienes registros que lo demuestran y una lista clara de lo que todavía falta cubrir.
Si prefieres no armar todo esto por tu cuenta, esta es la clase de auditoría que hacemos cada semana: confirmar que DBSC está aterrizando de verdad en tu flota, conectar el monitoreo para que los bindings fallidos lleguen a una persona, decidir si la aplicación de Context-Aware Access encaja con tu riesgo, y encontrar las brechas de macOS y móviles antes de que lo haga alguien más. Somos un equipo independiente de Workspace y Cloud, no un revendedor empujando una licencia. Si tu última revisión de seguridad es anterior a todo esto, es un buen momento para una mirada nueva.