Capacidad

Protección contra Account Takeover

Detenga los intentos de credential stuffing, fuerza bruta, low-and-slow y secuestro de sesión basándose en una decisión de riesgo combinada — no en una sola señal.

TR7 Account Takeover Protection no reduce la defensa ATO a una regla de 'bloquear la cuenta después de 5 intentos fallidos'. La puntuación de bot, la velocidad de auth fallida, la reputación de IP, las señales de tráfico conductual, la discrepancia de session binding, el CAPTCHA y el flujo de step-up MFA de AAM se evalúan todos juntos. Diferentes clases de ataques se detectan mediante diferentes señales. La fuerza bruta clásica desde una sola IP se cubre mediante el alcance IP; el credential stuffing distribuido a través de muchas IPs se cubre mediante el alcance de nombre de usuario; los intentos dirigidos enfocados en un usuario específico se cubren mediante el alcance username_ip o compuesto; los intentos de secuestro de sesión posterior al login se hacen visibles a través de anomalías de session binding. El modelo de protección no es de una sola etapa. Primero una advertencia produce un registro de auditoría, luego el CAPTCHA alojado en el servidor agrega fricción y finalmente se activa el bloqueo o la cuarentena. La capacidad de intento del atacante se reduce gradualmente sin penalizar innecesariamente a los usuarios legítimos. El resultado: TR7 WAAP y AAM trabajando juntos forman una capa de defensa integrada que aborda los intentos de account takeover en el contexto de identidad, comportamiento del tráfico, consistencia de sesión y política de acceso.

4
Capas de riesgo: puntuación de bot, velocidad de auth fallida, reputación de IP, session binding
3
Niveles de escalada gradual: advertencia → CAPTCHA → bloqueo
24h
Ventana de decaimiento predeterminada — los usuarios legítimos reanudan limpiamente

Los ataques de account takeover no son uniformes — no pueden detectarse con una sola señal.

La fuerza bruta clásica realiza muchos intentos de contraseña en poco tiempo desde una sola IP. El credential stuffing prueba la misma lista de contraseñas distribuida en muchas IPs. Los ataques low-and-slow realizan un pequeño número de intentos durante horas. Los intentos de secuestro de sesión se revelan después de un login exitoso a través de cambios en IP, user agent o comportamiento. Detectar todos estos con la misma regla de rate-limit no es realista.

Usar solo el bloqueo basado en IP permite que el credential stuffing distribuido se escape y afecta injustamente a los usuarios legítimos en redes compartidas. Usar solo el bloqueo basado en usuario permite que los atacantes desencadenen intencionalmente el bloqueo de cuenta como un denial of service. Usar solo CAPTCHA convierte cada intento de login en fricción innecesaria y degrada la experiencia del usuario.

Muchas soluciones solo miran el momento del login. Sin embargo, el riesgo de account takeover continúa después del login: si acciones sensibles como el cambio de contraseña, el cambio de email, la adición de método de pago, la generación de token de API o la transferencia de fondos llegan en un nuevo contexto, esta es una señal de abuso posterior al login. Este comportamiento debe evaluarse junto con el session binding y el step-up MFA.

El enfoque correcto es usar la combinación de alcance y señal apropiada para cada clase de ataque. Los alcances IP, nombre de usuario, username_ip y compuesto deben trabajar juntos con la puntuación de bot, la velocidad de auth fallida, la reputación de IP y la discrepancia de session binding.

TR7 Account Takeover Protection entrega este modelo: combina las señales de tráfico WAAP con las políticas de acceso AAM y gestiona el riesgo ATO a través de un gráfico de políticas multicapa en lugar de una sola regla.

Nuestro enfoque

TR7 aplica la defensa ATO mediante scoring multi-señal, selección de alcance específica por clase de ataque, escalada gradual y coordinación con AAM.

El modelo de decisión multi-señal combina cuatro capas de riesgo distintas

La puntuación de bot, la velocidad de auth fallida, la reputación de IP y la discrepancia de session binding se evalúan todas en el mismo camino de decisión. Las decisiones se toman en función de la forma conductual real del ataque — no únicamente sobre la IP o únicamente sobre el nombre de usuario.

El alcance de la política se selecciona para coincidir con la clase de ataque

El alcance IP rastrea los intentos de fuerza bruta de fuente única, el alcance de nombre de usuario rastrea el credential stuffing distribuido, el alcance username_ip rastrea los ataques dirigidos, y el alcance compuesto rastrea combinaciones de IP, user agent y cabeceras. Cada alcance opera con sus propios contadores y comportamiento de umbral.

