Detectando ataques IaTM 2FA de Tycoon en Entra ID y Google Workspace

Tycoon 2FA es actualmente la plataforma de phishing como servicio (PhaaS) más prolífica entre los kits de phishing de AiTM. Observado por primera vez en agosto de 2023 y atribuido a Storm-1747 (según Microsoft Threat Intelligence), el kit ofrece capacidades llave en mano de adversario en el medio (AiTM) que eluden la autenticación multifactor y roban tokens de sesión autenticados de cuentas de Microsoft 365 y Google Workspace. En su apogeo, la 2FA de Tycoon representaba aproximadamente el 62% de los intentos de phishing bloqueados por Microsoft, llegando a más de 500.000 organizaciones mensualmente.

A pesar de una retirada coordinada en marzo de 2026 liderada por Microsoft y Europol, con el apoyo de Cloudflare, SpyCloud, eSentir y otros socios que se apoderaron de 300 dominios, los operadores se adaptaron en cuestión de semanas. A finales de abril de 2026, eSentire documentó campañas que combinan técnicas de Tycoon con flujos de phishing OAuth Device Code, y el kit sigue siendo la entrada #1 en ANY. El rastreador de tendencias de malware de RUN.

Cómo funciona la 2FA de Tycoon

El mecanismo AiTM

La 2FA de Tycoon funciona como un proxy inverso entre la víctima y el proveedor legítimo de identidad (Entra ID o Google). No es un recolector de credenciales estáticas. Proxia el flujo real de inicio de sesión en tiempo real:

1. La víctima recibe un email de phishing que contiene un enlace o código QR incrustado en un archivo adjunto PDF, SVG, HTML o PPTX.
2. El enlace se enruta a través de una cadena de redirección multicapa. El kit realiza la identificación digital del navegador, desafíos CAPTCHA y comprobaciones antianálisis antes de presentar la página de inicio de sesión.
3. La víctima ve una réplica perfecta en pixel de la página de inicio de sesión de Microsoft o Google, que a menudo incluye la marca de la organización objetivo extraída dinámicamente del servicio real.
4. Las credenciales se transmiten en tiempo real al proveedor legítimo de la identidad. El verdadero desafío de MFA se activa y se reenvía de vuelta a la víctima.
5. La víctima completa la MFA con normalidad. El proveedor de identidad emite un token de sesión. El proxy intercepta este token antes de que llegue al navegador de la víctima.
6. El atacante ahora posee un token de acceso totalmente autenticado.

La cookie de sesión es el valor que monetiza el operador. Una vez capturado, el MFA es irrelevante porque el operador reproduce los tokens acuñados luego del MFA.

Dos variantes estructurales en la rotación de corrientes

Dos variantes distintas de kits que analizamos estaban en uso activo:

WebSocket AiTM (el flujo "tradicional" de 2FA de Tycoon): La víctima se autentica mediante un proxy alojado en kit que reenvía el tráfico a Microsoft o Google a través de WebSocket (Socket.IO) y captura la cookie de sesión posterior a la MFA. El controlador cliente JavaScript del kit mantiene un canal bidireccional en tiempo real hacia el servidor C2, retransmitiendo credenciales y respuestas de autenticación a medida que la víctima escribe. Estas respuestas incluyen tokens de acceso acuñado y de actualización para su uso.

Abuso de la concesión de código de dispositivo (solo Microsoft): El relé del kit obtiene un código de dispositivo desde el endpoint oauth2/devicecode de Microsoft con Microsoft Authentication Broker (29d9ed98-a469-4536-ade2-f981bc1d605e) como cliente, lo muestra a la víctima mediante un señuelo de "código de verificación" y cambia el código por tokens de acceso/actualización después de que la víctima inicie sesión en el microsoft.com/devicelogin legítimo Punto final.

Técnicas de evasión

El kit emplea mecanismos antianálisis en capas confirmados mediante la descompilación en JavaScript:

