Tema 17
Los sistemas de identidad y acceso están expuestos a ataques que no siempre rompen algoritmos ni explotan fallas sofisticadas. Muchas veces aprovechan credenciales reutilizadas, errores de validación, hábitos inseguros de los usuarios, debilidades en la gestión de sesiones o controles defensivos mal ubicados. Conocer estas amenazas es esencial para diseñar controles realistas y no confiar demasiado en una sola capa de protección.
En identidad y acceso, el atacante no siempre necesita vulnerar la infraestructura completa. A veces le alcanza con conseguir una contraseña reutilizada, engañar a un usuario para que apruebe una solicitud MFA, robar una cookie de sesión o explotar una validación incompleta de tokens. Esto vuelve especialmente peligroso al dominio IAM: pequeños errores pueden traducirse en acceso legítimo desde la perspectiva del sistema.
Por eso la defensa no debe construirse sobre una única barrera. Contraseñas, MFA, protección de sesiones, monitoreo, revocación, autorización robusta y trazabilidad deben funcionar en conjunto. Cuando una de esas capas falla, las otras deberían reducir el impacto.
Una forma útil de analizar estas amenazas es preguntarse qué intenta capturar o falsificar el atacante. En general busca una de estas cosas:
Eso significa que el problema no se limita al momento del login. También alcanza a sesiones activas, APIs, flujos de soporte, aprovisionamiento y administración.
El credential stuffing consiste en probar, de forma automatizada, combinaciones de usuario y contraseña obtenidas de brechas previas en otros servicios. El atacante no adivina una contraseña nueva; explota la costumbre de reutilizar credenciales.
Este ataque es muy efectivo porque muchas organizaciones todavía asumen que una contraseña correcta es una señal fuerte de autenticidad. Si el usuario repite su clave entre servicios, una fuga ajena puede convertirse en una intrusión local.
El problema se agrava cuando no existen detección de comportamiento anómalo, MFA efectivo o controles de velocidad adecuados.
La defensa útil aquí no es una sola regla de complejidad, sino una combinación de higiene de credenciales, detección y segundo factor.
El brute force clásico intenta muchas contraseñas contra una misma cuenta. El password spraying, en cambio, prueba pocas contraseñas comunes contra muchas cuentas para evitar bloqueos por usuario. Ambos buscan explotar contraseñas débiles o configuraciones de rate limiting insuficientes.
El password spraying suele ser especialmente peligroso en entornos empresariales porque ataca a escala y puede pasar desapercibido si el monitoreo solo mira fallos repetidos por cuenta individual.
Defenderse bien implica equilibrio. Si el sistema bloquea agresivamente ante pocos errores, un atacante puede usar ese comportamiento para provocar denegación de servicio. Si no limita nada, la superficie queda abierta a automatización.
Algunas prácticas útiles son:
El phishing busca engañar al usuario para que entregue credenciales, códigos o aprobaciones. Desde la perspectiva del atacante, es más barato convencer a una persona que vulnerar una plataforma bien protegida.
Su peligro radica en que convierte acciones legítimas del usuario en acceso para el atacante. La víctima puede escribir su contraseña en un sitio falso, entregar un código OTP o aprobar una notificación push creyendo que responde a una acción válida.
Agregar MFA mejora mucho la defensa, pero no toda MFA ofrece la misma resistencia. Los códigos por SMS, aplicaciones OTP o notificaciones push pueden seguir siendo vulnerables a ataques de intermediación, engaño o fatiga de aprobaciones.
Por eso es importante distinguir entre “tener MFA” y “tener MFA resistente a phishing”. Tecnologías como FIDO2 o WebAuthn aportan defensas más fuertes porque vinculan la autenticación al origen legítimo y reducen la reutilización por sitios falsos.
Un patrón cada vez más visto consiste en bombardear al usuario con solicitudes de aprobación hasta que, por cansancio o confusión, acepta una. Esta técnica, conocida como MFA fatigue, muestra que el segundo factor también puede ser socialmente explotable.
El problema no es solo tecnológico. También influye el diseño de experiencia: mensajes ambiguos, notificaciones sin contexto y procesos que acostumbran al usuario a aprobar mecánicamente aumentan el riesgo.
El session hijacking ocurre cuando un atacante obtiene control de una sesión ya autenticada. En vez de robar la contraseña, roba o reutiliza el identificador de sesión, una cookie o un token vigente.
Esto puede suceder por múltiples vías: malware, exposición en el navegador, tráfico inseguro, robo desde un equipo comprometido o vulnerabilidades como XSS que permiten acceder a artefactos de sesión.
El impacto es alto porque, desde la lógica del sistema, la sesión parece legítima. Si además la autorización depende solo de esa sesión sin verificaciones adicionales, el atacante puede operar como el usuario real.
En la session fixation, el atacante fuerza o induce al usuario a autenticarse sobre un identificador de sesión ya conocido por él. Si el sistema no renueva la sesión después del login, el atacante puede reutilizar ese mismo identificador para acceder.
Este caso muestra por qué no basta con “tener sesiones”. Importa cómo se crean, cómo se renuevan y en qué momentos cambian de valor. El login, la elevación de privilegios y ciertos cambios de contexto deberían disparar rotaciones apropiadas.
Los flujos de recuperación de cuenta suelen ser un objetivo preferido porque ofrecen una ruta alternativa cuando el login principal está mejor protegido. Si las preguntas de seguridad son débiles, si el soporte puede ser manipulado o si los enlaces de recuperación no están bien protegidos, el atacante evita directamente la autenticación normal.
Un principio útil es tratar la recuperación como una forma sensible de autenticación. Si el proceso para recuperar una cuenta es más débil que el proceso para accederla, la seguridad real cae al nivel más bajo de ambos.
En entornos API, los ataques pueden dirigirse a tokens mal validados, scopes excesivos, secretos embebidos en clientes inseguros o falta de revocación efectiva. A veces el token es técnicamente válido, pero fue emitido para otra audiencia, está siendo usado fuera de contexto o contiene claims mal interpretados.
También es común que APIs internas confíen demasiado en la red o en un gateway y relajen validaciones propias. Eso crea un riesgo importante cuando un componente intermedio falla o cuando una ruta lateral permite llegar a la API sin pasar por el control esperado.
No todos los incidentes de identidad comienzan con una cuenta privilegiada. Muchas veces el atacante compromete una identidad común y luego avanza buscando permisos acumulados, relaciones de confianza débiles o caminos de escalamiento. Esto se conoce como movimiento lateral.
Por eso el principio de mínimo privilegio, la segregación de funciones, la revisión periódica de accesos y la protección especial de cuentas administrativas son controles esenciales. Una cuenta aparentemente menor puede convertirse en la puerta hacia activos críticos si el entorno está sobredimensionado en permisos.
| Ataque | Qué explota | Controles clave |
|---|---|---|
| Credential stuffing | Reutilización de credenciales filtradas | MFA, detección de credenciales expuestas, rate limiting y monitoreo |
| Brute force / spraying | Contraseñas débiles y falta de límites | Fricción adaptativa, bloqueo razonable, detección distribuida |
| Phishing | Engaño al usuario y robo de credenciales o aprobaciones | MFA resistente a phishing, diseño claro y educación operativa |
| Secuestro de sesión | Robo o reutilización de sesiones válidas | Protección de cookies, expiración, rotación y monitoreo contextual |
Estos errores son peligrosos porque generan una falsa sensación de madurez. El sistema parece “tener controles”, pero esos controles no necesariamente frenan los caminos de ataque más probables.
Los ataques más comunes en identidad y acceso no desaparecen por incorporar una tecnología puntual. Cambian de forma, se adaptan a los controles y aprovechan el punto más débil del conjunto: una contraseña repetida, un usuario engañado, una sesión expuesta o una autorización incompleta. Por eso el enfoque correcto no es buscar una defensa mágica, sino construir resiliencia por capas y revisar continuamente dónde podría romperse la cadena de confianza.
En el próximo tema nos concentraremos en observabilidad, auditoría y trazabilidad, que son claves para detectar estos eventos, investigarlos y demostrar control sobre el sistema de identidad.