La advertencia, el CAPTCHA y el bloqueo crean fricción gradual

En la primera etapa el evento se escribe en el registro de auditoría, luego se activa el CAPTCHA alojado en el servidor y finalmente se aplica el bloqueo. Este modelo frena al atacante mientras minimiza la fricción innecesaria para los usuarios legítimos.

La coordinación con AAM vincula el flujo de step-up MFA y bloqueo

Las señales de tráfico WAAP pueden trabajar junto con las políticas de bloqueo y step-up MFA de AAM. Se puede activar una verificación adicional para los usuarios que se acercan al umbral de CAPTCHA o que exhiben un cambio de contexto de sesión.

Capacidades

Account Takeover Protection reúne el riesgo de tráfico previo al login, los fallos de login y el comportamiento de sesión posterior al login en la misma cadena de protección.

La escalada de tres niveles frena al atacante mientras protege a los usuarios legítimos

TR7 hace que la defensa ATO sea gradual mediante el flujo advertencia → CAPTCHA → bloqueo. La etapa de advertencia produce un registro de auditoría sin presentar fricción al usuario. La etapa CAPTCHA desafía la automatización y ofrece a los usuarios legítimos un paso de verificación controlado. La etapa de bloqueo detiene temporalmente la capacidad de intento para el alcance específico.

Los alcances IP, nombre de usuario, username_ip y compuesto pueden ejecutarse en paralelo

Los ataques ATO no pueden detectarse con un solo alcance. TR7 puede ejecutar políticas de alcance basadas en IP, en nombre de usuario, en IP+nombre de usuario y en alcance compuesto simultáneamente en el mismo endpoint. La fuerza bruta de IP única, el credential stuffing de múltiples IPs y los ataques de cuenta dirigidos se rastrean por separado. Incluso si un atacante se mantiene bajo un alcance, el otro alcance aún puede detectar el comportamiento.

La velocidad de auth fallida mide la tasa de fallos de login dentro de una ventana de tiempo

El disparador failedAuthAttempts cuenta los intentos fallidos dentro de una ventana de tiempo definida. Este contador puede rastrearse por usuario, por IP o por alcance compuesto. Las ventanas cortas exponen los intentos de fuerza bruta rápida; las ventanas largas revelan el comportamiento ATO low-and-slow. Tanto el conteo total como la densidad de intentos a lo largo del tiempo alimentan la decisión.

La puntuación de bot convierte el riesgo de automatización en la superficie de login en una señal

TR7 puede tener en cuenta el análisis de user agent, la reputación de IP, el análisis de comportamiento, la ruta sospechosa, la huella de cabecera, las anomalías de protocolo, la inconsistencia de señales, el nodo de salida Tor, la huella TLS y la IP de centro de datos al calcular la puntuación de bot. Cuando la puntuación alcanza un nivel definido, se puede activar una acción de CAPTCHA o bloqueo. Los intentos de login se evalúan no solo como errores de contraseña sino también como comportamiento de automatización, llevando la calidad del tráfico a la defensa ATO.

La reputación de IP marca las fuentes malas antes de que lleguen los ataques de credenciales

Las subcategorías de reputación de IP como proxy abierto, bot malicioso, ataque, reconocimiento, spam e IP VPN pueden usarse como señales de riesgo en las decisiones ATO. Estas categorías no tienen que producir bloqueo obligatorio por sí solas; se evalúan junto con la puntuación de bot y las políticas de bloqueo. Los intentos de login desde infraestructura conocidamente mala pueden someterse a fricción más temprana. Este enfoque trabaja en combinación con otras señales para reducir el riesgo de falsos positivos.

Las señales de tráfico conductual detectan el abuso en la superficie de login

El path hammering, las solicitudes rápidas, la alta tasa de 404, las solicitudes de mutación sin referrer y el uso inesperado de método HTTP pueden ser señales de riesgo en la superficie de login. Estos indicadores ayudan a distinguir el credential stuffing, la enumeración de cuentas y el comportamiento de escaneo automatizado. Las señales no se evalúan de forma aislada — trabajan junto con la puntuación de bot y los contadores de auth fallida. El ataque se hace visible no solo a partir de errores de contraseña sino también del comportamiento del tráfico.

El CAPTCHA alojado en el servidor reduce la dependencia en servicios de verificación de terceros

Cuando se supera el umbral de CAPTCHA, TR7 puede activar su propio flujo de desafío. Se presenta un desafío controlado al usuario sin enviar datos a un servicio de verificación externo. Las respuestas CAPTCHA incorrectas pueden añadirse al contador de intentos fallidos y acelerar la escalada. Esto proporciona un modelo más controlado para organizaciones con sensibilidad a la residencia de datos y cumplimiento regulatorio.