• Filtrado de investigadores basado en IP: Antes de mostrar cualquier contenido, el kit llama a api.ipapi.is (o servicio equivalente) para comprobar la IP del visitante en comparación con una lista bloqueada de proveedores de cloud/hosting (Leaseweb, M247, DigitalOcean, Linode, Amazon, OVH, Hetzner, Google, Microsoft, Cloudflare, Akamai, Fastly, almacenado como cadenas invertidas para evadir escaneos estáticos). Los visitantes en la infraestructura en la nube son redirigidos a un sitio señuelo benigno.
• Detección de bots/herramientas: Comprueba navegator.webdriver (Selenium), window.callPhantom / window._phantom (PhantomJS) y "Burp" en la cadena user-agent. Detección activa una redirección a aproximadamente:blank.
• Bloqueo de DevTools: Intercepciona atajos de teclado para herramientas de desarrollo (F12, Ctrl+Shift+I/J/C, Ctrl+U, equivalentes a macOS) y desactiva los menús contextuales con clic derecho.
• Trampa de depuración: Un bucle setInterval que se ejecuta cada 100 ms inserta una instrucción de depurador y mide el tiempo de ejecución. Si DevTools está abierto (pausas de ejecución >100 ms), la víctima es redirigida a un sitio señuelo.
• DOM: El JavaScript malicioso se elimina del DOM tras la ejecución, sin dejar rastro para inspección estática.
• Cifrado por víctima: La carga útil emplea un cifrado personalizado de dos etapas (desplazamiento César + XOR con un flujo de claves generado por PRNG) sembrado con valores por sesión. La semilla, la clave y el blob cifrado se generan en el lado del servidor para cada víctima, haciendo imposible la detección de firmas estáticas.
• Segmentación de plataformas: En computadoras de escritorio Linux, escribe una cadena vacía para dejar la página en blanco: probablemente asumiendo que los usuarios de Linux son más propensos a ser investigadores de seguridad.
• CAPTCHA falso: Un CAPTCHA con cuadrícula de imagen personalizada reemplaza al torniquete Cloudflare en la variante actual. Las imágenes no provenientes de la pantalla en una cuadrícula 3×3 proporcionan verificación humana antes de que cargue la página de phishing.

Para campañas dirigidas a Google, el primer salto suele realizar en infraestructuras legítimas de Google, como Google Storage o Google Sites, aunque también se observan dominios controlados o comprometidos por el operador. Cuando se emplea el propio alojamiento de Google, el origen storage.googleapis.com o sites.google.com proporciona una cobertura de reputación integrada antes de que la víctima llegue al relé AiTM.

En otros casos, el email de la víctima se rellena automáticamente y el botón "Siguiente" se hace clic automáticamente: la víctima aparece directamente en la página de la contraseña, haciendo que parezca que ya está parcialmente autenticada (aumentando la confianza):

var emailcheck = "victim@email.corp";
// ...
function tryfindingele(email) {
   emailinputcheck.value = email;
   emailsectionelecheck.querySelector(".btn-blue-next-btn").click();
}
if (emailcheck !== "0") { tryfindingele(emailcheck); }

Microsoft 365 / Entra ID

Una arquitectura operativa de dos niveles

El modelo operativo actual de Tycoon 2FA se divide en dos niveles de infraestructura distintos, cada uno con su propio ASN, rol y firma de comportamiento. Los defensores que buscan un solo patrón atraparán un nivel y fallarán el otro.

Nivel 1 - Relevo de Kit

El backend automatizado que gestiona la adquisición y renovación de tokens. Características:

• IPs de salida de VPS en la nube de proveedores de alojamiento (Alibaba Cloud, ASN VPS baratos similares), rotando entre múltiples IPs en diferentes bloques /16 durante un mismo compromiso.
• Node.js agentes de usuario cliente HTTP: node (bare, por defecto Node.js UA), axios/1.15.2, node-fetch/1.0, Undici.
• Aplicación cliente: Microsoft Authentication Broker (29d9ed98-a469-4536-ade2-f981bc1d605e), posteriormente empleada con el Device Registration Service (DRS) para acuñar un primaryRefreshToken (PRT).
• Progresión por tipo de token: incomingTokenType: none (autenticación inicial de la víctima) > refreshToken (bucle de renovación de relé de kit, repetido entre IPs rotativas) > Registro de Dispositivo Fraudulento > primaryRefreshToken (reproducción PRT, alcance más amplio).
• Inicios de sesión no interactivos: Tras completar el código interactivo del dispositivo inicial, las operaciones posteriores de token son actualizaciones de servidor a servidor.

