Prevención de account takeover (ATO) y fraude en fintechs

Cómo ocurre el account takeover en fintechs

El account takeover (ATO) es el compromiso de una cuenta legítima por un tercero, que pasa a operar como si fuera el titular. En las fintechs, el impacto es directo: transferencias Pix no autorizadas, apertura de crédito fraudulento, cambio de datos de contacto para silenciar alertas y cash-out mediante cuentas mula. A diferencia de una intrusión en la infraestructura, el ATO frecuentemente no dispara los controles tradicionales porque usa credenciales válidas y flujos legítimos de la aplicación.

Los vectores predominantes son cuatro. El credential stuffing reutiliza pares de correo y contraseña filtrados en otros servicios, probados en masa contra la pantalla de login con automatización (catalogado por OWASP como OAT-008, Credential Stuffing, en el Automated Threat Handbook). El SIM swap transfiere la línea telefónica de la víctima a un chip controlado por el atacante, neutralizando cualquier segundo factor entregado por SMS o llamada. La ingeniería social, incluidas las estafas de falso funcionario y el phishing de OTP en tiempo real, induce a la propia víctima a entregar códigos o aprobar push notifications.

El cuarto vector es el phishing de credenciales con proxy inverso (kits como Evilginx), que intercepta usuario, contraseña y token MFA en la misma sesión, eludiendo el MFA basado en OTP. Es justamente ese escenario el que la NIST 800-63B clasifica como ataque de canal y que solo los autenticadores ligados criptográficamente al origen (phishing-resistant) logran bloquear.

El punto central para CTOs y equipos de riesgo: esos vectores se combinan. Una campaña real comienza con listas de credenciales filtradas, escala con automatización, escapa del MFA débil vía SIM swap o proxy inverso y termina con ingeniería social para aprobar la transacción final. Defender una capa aislada solo desplaza al atacante hacia la siguiente.

Señales de ATO: qué monitorear antes del perjuicio

El ATO deja rastros medibles antes del cash-out, y detectarlos temprano es lo que separa un incidente contenido de una pérdida materializada. Las señales útiles rara vez son una única regla binaria; son desviaciones del comportamiento histórico de cada cuenta y del conjunto de cuentas.

En la capa de autenticación, observa picos de intentos de login con baja tasa de éxito (firma del credential stuffing), logins exitosos desde ASNs de datacenter o redes de proxy residencial, viajes imposibles (login en Brasil y minutos después en otro país) y velocidad anómala de intentos por IP, por cuenta y por device. OWASP recomienda tratar esas métricas de forma agregada, no solo por IP, ya que las botnets distribuyen la carga.

En la capa de cuenta y transacción, las señales de post-compromiso son igualmente reveladoras: cambio de correo, teléfono o contraseña seguido de intento de transferencia; registro de nuevo dispositivo y Pix de alto valor hacia una clave nunca usada en la misma sesión; desactivación de notificaciones; y cambio de patrón de horario o de beneficiarios. Correlacionar el evento de cambio de credencial de contacto con la transacción subsecuente es uno de los detectores de fraude más eficaces en fintechs.

Transformar esas señales en acción exige telemetría centralizada y correlación continua. Los logs de autenticación, el device fingerprint, la geolocalización y los eventos transaccionales deben converger hacia un mismo pipeline de detección, donde reglas determinísticas y modelos de anomalía asignan riesgo en tiempo casi real. Sin esa consolidación, cada señal aislada se vuelve ruido.

MFA resistente a phishing: por qué passkeys y FIDO2

No todo MFA ofrece la misma protección contra el ATO. El OTP por SMS, el OTP por correo y la push notification simple aún dependen de un secreto o aprobación que puede ser interceptado, redirigido o extraído socialmente. La NIST 800-63B desalienta explícitamente el uso de SMS como canal restringido (out-of-band) por su vulnerabilidad a SIM swap e interceptación, y clasifica como phishing-resistant solo a los autenticadores que vinculan la autenticación al origen (channel binding).

Las passkeys, basadas en FIDO2/WebAuthn, cumplen ese requisito. La clave privada nunca deja el dispositivo del usuario, la autenticación se firma criptográficamente y se ata al dominio (origin), y no existe un secreto compartido que pueda ser phishado o reutilizado. Esto anula de una vez el credential stuffing, el phishing con proxy inverso y el SIM swap como caminos hacia el login. En términos de NIST 800-63B, los autenticadores criptográficos con verificador resistente a phishing son lo que viabiliza AAL2/AAL3 sin las debilidades del OTP.

Para un producto de fintech, la recomendación práctica es hacer de las passkeys el método primario y tratar el OTP por SMS solo como un fallback de recuperación con fricción y riesgo adicionales, jamás como segundo factor estándar para operaciones sensibles. La step-up authentication, exigiendo reautenticación con passkey antes de transferencias de alto valor, registro de beneficiario o cambio de datos de contacto, cierra la brecha entre autenticar la sesión y autorizar la acción crítica.

La migración no tiene que ser abrupta. Es viable habilitar passkeys en paralelo, incentivar el registro en el onboarding y en puntos de alto engagement, y reducir gradualmente la superficie de métodos débiles a medida que la adopción crece, midiendo siempre las tasas de registro y de éxito por cohorte.

Device fingerprinting, detección de fraude y respuesta