El step-up MFA de AAM fortalece las acciones de login y sesión de alto riesgo

TR7 puede coordinar las señales de bot y bloqueo de WAAP con las políticas de acceso de AAM. El step-up MFA puede activarse para usuarios que se acercan al umbral de CAPTCHA, que generan una anomalía de session binding o que realizan una acción sensible. Este enfoque lleva el riesgo del momento del login también a las operaciones posteriores al login. Incluso si el atacante conoce la contraseña correcta, aún se enfrenta a la barrera de verificación adicional.

La discrepancia de session binding hace visibles las señales ATO posteriores al login

Una sesión puede asociarse con IP, IP+user agent o un contexto compuesto. Si IP, user agent o contexto cambia inesperadamente después del login, puede generarse una anomalía de session binding. Esta señal es particularmente importante en escenarios de secuestro de sesión y reutilización de tokens. La reautenticación o controles adicionales pueden activarse en los endpoints sensibles.

La ventana de decaimiento evita que los errores pasados de un usuario legítimo se conviertan en una penalización permanente

attemptWindowDuration define cuánto tiempo los intentos fallidos siguen contándose. Si un usuario comete algunos errores de contraseña hoy, puede volver a un comportamiento limpio una vez que expire la ventana. Un atacante que acumula suficientes intentos dentro de la misma ventana se encuentra con CAPTCHA o bloqueo. Este modelo logra un equilibrio más saludable entre seguridad y experiencia del usuario.

El registro de auditoría apoya la investigación de incidentes con registros enmascarados

Para cada intento de login, se pueden registrar el timestamp, la IP fuente, el user agent, el alcance, el ID de política y el resultado. Los resultados como advertencia, CAPTCHA, bloqueo o paso exitoso se distinguen durante la revisión de incidentes. Los detalles del destinatario como el email o el número de teléfono se enmascaran para que el registro de auditoría no se convierta en un canal secundario de filtración de datos. Los equipos SOC rastrean los flujos de ataque usando registros estructurados.

La cuarentena coloca a los atacantes reincidentes bajo monitoreo extendido después del bloqueo

Si se define una acción de cuarentena después de que expire el período de bloqueo, el cliente o alcance puede colocarse bajo escrutinio adicional. Esto hace más difícil para los atacantes repetir los mismos intentos cada vez que termina la duración del bloqueo. La cuarentena proporciona rastreo de riesgo continuo más allá del comportamiento de bloqueo clásico y es una capa adicional útil en campañas ATO de larga duración.

Profundidad operativa

La protección ATO se opera junto con presets de política preparados, contadores nativos, curva de puntuación de bot, aislamiento de pool, alcance compuesto y compartición de contadores con AAM.

01

Presets de política preparados

TR7 puede proporcionar ejemplos de política de bloqueo preparados para los alcances de nombre de usuario, IP y username_ip. El alcance de nombre de usuario se enfoca en el credential stuffing con una ventana más larga; el alcance IP se enfoca en el comportamiento de fuerza bruta con una ventana más corta. Todos los umbrales, duraciones y acciones pueden ajustarse a las necesidades del servicio.

02

Contadores nativos de intentos fallidos

Los intentos de login fallidos se rastrean usando estructuras de contador rápidas. Este enfoque reduce la dependencia de llamadas a bases de datos externas y proporciona baja latencia en el camino de login. Replicar los contadores a los nodos pares en un entorno de clúster es importante para la continuidad de la protección después de un failover.

03

Curva de puntuación de bot

La puntuación de bot puede interpretarse como sensible en niveles de señal bajos y saturando a medida que se acumula alto riesgo. Este enfoque permite que muchas señales pequeñas se combinen en un riesgo significativo. Cuando se agrega una nueva señal, se reduce la necesidad de rediseñar el umbral de política completo desde cero.

04

Aislamiento basado en pool

Cada pool puede vincularse a su propio perfil de protección del tráfico. Una señal ATO en un tenant o servicio no afecta los contadores de otro tenant. Este aislamiento es crítico en escenarios SaaS y MSP multi-tenant.

05

Comportamiento del alcance compuesto

El alcance compuesto puede combinar IP, user agent, accept-language o componentes de cabecera similares en una sola clave de rastreo. Este modelo proporciona un rastreo más contextual cuando IP o nombre de usuario solo no es suficiente. Ofrece visibilidad adicional contra user agents rotatorios o comportamiento de cliente variable.

06

Coordinación de contadores con AAM