Nivel 2 - Consola de Operador

El humano (o herramienta de simulación humana) que realiza el reconocimiento post-compromiso. Características:

• ISP de forma residencial o salida proxy, típicamente un ASN pequeño que no está presente en las señales comunes de amenazas de proveedores de hosting. Múltiples IPs en un solo /24, todos actuando en coordinación.
• Un único agente de usuario de navegador (por ejemplo, Firefox en Windows) fijo en todas las IPs del clúster. Una herramienta configurada, no usuarios independientes.
• Inicios de sesión interactivos mediante navegador para las aplicaciones sitio web de Microsoft: Mi Perfil, Mis Inicios de Sesión, Gestión de Aprobaciones de Microsoft, Outlook Sitio web y OfficeHome.
• Un solo c_sid (ID de sesión del cliente en los Logs de Actividad de Grafos) compartido entre todas las IPs, confirmando una única sesión distribuida en el pool.
• Ritmo operativo: Normalmente aparece entre 10 y 20 minutos luego de la emisión exitosa del primer token del relevo de kit. La brecha representa la ventana de traspaso kit-operador.

La señal de detección multinivel duradera: Dos ASN distintos (uno en la nube-VPS, otro de forma residencial) que se autentican como el mismo usuario principal en cuestión de minutos. Las reglas de un solo ASN atrapan un nivel; El pivote entre niveles es el indicador de alta confianza.

Enumeración de API de grafos posterior al compromiso

Una vez que la consola del operador tiene un token válido, sigue una ráfaga rápida de llamadas a la API Microsoft Graph, normalmente decenas de solicitudes en 30-60 segundos, alcanzando endpoints de reconocimiento de alto valor:

Indicadores clave de telemetría del reconocimiento automatizado post-compromiso:

• Volumen y velocidad: 20-30+ llamadas en una ventana de 30-60 segundos, cada una llegando a un punto final diferente.
• Métodos HTTP mixtos: GET para la mayoría de endpoints, POST para acciones como getResourceTenants.
• Parámetros estructurados de consulta: $select, $top=999, $count=true : optimizados para la máxima extracción de datos por llamada.
• Uso de la API /beta/: Usado de forma desproporcionada por herramientas ofensivas frente a la navegación normal por portales.
• Éxito/fracaso mixto: Algunos endpoints devolven 400 o 403 (el kit sondea todo igualmente), mientras que la mayoría devuelve 200. Los intentos fallidos de reconocimiento siguen siendo reconocimiento.
• C_DeviceId vacía: El token se emitió a un dispositivo no gestionado ni registrado.
• Aplicaciones de primera mano con amplios ámbitos preconsentidos: los tokens para mi perfil llevan ámbitos como RoleManagement.ReadWrite.Directory, MailboxSettings.ReadWrite, UserAuthenticationMethod.ReadWrite y User.RevokeSessions.All - todos preconsentidos, sin necesidad de solicitud de consentimiento OAuth.

Persistencia Device-PRT

Como se indicó antes, el kit puede establecer una persistencia de registro de dispositivos que sobreviva a los manuales estándar de revocación de sesión. El mecanismo:

1. El token de actualización del MAB se intercambia en oauth2/token por un token de acceso cuyo aud es urn:ms-drs:enterpriseregistration.windows.net (mismo ID de cliente, nueva audiencia, sin aviso de consentimiento).
2. El kit emplea el token de acceso urn:ms-drs:enterpriseregistration.windows.net al servidor de inscripción/dispositivo del endpoint POST con un CSR PKCS#10 generado localmente, metadatos sintéticos del dispositivo y blob de clave de transporte. DRS crea un objeto de dispositivo, asigna un ID de dispositivo, firma y devuelve un certificado de dispositivo.
3. El kit construye un JWT que contiene el token de actualización del usuario, lo firma como RS256 con la clave privada del dispositivo e inserta el certificado del dispositivo en la cabecera JWT. PUBLICA esto a login.microsoftonline.com/common/oauth2/token como portador de una beca JWT. Entra valida la firma frente al certificado y devuelve el PRT más una clave de sesión cifrada (JWE).
4. Cuando un defensor dispara revokeSignInSessions (que invalida todos los tokens a nivel de usuario y tokens de actualización), la PRT del dispositivo sigue siendo válida porque el dispositivo es un principal separado en el ID de Entra.
5. A partir de las nuevas IPs de relé, el kit emplea la clave PRT plus sesión para firmar aserciones HMAC-SHA256 por solicitud a /oauth2/token, intermediando tokens de acceso para cualquier client_id de primera mano que nombre (Teams, Outlook, OneDrive, Office, Intune).

¿Por qué no detiene la 2FA de Tycoon revocar las sesiones?

Esto significa que la secuencia estándar de respuesta a incidentes de "revocar sesiones > restablecer contraseña" es insuficiente. Los defensores deben enumerar y eliminar los dispositivos registrados antes de revocar las sesiones para romper la cadena dispositivo-PRT de forma atómica.

Matices de detección - Microsoft

La Protección de Identidad puede no marcar infraestructura de kits. Las IPs de salida actuales de Tycoon 2FA rotan agresivamente y puede que no estén dentro del corpus de riesgos de Microsoft. Los defensores que dependan únicamente de las señales de riesgo de Entra ID para la detección de IaTM no verán nada.

c_sid en los Registros de Actividad de Grafos NO es el ID del objeto de usuario. Es un identificador de sesión/contexto de seguridad. Los analistas que filtren los Logs de Actividad de Grafos por c_sid == user_object_id obtendrán resultados vacíos y concluirán que el atacante no usó tokens de Grafo. El pivote correcto de búsqueda es IP fuente + appId, cruzado con registros de inicio de sesión para mapear IP al usuario.

La geolocalización es poco fiable para las IPs de los proveedores de nube. La misma IP de retransmisión de kit puede geolocalizar a diferentes ciudades dentro de la misma sesión de inicio de sesión. ASN es el único enriquecimiento fiable para las reglas de detección.

Visibilidad de la acuñación de fichas. La acuñación o emisión de fichas no se registra; Los eventos de autenticación que aprovechan estos tokens proponen una señal de caza más reactiva.

Protección de Entra ID Estado de usuario riesgoso. Entra ID Protection analiza eventos de inicio de sesión, sesiones, tokens y más para aplicar un nivel de riesgo y un estado a los usuarios. se observó aiConfirmedSafe durante el relé de nivel 2 , marcando al usuario como sin riesgo. Luego se identificaron anomalías de riesgo de usuario basadas en anomalousToken , lo que devolvía al usuario a un riesgo medio. Simplemente excluyendo eventos en los que aiConfirmedSafe puede cegar a las organizaciones ante falsos negativos según el etiquetado de Microsoft.

Google Workspace

Relé de kit de un solo nivel

La variante de Google funciona como un relé de un solo nivel de kit sin el nivel distintivo de consola de operador que se ve en el lado de Microsoft. Múltiples IPs de retransmisión de kit (normalmente de ASNs de alojamiento baratos como Clouvider, Host Telecom o similares) autentican al mismo usuario en cuestión de minutos, cada una realizando la misma secuencia de cuatro eventos:

1. login_success contraseña validada (T+0.000s)
2. login_verification con is_second_factor: true - kit retransmite el TOTP/SMS/código push en tiempo real, completando 2SV (T+0.000s)
3. token: autorizar para el cliente Chrome OAuth de Google (77185425430) (T+0.4 a 0.6s)
4. DEVICE_REGISTER_UNREGISTER_EVENT (el nuevo dispositivo está registrado por Google debido a la autenticación de perfil) (T+0,6 a 1,2s)

Esa compresión de ~1 segundo es una señal de inicios de sesión automáticos.