La autenticación fuerte no elimina la necesidad de evaluar el contexto de cada sesión. El device fingerprinting combina atributos de hardware, navegador y red para reconocer dispositivos conocidos y señalar los nuevos, dando peso a un login que ocurre desde un device nunca visto asociado a esa cuenta. Bien implementado, reduce la fricción para el usuario legítimo (que opera desde dispositivos familiares) y la concentra exactamente donde aparece el riesgo.

Sobre ese contexto opera el motor de detección de fraude: reglas determinísticas para patrones conocidos (viaje imposible, beneficiario nuevo de alto valor, velocidad anómala) sumadas a modelos de riesgo que puntúan el comportamiento agregado. La respuesta debe ser proporcional al score: liberar de forma transparente para bajo riesgo, exigir step-up con passkey para riesgo medio y bloquear o poner en revisión manual para riesgo alto. Ese escalonamiento preserva la experiencia sin renunciar a la contención.

La detección sin respuesta operacional es incompleta. Un plan de respuesta a ATO necesita runbooks claros: invalidar sesiones activas, forzar reautenticación, congelar transacciones pendientes, revertir cambios de datos de contacto, notificar al titular por un canal independiente y preservar evidencias para análisis forense y eventual reporte. En Brasil, ese proceso se conecta con las exigencias de seguridad cibernética y gestión de incidentes aplicables a instituciones reguladas por el Banco Central, incluido el ecosistema Pix, donde se esperan oportunidad y trazabilidad.

Operar esa cadena, telemetría, detección y respuesta, de forma continua exige una capacidad 24x7 que muchas fintechs en crecimiento aún no tienen internamente. Es en ese punto donde Decripte actúa como socia: SOC con monitoreo ininterrumpido, correlación de señales de ATO y fraude, y respuesta a incidentes con runbooks accionables, integrándose a los controles de autenticación y antifraude ya existentes en el producto.

Construyendo defensa en profundidad contra el ATO

Ningún control aislado resuelve el account takeover, porque cada vector ataca una capa diferente. La contraseña protege contra el acceso casual, pero cae en la filtración; el MFA fuerte protege el login, pero no la autorización de la transacción; el device fingerprinting contextualiza, pero no autentica. La fuerza está en la superposición: para tener éxito, el atacante necesitaría eludir varias capas independientes simultáneamente, lo que eleva drásticamente el costo del ataque.

En términos de OWASP, esto significa abordar las amenazas automatizadas (credential stuffing, account creation abuse) en el borde, las fallas de identificación y autenticación en el flujo de login (categoría del OWASP Top 10), y la lógica de negocio en la capa transaccional. Cada una exige controles propios, y el diseño debe asumir que cualquier capa puede fallar de forma aislada.

Una arquitectura madura encadena: higiene de credenciales (verificación contra bases de contraseñas filtradas, según NIST 800-63B), passkeys como autenticador primario resistente a phishing, device fingerprinting y análisis de riesgo por sesión, step-up authentication para acciones sensibles, monitoreo continuo con correlación de señales y un plan de respuesta probado. El resultado no es riesgo cero, sino riesgo gestionable y medible.

Para las fintechs que están estructurando o madurando esa postura, Decripte ofrece un plan gratuito para iniciar el monitoreo y evaluar la superficie de ATO, con un camino de evolución hacia SOC 24x7 y respuesta a incidentes a medida que la operación crece.

Checklist práctico

1. 1

   1. Mapea los vectores y la superficie de ATO

   Inventaría todos los flujos de autenticación, recuperación de cuenta, cambio de datos de contacto y autorización de transacción. Identifica dónde hay dependencia de SMS/OTP y dónde un cambio de credencial puede habilitar una transferencia en la misma sesión.

2. 2

   2. Bloquea el credential stuffing en el borde

   Verifica las contraseñas contra bases de filtraciones (NIST 800-63B), aplica rate limiting por cuenta, IP y device, e implementa detección de automatización siguiendo el OWASP Automated Threat Handbook (OAT-008).

3. 3

   3. Adopta MFA resistente a phishing

   Implementa passkeys/FIDO2 (WebAuthn) como autenticador primario apuntando a AAL2/AAL3. Degrada el OTP por SMS a fallback de recuperación con fricción, nunca como segundo factor estándar de operaciones sensibles.

4. 4

   4. Implanta device fingerprinting y score de riesgo

   Reconoce dispositivos conocidos, señala los nuevos y combina geolocalización, ASN y telemetría de comportamiento en un score de riesgo por sesión para calibrar la fricción de forma proporcional.

5. 5

   5. Exige step-up para acciones sensibles

   Fuerza reautenticación con passkey antes de transferencias de alto valor, registro de beneficiario y cambio de correo, teléfono o contraseña. Trata la autorización de la acción como un evento distinto de la autenticación de la sesión.

6. 6

   6. Centraliza la telemetría y monitorea 24x7

   Consolida los logs de autenticación, device, geolocalización y eventos transaccionales en un único pipeline de detección, con correlación continua de señales de ATO y cobertura ininterrumpida vía SOC.

7. 7

   7. Prepara y prueba el runbook de respuesta

   Documenta los pasos de contención (invalidar sesiones, congelar transacciones, revertir cambios de contacto, notificar por canal independiente, preservar evidencias) y ejercítalos, alineándolos a los requisitos de incidentes del Banco Central.

Preguntas frecuentes