El ataque más eficiente contra el MFA no es quebrar el MFA: es robar la cookie de sesión y saltarse la autenticación entera. Sin contraseña. Sin segundo factor. Acceso total. Este vector dominó el ecosistema de infostealers en los últimos años. Ahora, este vector tiene fecha de vencimiento. Al menos en Chrome.
El problema: las session cookies bypasean el MFA
Los infostealers procesaron 51,7 millones de paquetes en 2025, un aumento del 72% respecto al año anterior (Constella). De esas credenciales, el 98,6% contenía contraseñas activas. El patrón de ataque es simple y escalable: el malware roba la cookie de sesión del navegador → el atacante reutiliza la sesión activa → acceso total a la cuenta, sin pasar por autenticación.
El MFA protege el login. No protege la sesión después del login. La cookie de sesión es la prueba de que el usuario ya se autenticó. Quien tiene la cookie tiene la sesión. En ambientes enterprise, una sola cookie de O365 o Google Workspace puede dar acceso lateral a toda la infraestructura. La cadena de defensa tiene un eslabón que nadie estaba protegiendo.
Antes de DBSC, la respuesta era reactiva: heurísticas para detectar cookies robados, análisis del comportamiento de la sesión, revocación manual. Funciona parcialmente. El atacante siempre tiene una ventana de oportunidad entre el robo y la detección.
Cómo funciona DBSC: binding criptográfico al hardware
Device Bound Session Credentials (DBSC) llegó a la disponibilidad general. Google lo anunció el 28 de mayo de 2026: habilitado por defecto en Chrome para Windows.
El mecanismo es directo: durante la autenticación, Chrome genera un par de claves criptográficas dentro del chip de seguridad del dispositivo. En Windows, el TPM. En macOS, el Secure Enclave (Chrome 148). La clave privada nunca sale del hardware. No puede ser exportada, copiada ni exfiltrada por malware.
Las cookies de sesión pasan a ser short-lived. Cuando expiran, Chrome necesita probar la posesión de la clave privada antes de renovar. Esa prueba ocurre dentro del chip de seguridad: la cookie de renovación solo se emite si la prueba criptográfica es válida. Sin la clave hardware-bound, la cookie robada expira y no se renueva. El atacante se queda con una cookie muerta.
Google reportó una reducción significativa del session theft desde el despliegue inicial. El cambio es estructural: de reactivo a proactivo. Antes, detectar cookies robados con heurísticas. Ahora, las cookies robadas son inútiles sin la clave que vive en el hardware.
Por qué DBSC es la mejora de seguridad de navegador más significativa en años
El impacto no es incremental. DBSC invalida el vector más usado para bypasear el MFA a escala. Los infostealers evolucionaron para especializarse en session cookies precisamente porque ese bypass es barato, escalable y funciona contra cualquier servicio que use cookies de sesión, es decir, prácticamente todos.
DBSC cambia la economía del ataque. Antes: el infostealer roba la cookie → el atacante accede a la cuenta. Después de DBSC: el infostealer roba la cookie → la cookie expira → el atacante no accede. El costo del ataque no cambia, pero el ROI cae a cero para este vector específico.
Ninguna otra mejora de navegador en los últimos años tuvo este impacto práctico. Las cookies SameSite mitigaron CSRF. HTTPOnly mitigó el robo de cookies vía XSS. Pero ninguno de los dos resolvió el problema del robo de cookies vía malware, que es exactamente el vector que explotan los infostealers. DBSC ataca el problema en la raíz: la cookie robada no funciona fuera del dispositivo.
Lo que DBSC no resuelve
DBSC es esencial. No es suficiente. Las limitaciones son reales y hay que enfrentarlas.
Cobertura limitada. Chrome en Windows hoy. macOS llegando en Chrome 148. Mobile y otros navegadores no lo soportan. Firefox y Safari no anunciaron soporte. La protección cubre una parte significativa del tráfico enterprise, pero no lo cubre todo.
Los infostealers roban más que cookies. Contraseñas guardadas, PII, claves SSH, configuraciones VPN, cloud tokens. DBSC protege la sesión. El resto sigue siendo exfiltrado. Un infostealer que no consiga robar cookies sigue robando credenciales que pueden usarse en credential stuffing (relleno automático de credenciales filtradas), acceso VPN y movimiento lateral.
Credenciales ya en circulación. Los 51,7 millones de paquetes de 2025 ya están en el underground. DBSC previene nuevos robos de sesión. No remedia lo que ya se filtró. Las credenciales comprometidas antes de DBSC siguen válidas hasta que se roten.
Dispositivos sin TPM. Sin chip de seguridad, Chrome hace fallback al comportamiento estándar. El hardware antiguo y los dispositivos personales sin TPM quedan desprotegidos. En ambientes con BYOD, esta es una brecha real.
Malware activo durante el login. Si el infostealer está corriendo en el momento de la autenticación, puede interceptar la cookie antes de que el binding se concluya. Es un ataque más complejo, exige timing y persistencia, pero es posible. DBSC protege contra el robo de cookies en reposo, no contra la interceptación en tiempo real.
Conclusión
DBSC es la mejora de seguridad de navegador más significativa en años. Mata el vector más usado para bypasear el MFA. Pero es una capa, no una solución completa. Los infostealers siguen robando todo lo que no es cookie de sesión. Y 51,7 millones de paquetes ya están afuera.
En Tech86 implementamos defensa en profundidad contra infostealers, desde el hardening de endpoints hasta el monitoreo de credenciales en circulación en el underground. DBSC es una capa esencial de esa defensa. No es la única que necesitas.