El kit autoriza consistentemente el mismo cliente OAuth en cada sesión de relé:

El alcance OAuthLogin es el alcance interno de inicio de sesión de arranque de Chrome. No es un ámbito de plano de datos (por sí solo no concede acceso a Gmail, Drive o Calendario). El radio de explosión del kit desde este único osciloscopio está vinculado a un inicio de sesión de larga duración capaz de convertir en una sesión de Chrome Sync, no atajo a buzones o archivos sin más llamadas de intercambio de tokens.

Lo que confirma el evento token.authorize de un ASN VPS es que la autorización ocurre en el servidor durante el relé, no desde el dispositivo de la víctima, lo que lo hace sospechoso independientemente de la intención del operador.

Arquitectura JavaScript de Kit (variante de Google)

La descompilación de la variante WebSocket orientada a Google revela una arquitectura de 5 capas:

Los campos de entrada 15 capturan todos los métodos de 2FA de Google: contraseña, TOTP, SMS, llamada de voz, códigos de respaldo, correo de recuperación, verificación del teléfono, respaldo de la clave de seguridad, aviso móvil y cambio forzado de contraseña. El nombre de evento "recieveid" Socket.IO (fíjate en el error tipográfico) es una huella dactilar consistente del kit.

Matices de detección - Google

El Centro de Alertas de Google puede permanecer en silencio. Incluso cuando varios inicios de sesión de varios ASN llegan al mismo usuario en cuestión de minutos, los registros del Centro de Alertas pueden no fluir a la API de Alertas. Los emails de alerta de seguridad de buzón de víctimas de Google no son un sustituto, ya que van a la bandeja de entrada del usuario comprometido, no a la superficie de administración.

is_suspicious no puede disparar. Las IPs de retransmisión de kit de ASN de alojamiento barato pueden no estar en el corpus de riesgos de Google. Los defensores que dependan de este campo como señal principal tendrán puntos ciegos. En el combate con canarios, is_suspicious era falso en todos los login_success de las cuatro IPs de los kits, tanto de Clouvider como de Host Telecom.

No hay agente de usuario en los eventos de inicio de sesión: Los eventos de inicio de sesión de la API de Reportes no incluyen datos de agentes de usuario ni datos de huellas dactilares del dispositivo. Las detecciones basadas en UA que funcionan en el lado de Entra (nodo / axios / undici) no tienen equivalente directo en Google.

La visibilidad del flujo de trabajo OAuth es mínima: El evento token.authorize de Google client.id, app_name, cliente.type, y alcance.valor, Y ese es el set completo. No hay resource_id distinto de alcance, ni campo de tipo concesión, ni campo de tipo token entrante.

La mayoría de los flujos auxiliares permanecen en silencio: no hay acceso a google_workspace.context_aware _ eventos activados (a pesar de cinco nuevos registros de dispositivos en el usuario) y ningún registro del Centro de Alertas llegó a la API de Alertas. La huella del kit se encuentra en tres flujos únicamente: inicio de sesión, token y dispositivo. Las cacerías que dependen de cualquier otro stream no detectarán este kit.

Tycoon 2FA en Entra ID y Google Workspace

La variante M365 es operativamente más pesada, y el registro proporciona detalles extensos antes y luego del compromiso de identidad. La variante de Google Workspace es más ligera (solo se observaron inicios de sesión), pero el registro por defecto carece de contexto importante.

Reglas de detección de comportamiento de 2FA en Tycoon

Implementamos reglas de detección a través de fuentes de telemetría de Microsoft y Google que cubren toda la cadena de ataques: phish inicial de AiTM, retransmisión de token, reconocimiento en consola del operador y persistencia del dispositivo.

Microsoft - Detección de relés en kit

Entra ID Posible inicio de sesión AiTM vía OfficeHome (Tycoon2FA) - Es una detección de alta señal que se activa al iniciar sesión con Broker de Autenticación u OfficeHome en Graph/Exchange con agentes de usuario estilo Node.js (node, axios, undici). Captura las operaciones del token del lado servidor del nivel de kit relay.

