Cuando el MFA no es suficiente: tokens, cookies y API keys como nuevas llaves de acceso
En los últimos años, la Autenticación Multifactor —mejor conocida como MFA — se ha convertido en una de las principales recomendaciones para proteger cuentas corporativas, aplicaciones web, servicios en la nube, plataformas de desarrollo y accesos administrativos para infraestructura crítica. La lógica es sencilla: aunque el adversario obtenga la contraseña, necesitará un segundo mecanismo para poder lograr el acceso de manera exitosa.
Ante este escenario, en las pruebas de seguridad aplicativa, revisiones de arquitectura e investigaciones de incidentes, así como las investigaciones realizadas por el equipo de Cyber Threat Research del Scitum Innovation Center, se está observando un patrón cada vez más frecuente: muchos ataques modernos ya no buscan vulnerar el MFA, sino evitarlo por completo. Para ello, los adversarios apuntan a los elementos que se generan después de que el usuario ya se autenticó correctamente: cookies de sesión, tokens OAuth 2.0, SSO (Single Sign-On), JWT (JSON Web Token), Access y Refresh tokens, y API keys.
Estos elementos funcionan como comprobantes de acceso. Si son válidos, la aplicación o el API asumen que quien los presenta es el usuario, la aplicación o el servicio autorizado. Por eso, cuando un adversario logra obtenerlos, puede acceder a recursos protegidos sin conocer la contraseña y sin volver a pasar por la autenticación multifactor.
El objetivo de este artículo es explicar, desde una perspectiva técnica, por qué el robo o abuso de tokens, cookies, OAuth y API keys representa un problema de diseño en muchas arquitecturas actuales, cómo los adversarios están aprovechando estas debilidades en ataques recientes y qué controles pueden implementar las organizaciones para reducir este riesgo.
El problema: después del login también hay identidad
Cuando un usuario inicia sesión en una aplicación, normalmente ocurre lo siguiente:
Esto evita que el usuario tenga que ingresar contraseña y MFA en cada clic o interacción con el aplicativo, facilitando la usabilidad y la experiencia de navegación del usuario. El problema aparece cuando esos elementos se tratan como valores portables, reutilizables y de larga duración.
En la práctica, un objeto de sesión puede representar diferentes riesgos como:
| Elemento | Uso común | Riesgo principal |
| Cookie de sesión | Mantener autenticado al usuario en el navegador | Si se roba, permite el secuestro de sesión (session hijacking o cookie hijacking) |
| Access token | Autorizar llamadas a las APIs o endpoints | Si se filtra, permite acceder a recursos dentro del alcance autorizado |
| Refresh token | Renovar Access tokens sin pedir login nuevamente | Si se roba, se extiende el tiempo de la sesión robada por el adversario |
| API key | Autenticar scripts, servicios o integraciones | Si se expone, permite el abuso directo a los endpoints disponibles |
| OAuth grant | Autorizar a una aplicación de terceros | Si se compromete, permite abrir una ruta de acceso persistente que podría culminar en un ataque de cadena de suministro |
El punto clave es el siguiente: el MFA robustece la autenticación, pero no siempre protege el uso posterior de los elementos emitidos después del acceso.
Por ello, una pregunta útil para evaluar el diseño de una aplicación no es solo:
¿La aplicación tiene MFA?
Sino también:
¿Qué puede hacer un adversario si obtiene una cookie, token, refresh token o API key válida?
Robo de Cookies de sesión: el acceso que el navegador guarda por nosotros
Las cookies de sesión son una de las formas más comunes de mantener autenticado a un usuario en una aplicación web. Una vez que el usuario inicia sesión, el servidor envía una cookie al navegador. En solicitudes posteriores, el navegador la incluye automáticamente en las cabeceras de la petición web para que el servidor reconozca la sesión como válida.
Desde la perspectiva del usuario, esto es transparente. Desde la perspectiva del servidor, la cookie representa una sesión ya autenticada.
El problema es que muchas aplicaciones no validan suficiente contexto alrededor de esa cookie. Si un usuario malintencionado logra obtenerla, puede intentar reutilizarla desde otro navegador, otro equipo o incluso otra región.
Los ataques de este tipo suelen verse de la siguiente manera:
Lección de diseño
El MFA protege al usuario en caso de robo de usuario y contraseña, sin embargo, el sistema confía en el elemento de autenticación generado posterior al acceso, es decir, el segundo factor ya fue otorgado por la víctima. El adversario no necesita repetirlo si la aplicación acepta la cookie como prueba suficiente de autenticación.
Ante este escenario, OWASP plantea cuatro elementos cruciales para mitigar este fallo:
- Notificaciones al usuario: Notificar a los usuarios después de cada inicio de sesión exitoso para que estén al tanto de las sesiones activas.
- Página de administración de sesiones: Crear una página dedicada para mostrar y permitir la finalización de las sesiones activas, lo que brinda un mayor control al usuario.
- Seguimiento de direcciones IP: Rastrear las direcciones IP de los usuarios que inician sesión en una cuenta y detecte cualquier actividad sospechosa, como múltiples inicios de sesión desde diferentes ubicaciones.
- Restricciones de direcciones IP: Permitir que los usuarios especifiquen direcciones IP o rangos de direcciones IP de confianza desde los cuales pueden acceder a sus cuentas, lo que mejora la seguridad al restringir las sesiones a ubicaciones conocidas y aprobadas.
Infostealers: cuando el navegador se convierte en el objetivo
Otra forma común de obtener API Keys, cookies y tokens es mediante malware de tipo infostealer. A diferencia de otras amenazas, este código malicioso no necesariamente busca cifrar archivos o actuar como una puerta trasera, su objetivo es recolectar información valiosa del equipo comprometido.
Entre los datos que puede intentar obtener se encuentran:
- Cookies de sesión
- Tokens almacenados localmente
- Contraseñas guardadas
- Historial de navegación
- Información de billeteras digitales
- Archivos de configuración
- Variables de entorno
- Credenciales de herramientas de desarrollo
Este tipo de malware es especialmente peligroso en estaciones de trabajo de desarrolladores, administradores de sistemas, equipos de soporte y usuarios con acceso a múltiples aplicaciones SaaS, debido a la cantidad de accesos que se encuentran almacenados en esos dispositivos.
Los ataques de este tipo suelen verse de la siguiente manera:
Lección de diseño
Muchas sesiones activas viven en el navegador. Si el usuario ya inició sesión en el correo, tenants o consolas cloud, repositorios, aplicaciones internas y herramientas de colaboración, el equipo se convierte en una concentración de múltiples accesos.
Por esta razón, proteger la identidad ya no significa únicamente centrarnos en proteger el método de autenticación. También implica proteger el dispositivo del usuario, el navegador, las extensiones, integraciones y el software instalado, además de contar con un proveedor de gestión de identidades.
Ataques AiTM: cuando el atacante se coloca en medio del inicio de sesión
Otra técnica relevante relacionada con este problema es el ataque Adversary-in-the-Middle, o AiTM. A diferencia del phishing tradicional, que intenta engañar al usuario con una página falsa, este tipo de ataque puede funcionar como un intermediario o proxy entre la víctima y el sitio legítimo.
El usuario cree estar interactuando con el servicio real, ingresa sus credenciales y completa el MFA. Por su parte, el servicio legítimo valida la autenticación y emite la sesión. Al estar el adversario en medio del flujo, puede capturar cookies o tokens emitidos durante el proceso.
El resultado es preocupante: el usuario observa un login exitoso y el adversario ya obtuvo los elementos necesarios para también tener una sesión autenticada.
Este modelo ha sido utilizado por campañas de phishing como servicio en años recientes, donde los atacantes no necesitan desarrollar toda la infraestructura desde cero, sino solamente interceptar la solicitud de autenticación. En otras palabras, en lugar de robar solamente contraseñas, el objetivo es capturar sesiones válidas.
Los ataques de tipo AiTM suelen verse de esta forma:
Lección de diseño
El MFA basado en códigos, notificaciones push o aprobaciones simples pueden ser insuficientes frente a ataques que interceptan el flujo de autenticación. En estos casos, los controles resistentes a phishing, como FIDO2 o passkeys con validación de origen, ofrecen una mejor defensa porque la autenticación se liga criptográficamente al dominio legítimo.
Abuso de OAuth: cuando la confianza delegada se convierte en superficie de ataque
OAuth permite que una aplicación acceda a recursos en nombre del usuario sin compartir la contraseña. Es una pieza clave para la integración moderna entre plataformas: correo, almacenamiento en la nube, calendarios, repositorios de código, herramientas de CI/CD y aplicaciones SaaS.
Las fallas de seguridad de OAuth no radican en su arquitectura, sino en su uso sin gobierno adecuado.
Cuando un usuario autoriza una aplicación OAuth, puede otorgarle permisos como:
- Leer correo
- Leer o modificar archivos
- Acceder a repositorios
- Consultar información de perfil
- Mantener acceso sin interacción del usuario mediante refresh tokens
Si una aplicación OAuth autorizada es comprometida o si el usuario otorga acceso a una aplicación maliciosa, el adversario puede obtener acceso persistente sin necesidad de adquirir la contraseña del usuario.
En ambientes corporativos, muchas aplicaciones SaaS se conectan entre sí mediante OAuth, lo que permite que un proveedor/tercero tenga acceso a distintos servicios como Google Workspace, Microsoft 365, GitHub, Slack, Jira, Vercel, entre otras, así como a herramientas internas, esto genera una cadena de confianza. Si uno de los eslabones se compromete, el impacto puede propagarse (o convertirse en ataque de cadena de suministro) hacia plataformas que no fueron atacadas directamente, algo que se ha observado en ataques recientes.
El riesgo se agrava cuando las organizaciones no tienen inventario de:
- Aplicaciones OAuth autorizadas
- Usuarios que otorgaron permisos
- Scopes concedidos
- Fecha de autorización
- Uso reciente de tokens
- Aplicaciones sin dueño claro
- Integraciones que ya no se utilizan
Lección de diseño
Una aplicación OAuth usada en la organización no debe verse como una simple preferencia del usuario. Debe tratarse como un proveedor con acceso a datos corporativos. Esto implica revisión, aprobación, monitoreo, expiración y revocación periódica.
Adicionalmente, se debe tener en cuenta que una autorización a una aplicación de un tercero comprometido, siempre podrá ser un vector de entrada a su organización.
Device Code Flow: un flujo legítimo con abuso posible
OAuth también contempla flujos diseñados para dispositivos con capacidades limitadas de entrada, como televisores, consolas, impresoras o dispositivos sin teclado. Uno de ellos es Device Code Flow.
El flujo legítimo funciona así:
El problema aparece cuando el dispositivo que inició el flujo no es del usuario, sino del adversario. En ese escenario, la víctima puede ingresar un código de un adversario en una página legítima del proveedor de identidad, completar MFA y aprobar, sin darse cuenta de que otorgó una sesión válida al actor malintencionado.
Esta técnica es especialmente peligrosa porque el usuario puede ver un dominio legítimo en el navegador. Como resultado, la víctima no necesariamente está escribiendo su contraseña en una página falsa, está completando un flujo real pero iniciado con intención maliciosa; tal y como se ha observado en campañas recientes como la de EvilTokens analizadas por el Scitum Innovation Center.
Lección de diseño
Los flujos que generan códigos de acceso único deben restringirse. Cuando se requieran, deben estar sujetos a acceso condicional, monitoreo y revocación después de su uso. El usuario debe entender que ingresar un código de dispositivo no solicitado puede equivaler a autorizar una sesión de un tercero.
API keys: el acceso usado por dispositivos que no requiere MFA
Las API keys son comunes en integraciones, automatizaciones, scripts, agentes, pipelines y aplicaciones backend. Su ventaja es que son simples de usar, su desventaja es que quien conoce el API tiene el acceso.
Cabe resaltar que una API key generalmente no requiere de MFA, por lo que, si se filtra en un repositorio, archivo de configuración, variable de entorno, log, extensión de navegador o herramienta de desarrollo, el adversario puede reutilizar el API directamente sobre los endpoints.
Entre los fallos de seguridad más comunes se encuentran:
- Claves declaradas explícitamente (hardcodeadas) en código fuente
- Claves publicadas por accidente en repositorios
- Claves en frontend o aplicaciones móviles
- Variables de entorno visibles para más usuarios de los necesarios
- Claves sin rotación
- Claves con permisos excesivos
- Ausencia de monitoreo por uso o comportamiento anómalo
- Falta de separación entre desarrollo, pruebas y producción
Una API key con permisos amplios puede convertirse en una llave maestra. Por ejemplo, una clave para consultar datos puede no parecer crítica, pero, si también permite escritura, eliminación o administración, el impacto cambia completamente.
Lección de diseño
Las API keys deben tratarse como secretos de alto valor. No deben ser permanentes por defecto, no deben tener permisos globales y no deben almacenarse en lugares donde múltiples usuarios, herramientas, malware o procesos puedan leerlas sin control.
Adicionalmente, el principio de mínimo privilegio debe aplicarse también a identidades de dispositivo.
Recomendaciones
No existe un único control que resuelva todos estos escenarios. La defensa debe combinar la protección dirigida a personas, procesos y tecnología. A continuación, se presentan recomendaciones enfocadas en dichos aspectos.
Enfocadas en tecnología
- MFA resistente a phishing
Cuando sea posible, y en aplicativos altamente críticos, priorizar FIDO2, llaves de seguridad o passkeys. Estos métodos validan el origen de la autenticación y reducen el riesgo de ataques AiTM frente a elementos como SMS, OTP o aprobaciones push simples.
- Acceso condicional y evaluación continua
Las sesiones deben evaluarse con señales adicionales, por ejemplo:
- Dispositivo administrado
- Cumplimiento de postura de seguridad
- Ubicación
- ASN o red de origen
- Riesgo del usuario
- Riesgo de inicio de sesión
- Cambios de User-Agent
- Uso desde países o regiones atípicas
- Eventos de impossible travel
Cuando el contexto cambie, la sesión debe forzar la re-autenticación o ser revocada.
- Reducción de vida útil de tokens
Los access tokens deben ser de corta duración. Los refresh tokens deben tener políticas de expiración, rotación, revocación y detección de reutilización.
Un token de larga vida equivale a una ventana de ataque más amplia.
- Protección de cookies
Las aplicaciones deben usar atributos y controles como:
- Secure
- HttpOnly
- SameSite
- Prefijos seguros cuando aplique
- Expiración por inactividad
- Expiración absoluta
- Regeneración de sesión después de cambios de privilegio
- Reautenticación para operaciones sensibles
- Detección de cambios bruscos en IP, dispositivo o User-Agent
Estos controles no eliminan todos los riesgos, pero reducen el impacto de ataques comunes.
- Tokens ligados al dispositivo o al cliente
Cuando la plataforma lo soporte, evaluar mecanismos como:
- Tokens sender-constrained
- Demonstrating Proof-of-Possession (DPoP)
- TLS mutuo (mTLS)
- Device-bound sessions/credentials (DBSC)
- Certificados de cliente
- Controles de sesión ligados a hardware
La idea es reducir la portabilidad del token. Un token robado debería ser inútil fuera del contexto donde fue emitido.
- Gobierno de OAuth
Las organizaciones deben mantener control sobre:
- Aplicaciones OAuth autorizadas
- Scopes permitidos
- Concientización a usuarios
- Definición de aplicaciones de alto riesgo
- Permisos offline_access
- Aplicaciones con autorización sin uso o no utilizadas recientemente
- Integraciones de terceros
- Dueños internos de cada integración
También es recomendable bloquear el consentimiento de usuario para permisos de alto impacto y requerir aprobación administrativa, en aplicaciones de alto riesgo como Office 365.
- Restricción de Device Code Flow
Si la organización no necesita Device Code Flow, debe bloquearlo. Si lo necesita, debe limitarlo a usuarios, grupos, aplicaciones o dispositivos específicos.
También deben existir alertas para autenticaciones por este flujo cuando no correspondan al perfil normal del usuario.
Algunos indicios que pueden ayudar a identificar abuso de Device Code Flow son:
- Autenticaciones por flujo de dispositivo en usuarios que no suelen usar ese tipo de dispositivos
- Solicitudes de código posteriores a clics en correos externos
- Tokens emitidos a aplicaciones no permitidas
- Accesos posteriores desde infraestructura inusual (uso de geolocalización)
- Incremento repentino de operaciones vía API, por ejemplo, lectura de correo o archivos
- Gestión segura de API keys
Las API keys deben almacenarse en bóvedas de secretos, no en código fuente ni archivos locales. Además, deben tener:
- Alcance mínimo
- Separación por ambiente
- Rotación periódica
- Expiración
- Monitoreo de uso
- Restricción por IP, cuando sea posible
- Alertas por uso anómalo
- Revocación rápida
Cuando sea viable, se recomienda reemplazar API keys estáticas por identidades de workload, credenciales federadas u OAuth/OIDC/SAML con tokens de corta duración.
- Seguridad del dispositivo y navegador
El dispositivo debe verse como parte del plano de identidad. Controles relevantes:
- EDR con detección de infostealers
- Bloqueo de ejecución desde ubicaciones temporales
- Restricción de PowerShell no autorizado
- Control de dispositivos USB
- Gestión de privilegios locales
- Navegadores actualizados
- Control de extensiones
- Separación de perfiles personales y corporativos
- Monitoreo de intentos de acceso a almacenes de cookies o credenciales
- Detección orientada a tokens
Muchas organizaciones investigan compromisos como si todo iniciara con contraseña. En ataques modernos, esto puede ser insuficiente.
Algunas señales para monitorear:
- Uso de refresh token desde ubicación nueva
- Token usado desde dispositivo no administrado
- Consentimiento OAuth inusual
- Lectura masiva de correo o archivos vía API
- Creación de reglas de buzón posteriores a login sospechoso
- Enumeración masiva de variables de entorno
- Uso de API key desde IP o región no habitual
- Incremento repentino de errores y éxitos en endpoints sensibles
- Acceso a repositorios o secretos fuera del horario normal
Enfocadas en procesos
Inventario de sesiones, tokens y aplicaciones
No se puede proteger lo que no se conoce. Las organizaciones deben mantener inventarios de:
- Aplicaciones conectadas por OAuth
- API keys activas
- Secretos en CI/CD
- Tokens de bots
- Cuentas de servicio
- Integraciones entre SaaS
- Usuarios con permisos para crear o autorizar aplicaciones
- Lugares donde se almacenan variables de entorno
Playbooks de respuesta a incidentes
Ante sospecha de robo de sesión, no basta con cambiar la contraseña. El playbook debe considerar:
- Revocar sesiones activas
- Revocar refresh tokens
- Eliminar consentimientos OAuth sospechosos
- Rotar API keys
- Rotar secretos de CI/CD
- Revisar reglas de correo
- Revisar aplicaciones conectadas
- Buscar accesos vía API
- Revisar repositorios y variables de entorno
- Hacer triage del dispositivo del usuario
- Validar persistencia en SaaS
Revisión periódica de permisos
Los permisos concedidos tienden a crecer con el tiempo. Por ello, se recomienda una revisión periódica de:
- Scopes OAuth
- Aplicaciones sin uso
- API keys sin dueño
- Secretos antiguos
- Cuentas de servicio con privilegios excesivos
- Integraciones de proveedores que ya no son necesarias
Gestión de proveedores
Un proveedor con acceso OAuth o API a datos corporativos debe evaluarse como un tercero con acceso privilegiado. Esto incluye controles de seguridad, notificación de incidentes, rotación de credenciales, límites de acceso y revisión contractual.
Enfocadas en personas
Concientización más allá de la contraseña
Durante años, la capacitación se centró en “no compartas tu contraseña”. Hoy ese mensaje es insuficiente.
Los usuarios también deben saber que:
- Ingresar un código de dispositivo no solicitado puede autorizar acceso a un adversario
- Una aprobación MFA inesperada debe reportarse
- Una aplicación que pide permisos excesivos puede ser riesgosa
- Las extensiones del navegador pueden representar riesgo
- Un Wi-Fi abierto o portal cautivo puede formar parte de un ataque
- Descargar herramientas no verificadas puede comprometer sesiones existentes
- Un token o API key debe protegerse como una contraseña
La concientización debe incluir ejemplos de ataques modernos, no solo phishing tradicional.
Preguntas dirigidas a los CISO para evaluar el nivel de exposición en la organización
A continuación, algunas preguntas que pueden ayudar a identificar riesgos:
- ¿Sabemos qué aplicaciones OAuth 2.0 tienen acceso a nuestros datos?
- ¿Los usuarios pueden autorizar aplicaciones sin revisión?
- ¿Tenemos Device Code Flow habilitado, aunque no lo usemos?
- ¿Podemos revocar sesiones y refresh tokens rápidamente?
- ¿Sabemos dónde están almacenadas nuestras API keys?
- ¿Las API keys tienen dueño, alcance y fecha de expiración?
- ¿Detectamos uso de tokens desde ubicaciones inusuales?
- ¿Tenemos alertas por lectura masiva vía API?
- ¿Revisamos extensiones de navegador en equipos corporativos?
- ¿El dispositivo forma parte de nuestra estrategia de protección de identidad?
- ¿Las variables de entorno sensibles están protegidas por defecto?
- ¿Los proveedores con acceso OAuth son evaluados como terceros críticos?
Si la respuesta a varias de estas preguntas es “no”, probablemente existe una brecha entre la estrategia de identidad y la realidad operativa.
Lecciones aprendidas
Los ataques recientes donde observamos las técnicas mencionadas en este artículo dejan varias lecciones aprendidas importantes:
- El MFA sigue siendo necesario, pero no es suficiente
- Una sesión autenticada puede ser más valiosa que una contraseña
- OAuth debe gobernarse como una relación de confianza con terceros
- Las API keys son identidades de máquina y deben gestionarse como secretos críticos
- El navegador es parte de la superficie de ataque
- El endpoint es parte del plano de identidad
- Cambiar contraseñas no resuelve un compromiso si los tokens siguen activos
- La detección debe enfocarse en comportamiento, no solo en eventos de login
- Las sesiones deben validarse de forma continua
- La seguridad por defecto importa: si un secreto requiere marcarse manualmente como sensible, eventualmente alguien no lo hará
Conclusión
Durante mucho tiempo se asumió que proteger el login era suficiente. Usuario, contraseña y MFA parecían cerrar la puerta principal. Sin embargo, las aplicaciones modernas funcionan con sesiones, tokens, integraciones, API keys y secretos distribuidos en múltiples plataformas.
Los adversarios lo entendieron, por eso muchos ataques actuales ya no intentan adivinar contraseñas. Buscan cookies, tokens OAuth, refresh tokens, consentimientos abusivos y API keys expuestas. En otras palabras, buscan las llaves que se generan después de que la autenticación ya ocurrió.
La solución no es abandonar el MFA, sino complementarlo con una estrategia más amplia: MFA resistente a phishing, sesiones menos portables, tokens de corta vida, gobierno de OAuth, protección integral de dispositivos, administración segura de secretos, monitoreo continuo y respuesta a incidentes orientada a revocación de accesos.
En ciberseguridad, una sesión válida puede ser tan poderosa como una contraseña, aunado a esto, el abuso de tokens es letal porque, desde la perspectiva de los logs tradicionales del IdP, el tráfico del atacante se ve exactamente igual al tráfico legítimo. Por ello, las organizaciones deben dejar de proteger solamente el momento del login y comenzar a proteger todo el ciclo de vida de la identidad.