AiTM y robo de sesión: qué protege el token de la app y qué no

Resumen: credencial, código y sesión no son lo mismo

La contraseña acredita conocimiento de un secreto; el código de un solo uso, u OTP, añade una comprobación. La cookie de sesión mantiene la continuidad del acceso después de autenticar. Confundir estas piezas lleva a diagnosticar como «fallo del token» lo que puede ser una intermediación del flujo o el uso indebido de una sesión.

La pregunta útil para banca y fintech no es si existe doble factor, sino qué propiedad aporta el método elegido y qué sucede después de autenticar. Esta nota sintetiza investigaciones de terceros. No presenta observaciones propias de intrusiones, un inventario completo de bancos afectados ni una medición de prevalencia regional.

Qué cambia cuando el phishing interviene en tiempo real

En el patrón de proxy inverso descrito por Sekoia, la página fraudulenta retransmite la autenticación al servicio legítimo y obtiene datos de acceso y cookies. Los más de 1.200 dominios son un conteo histórico del proveedor desde agosto de 2023, no dominios bancarios de LATAM ni necesariamente todos activos a la vez.

No es preciso decir que este ataque «no roba una contraseña»: puede capturar credenciales y, además, la sesión. Tampoco todo phishing interactivo demuestra que haya un proxy inverso. Un panel que solicita un segundo código con un operador presente describe una capacidad distinta, cuya implementación debe verificarse.

Para clasificar evidencia técnica, conviene consultar tanto T1557, Adversary-in-the-Middle como T1539, robo de cookies de sesión. Un identificador de ATT&CK no sustituye la descripción del comportamiento observado ni demuestra por sí solo cómo funcionó un incidente concreto.

Cronología documentada, no una medición actual del mercado

El comunicado de Microsoft del 4 de marzo de 2026 describe la incautación de 330 dominios activos de la infraestructura central de Tycoon 2FA. Es un resultado de aquella intervención, no un conteo de todas las infraestructuras de phishing.

El informe de Abnormal AI del 6 de mayo de 2026 documenta una reconstrucción posterior: una campaña identificada veinte días después de la intervención y comprobada activa el 2 de abril. Esta fuente sostiene la reaparición descrita, no la desaparición del efecto del operativo ni una cuota mundial del mercado.

La investigación de Sekoia sobre Sneaky 2FA distingue páginas observadas desde octubre de 2024, descubrimiento en diciembre y publicación en enero de 2025. El precio de 200 dólares mensuales corresponde a ese informe; no se ofrece aquí como precio actual. Su existencia tampoco prueba que sus ventas aumentaran debido al operativo de Tycoon.

Tres casos financieros y los límites de cada uno

Phoenix System. Group-IB describe un panel con intervención en vivo dentro de un análisis global de smishing que incluye LATAM. Esa mención regional no equivale a identificar por nombre un banco latinoamericano comprometido en el texto revisado.

ZeroTokens. Abnormal AI informa 53 marcas financieras configuradas en 14 localidades y una fuerte concentración de organizaciones asociadas a dominios .au. Plantilla, marca y destinatario no son sinónimos de cuenta comprometida. No se extrapola esa distribución a LATAM.

UNC6671. GTIG/Mandiant documenta vishing y AiTM contra empleados y entornos cloud empresariales, incluido el sector financiero. Es un contexto diferente del acceso de un cliente a su banca personal; no deben mezclarse ambos como un único mecanismo de fraude bancario.

La conclusión se restringe a estas referencias: no se establece aquí un incidente bancario latinoamericano identificado de forma suficiente en sus textos. No es una afirmación de que no existan incidentes, alertas o investigaciones regionales fuera de este conjunto. Véanse los criterios de citabilidad y alcance del dataset.

Qué comprobar en la autenticación y después de ella

El NIST SP 800-63B-4 no considera resistentes al phishing los códigos OTP introducidos manualmente. Describe la vinculación criptográfica al verificador y cita WebAuthn/FIDO2 como ejemplo. Un aviso push con datos del pago no demuestra, por sí solo, esa misma propiedad.

Como criterio de revisión, separar tres preguntas: ¿puede un impostor retransmitir la autenticación?, ¿puede reutilizarse la sesión desde otro contexto?, ¿qué autoriza exactamente la confirmación del pago? Mostrar importe y destinatario puede formar parte del diseño de autorización; no conviene presentarlo como equivalente automático a un protocolo resistente al phishing.

Una credencial protegida tampoco autoriza a declarar invulnerable toda la cuenta. La revisión debe abarcar recuperación, enrolamiento, cambio de dispositivo, sesiones y operaciones sensibles. Son áreas de comprobación propuestas, no el resultado de una prueba sobre la aplicación de un banco particular.

Alcance regulatorio y límites de la evidencia

No se usan aquí como hechos normativos las afirmaciones sobre biometría, SMS o regulación financiera en México y Brasil que no fueron verificadas en fuente primaria vigente. No se deduce de ellas cumplimiento, incumplimiento ni una obligación aplicable a toda la banca regional.

La comparación técnica entre mecanismos de autenticación no constituye una conclusión jurídica. Para publicar un panorama normativo, falta enlazar cada afirmación con la disposición primaria, su fecha y las entidades o canales que alcanza.

Tres decisiones para una revisión defensiva

Separar mecanismos. Registrar credenciales, OTP, cookies y autorizaciones de pago como elementos distintos. No diagnosticar un proxy inverso sólo porque hubo robo de códigos.

Probar el flujo completo. Evaluar autenticación resistente al phishing, recuperación de cuenta y controles de sesión sin prometer que una sola medida elimina todos los ataques.

Exigir alcance verificable. Para hablar de víctimas regionales, conservar fuente, país, período y tipo de evidencia. Una marca en una plantilla, una mención a LATAM y un incidente confirmado necesitan etiquetas diferentes. Esta síntesis no añade IOC ni atribuye un operador común a los casos.