M365 Potencial Usuario AiTM Iniciado sesión mediante Office App (Tycoon2FA) - Misma lógica de detección que la regla de inicio de sesión de Entra pero en contra del Registro Unificado de Auditoría de M365 para inquilinos que ingieren o365.audit en lugar de (o además de) los registros de inicio de sesión de Entra.

Phishing por código de dispositivo OAuth de Entra ID vía AiTM : Detecta inicios de sesión interactivos exitosos de flujo de código del dispositivo a través del Auth Broker, dirigir a Exchange, Graph o SharePoint. Detecta específicamente la variante de abuso de código de dispositivo.

Entra ID Microsoft Authentication Broker Inicio de sesión en un recurso inusual : Detecta inicios de sesión exitosos del Auth Broker cuando el recurso objetivo está fuera del conjunto de primera parte comúnmente observado. Detecta el intercambio de tokens FOCI a APIs o aplicaciones empresariales inesperadas.

Microsoft - Detección de persistencia

Dispositivo de registro de Entra ID con agente de usuario inusual (Azure AD Join): Detecta eventos exitosos de registro de dispositivos cuando el agente de usuario no es uno de los clientes nativos conocidos (Dsreg, DeviceRegistrationClient, Dalvik). Detecta la reproducción de persistencia dispositivo-PRT del kit que también se origina en el agente de usuario axios:

Enumeración posterior al compromiso de la API de grafos (ES|QL)

Para la reconstrucción posterior al compromiso del nivel de consola de operador, construimos un ES| Regla QL que etiqueta cada solicitud de API de Microsoft Graph en una de cinco categorías de reconocimiento y se activa cuando se alcanzan 4 o más categorías distintas dentro de la ventana de agregación (<= 60s):

Microsoft Graph Multi-Category Reconnaissance Burst captura enumeraciones sistemáticas posteriores al compromiso mientras filtra el uso orgánico de portales. La actividad normal del usuario puede tocar una o dos de estas categorías; al acertar 4 o más categorías de reconocimiento distintas de una sola sesión en un corto periodo (33 segundos) está la huella digital de herramientas automatizadas.

Google - Detección de relé y persistencia de kits

Inicio de sesión en Google Workspace Viajes Imposibles - ES|Regla QL usando *st_distance()* funciones geoespaciales para detectar inicios de sesión exitosos en ubicaciones que implican desplazamientos más rápidos que 800 km/h con al menos 500 km de separación. Detecta el patrón de relé de kit multi-ASN donde múltiples IPs en diferentes geolocalizaciones autentican al mismo usuario en cuestión de minutos:

Inicio de sesión de usuario de Google Workspace desde Atypical ASN : nueva regla de términos que detecta la primera vez que un usuario de Google Workspace inicia sesión con éxito desde un ASN de origen dentro de una ventana histórica de 14 días.

Registro de dispositivos en Google Workspace tras OAuth de Suspicious ASN : regla de secuencia EQL detectando autorización OAuth para el cliente Chrome (77185425430.apps.googleusercontent.com) desde un ASN de alojamiento barato, seguida en 30 segundos por un registro de dispositivo con estado de cuenta REGISTERED.

Ráfaga de registro de dispositivos de Google Workspace para un solo usuario - Detecta ráfagas de eventos de registro de dispositivos en Google Workspace para el mismo usuario, cuando tres o más eventos distintos
google_workspace.device.id valores se emiten en una ventana de un minuto:

Automatización del contención con flujos de trabajo elásticos

Una vez que el contenido de detección está en su lugar, el siguiente intervalo es el tiempo entre la alerta y la acción. La ventana de transferencia de kit a operador del Tycoon 2FA M365 que documentamos antes es de 10-20 minutos, el tiempo entre la emisión exitosa del primer token del kit relay y el inicio de la sesión de nivel operador de su reconocimiento Graph posterior al compromiso.

Una respuesta SOC manual suele tardar más que esa ventana, por lo que el operador realiza el trabajo de reconocimiento antes de que llegue la contención. Cerrar esa brecha es lo que hace que la detección sea accionable.