Los contadores de auth fallida de WAAP pueden coordinarse con las políticas de bloqueo de AAM. Incluso si un atacante apunta directamente a diferentes endpoints de login, el mismo comportamiento de riesgo puede evaluarse en el contador compartido y la ruta de política. Esto hace que la protección ATO sea consistente no solo en la capa de tráfico sino también a lo largo del flujo de identidad.

Cuándo usarlo

Reducción de fuerza bruta en login bancario y API móvil

Los equipos bancarios pueden monitorear los endpoints de login con el alcance IP y el comportamiento de conexión SSL juntos. Cuando se superan los umbrales definidos, se activan CAPTCHA, bloqueo o step-up MFA de AAM.

Defensa contra credential stuffing distribuido en e-commerce

Los bots que realizan un pequeño número de intentos desde muchas IPs pueden no aparecer bajo el alcance IP. El alcance de nombre de usuario detecta los intentos fallidos que se acumulan en la misma cuenta y aplica CAPTCHA o bloqueo a nivel de cuenta.

Protección de cuentas de administrador objetivo en SaaS empresarial

Los intentos de bajo volumen pero enfocados contra una cuenta de CFO o administrador pueden rastrearse con el alcance username_ip o compuesto. Cuando el riesgo aumenta, se activa el step-up MFA a través de AAM.

Verificación de contexto de sesión en acciones sensibles posteriores al login

Si IP o user agent cambia inesperadamente inmediatamente después de que un usuario inicia sesión, puede generarse una anomalía de session binding. Se puede requerir reautenticación para acciones como transferencias de fondos, cambios de email o generación de tokens.

Preguntas frecuentes

¿Pueden detectarse el credential stuffing y la fuerza bruta clásica con la misma política?
Estos ataques requieren alcances diferentes. La fuerza bruta clásica proviene de una sola IP y se detecta mediante el contador de alcance IP. El credential stuffing se distribuye a través de miles de IPs; aquí el alcance de nombre de usuario rastrea los intentos fallidos que se acumulan en la misma cuenta. TR7 puede ejecutar ambas políticas en paralelo en el mismo endpoint, por lo que independientemente del alcance bajo el que se mantenga un atacante, el otro alcance detectará el comportamiento.
¿Cuándo se activa la discrepancia de session binding?
Después de un login exitoso, si la IP, el user agent o el contexto compuesto de la sesión cambia inesperadamente, puede generarse una anomalía de session binding. Esta señal es importante en escenarios de secuestro de sesión y reutilización de tokens. La reautenticación o el step-up MFA de AAM puede activarse en los endpoints sensibles.
¿El CAPTCHA alojado en el servidor envía datos a servicios externos?
No. La solución CAPTCHA alojada en el servidor de TR7 no envía datos a servicios de verificación externos. El flujo de desafío se maneja dentro de la plataforma. Este modelo ofrece una opción más controlada para organizaciones con requisitos de residencia de datos como GDPR u otras normativas de protección de datos locales.
¿Cómo trabajan juntos el step-up MFA de AAM y el bloqueo de WAAP?
Las señales de tráfico de WAAP y los contadores de auth fallida pueden coordinarse con las políticas de bloqueo de AAM. El step-up MFA puede activarse a través de AAM para usuarios que se acercan al umbral de CAPTCHA o que generan una anomalía de session binding. Incluso si el atacante conoce la contraseña correcta, aún se enfrenta a esta barrera de verificación adicional.
¿Qué sucede si un usuario legítimo queda bloqueado accidentalmente?
El modelo de tres niveles reduce este riesgo. La etapa de advertencia primero crea un registro de auditoría sin mostrar fricción al usuario. Luego CAPTCHA ofrece verificación controlada. El bloqueo solo se aplica en la etapa final. Además, la ventana de decaimiento attemptWindowDuration restablece los errores pasados después de un período definido, permitiendo que los usuarios legítimos regresen a un comportamiento limpio.
¿Cómo se detectan los ataques ATO low-and-slow?
Las políticas de ventana corta no pueden detectar los ataques low-and-slow. En TR7 el attemptWindowDuration predeterminado para el alcance de nombre de usuario es de 24 horas. Esto significa que incluso si un atacante realiza solo un pequeño número de intentos durante horas, los intentos fallidos acumulados durante el día activarán CAPTCHA o bloqueo una vez que se supere el umbral.

Deje el riesgo de account takeover a cuatro capas — no a una sola señal

Defensa ATO integrada contra credential stuffing, fuerza bruta, low-and-slow y secuestro de sesión. Recorramos una configuración en vivo en sus propios servicios.