Elastic Workflows, incluido con la pila (9.4+), permite que las reglas de detección invoquen flujos de trabajo personalizados con una cadena de pasos definida por YAML en cada alerta.

Como PoC, creamos un flujo de trabajo personalizado conectado a una regla de detección Entra ID Potencial Inicio de sesión AiTM vía OfficeHome (Tycoon2FA) que refleja las acciones de respuesta requeridas.

En cada alerta el flujo de trabajo:

1. Adquiere un portador de grafo mediante client_credentials (una vez por ejecución).
2. PATCHea el UPN comprometido con accountEnabled: false para detener nuevas autenticaciones.
3. Enumera los Dispositivos registrados y los dispositivos propietarios del usuario.
4. ELIMINA cada principal de dispositivo, que es lo que en realidad invalida un PRT vinculado al dispositivo.
5. POSTs a revokeSignInSessions para invalidar tokens de actualización a nivel de usuario y cookies de sesión.
6. Abre un caso Kibana rellenado con el contexto de alerta para la auditoría posterior a la investigación de la investigación (restablecimiento de contraseña, revisión del método de autenticación, auditoría de la subvención OAuth).

La cadena se ejecuta en menos de 10 segundos de principio a fin contra Microsoft Graph, muy dentro de la ventana de entrega de 10-20 minutos de Tycoon 2FA. La sesión de nivel operador nunca tiene oportunidad de comenzar el reconocimiento.

El patrón escala más allá de esta regla. La misma forma de flujo de trabajo funciona para cualquier detección de identidad en la nube que se beneficie de una contención inmediata: inicios de sesión AiTM, viajes imposibles, concesiones ilícitas de consentimiento OAuth, escalada de roles, fatiga MFA, registro anómalo de dispositivos. Conecta la regla a un flujo de trabajo que llama a la API de la nube correspondiente y el SOC obtiene contención de segundo nivel.

Defendiendo contra ataques de IA de 2FA de Tycoon

• Despliega MFA resistente al phishing: Las claves de seguridad y las claves de acceso FIDO2 son los únicos métodos inmunes al robo de sesiones con AiTM. TOTP, SMS y MFA basado en push pueden ser proxy.
• Hacer cumplir el cumplimiento de dispositivos mediante Acceso Condicional: Exigir dispositivos gestionados y compatibles para la emisión de tokens. Este es el control más efectivo contra el robo de tokens de AiTM.
• Flujo de código de dispositivo de bloque: La política de Acceso Condicional de Block device code flow rechaza limpiamente el relé del kit en la fase de concesión (error 53003). Actívalo para todos los usuarios excepto en escenarios de kioscos o headless aprobados explícitamente.
• Habilitar la protección de tokens (vinculación de token): Vincula los tokens al dispositivo al que fueron entregados. Un token robado reproducido desde otro dispositivo es rechazado.
• Habilitar la Evaluación de Acceso Continuo (CAE): Revocación de tokens casi en tiempo real cuando cambian las condiciones de riesgo.
• Activar valores predeterminados de seguridad en Entra ID (solo para inquilinos sin acceso condicional personalizado): rechaza la autenticación heredada como ROPC y bloquea el flujo de código del dispositivo por defecto. Activar los valores predeterminados de seguridad desactiva políticas de CA personalizadas, por lo que esto no es aplicable a los inquilinos que ya ejecutan CA granular.

CARTOGRAFÍA DE MITRE ATT&CK

Referencias

• Microsoft Security Blog - Dentro de Tycoon2FA: Cómo operaba a gran escala un kit líder de phishing de IA (marzo de 2026)
• Análisis de malware 2FA de Tycoon, resumen por ANY. CORRE
• Cloudflare - Retirada de 2FA de Tycoon (marzo de 2026)
• SpyCloud - Eliminación de 2FA de Tycoon: Dentro de la disrupción global de la infraestructura de phishing (marzo de 2026)
• eSentire - Operadores de 2FA de magnates adoptan phishing de código de dispositivo OAuth (mayo 2026)
• Sekoia - Tycoon 2FA: un análisis en profundidad de la última versión del kit de phishing AiTM (marzo de 2024)