Portatil con escudo que contiene usuario y llave representando robo de credenciales

UAT-11985: la APT que evade MFA con phishing AitM e invitaciones falsas en Google

octubre 20, 2026 Alfonso Moreno | Sysadmin Senior 4 Visitas 17 min de lectura

La primera vez que vi un ataque AitM en producción fue en un cliente que tenía Google Workspace bien configurado, contraseñas robustas, políticas de contraseñas funcionales, y 2FA con Google Authenticator activado para todos los usuarios. Aun así, les vaciaron la bandeja y reenviaron reglas a dominios externos durante tres semanas antes de que alguien notara que varios hilos de correo de un proyecto sensible estaban duplicados en otra dirección. La causa raíz fue exactamente el patrón que Cisco Talos acaba de documentar como UAT-11985: invitaciones falsas a eventos que llevan a un proxy de autenticación transparente que se sienta entre la víctima y el proveedor de identidad, captura credenciales y códigos MFA de un solo uso en tiempo real, y se los entrega al operador. El atacante entra a la cuenta sin disparar la alerta de inicio de sesión nuevo, porque técnicamente la víctima sí inició sesión y usó su dispositivo legítimo.

Lo que cuenta Talos en su publicación del 16 de octubre de 2026 es importante para sysadmins aunque tu organización no esté en Asia: el kit de herramientas se puede reusar contra cualquier Google Workspace empresarial o cualquier instancia de Workspace con MFA activada, los cebos se redactan con IA generativa para que parezcan creíbles incluso cuando el atacante no sabe nada del objetivo, y el vector de entrada (una invitación a un evento de Google Calendar enviada desde un dominio externo) pasa por encima de la mayoría de los filtros antiphishing porque viene firmado por una cuenta legítima. Si tu organización usa Google Workspace, Office 365, o cualquier IdP con MFA TOTP, este artículo te interesa. Si ya migraste a FIDO2, también: hay matices que tienes que entender.

TL;DR — Lo que vas a tener al final

Tiempo de setup: 30 a 60 minutos para auditar la pila MFA actual, identificar usuarios que aún dependen solo de TOTP, y migrar los críticos a FIDO2 o passkeys.
Requisitos: acceso admin al Google Workspace o IdP equivalente, navegador actualizado en los endpoints, una llave FIDO2F (YubiKey, Titan, o la passkey del propio Android/iPhone) para los usuarios privilegiados.
Resultado: entiendes cómo funciona el phishing AitM documentado por Talos, qué controles específicos rompen la cadena, y por qué FIDO2 es la única defensa que detiene el proxy en seco.
Troubleshooting típico: usuarios con tokens TOTP legacy que resisten el cambio, llaves FIDO2 perdidas o no registradas, errores de binding en Workspace, falsos positivos de Google al evaluar la nueva política.

Qué es UAT-11985 y por qué Talos lo separó como cluster propio

Cuando un vendor publica un advisory de phishing, normalmente es una variante más de un patrón conocido: kit de phishing genérico, dominio recién registrado, plantilla de Office 365 copiada. Lo que Talos documentó esta vez no es un kit. Es un operador con identidad, infraestructura, herramientas a medida, y un playbook de varios pasos. Lo bautizaron como UAT-11985 y lo describen como un actor persistente con atribución incierta pero infraestructura y herramientas consistentes con grupos chinos-nexus. Lo importante no es la atribución: es que este operador tiene un kit de AitM modular que cualquiera puede copiar.

El vector de entrada es una invitación a un evento de Google Calendar enviada desde una cuenta de Gmail recién creada con un nombre creíble (típicamente algo tipo conference-organizer@<dominio-legítimo-imitado> o noreply@<subdominio-engañoso>). El correo llega a la bandeja de entrada, no a promociones ni a spam, porque Gmail trata las invitaciones a Calendar como correo legítimo. El cuerpo del evento contiene un enlace con apariencia oficial que la víctima sigue sin pensarlo: “Confirma tu asistencia aquí”, “Revisa el programa adjunto”, “Descarga la presentación preliminar”.

El enlace lleva a un dominio controlado por el atacante que parece una página de login de Google. Ahí empieza el proxy AitM. La víctima escribe su usuario y contraseña en una página que parece Google pero no lo es. El proxy reenvía la petición al Google real, recibe el desafío MFA, se lo presenta a la víctima en tiempo real, y captura el código. Con credencial válida + código TOTP válido, el atacante inicia sesión desde su propia infraestructura sin que Google marque la actividad como sospechosa, porque la petición lleva cookies válidas de un dispositivo legítimo (el de la víctima, que todavía está conectada).

Cómo funciona el phishing AitM en la práctica

Adversary-in-the-middle es ingeniería social con un servidor proxy en el medio. La página falsa no es estática: es un relay HTTP que habla con Google en una conexión paralela mientras tú hablas con ella. Cuando escribes [email protected], el proxy se lo manda a Google, recibe la pantalla de contraseña, te la muestra. Cuando escribes tu contraseña, el proxy la manda a Google, recibe el segundo factor, te lo muestra. Cuando ingresas el código TOTP de tu Google Authenticator, el proxy se lo manda a Google, recibe la cookie de sesión válida, y se queda con ella.

La diferencia técnica con el phishing clásico de “te robo la contraseña y después entro” es que el atacante ya no necesita evadir tu segundo factor en otro momento: lo captura en el mismo flujo legítimo. El código TOTP es de un solo uso y dura 30 segundos, así que tienes que actuar rápido, pero los scripts automatizados del proxy lo ingresan en menos de un segundo. Cuando ves “Sesión iniciada correctamente” en tu navegador, ya es demasiado tarde: el operador tiene una cookie válida y está navegando tu correo desde su infraestructura.

Este patrón no es nuevo: lleva circulando al menos desde 2022 con kits como Evilginx, Modlishka y Muraena, todos open source. Lo que cambió en 2026 es la escala y la automatización. Los operadores ya no necesitan desplegar su propio servidor: hay servicios comerciales tipo phishing-as-a-service que cobran entre 100 y 500 USD por sesión capturada de credenciales válidas con MFA incluido. La barrera de entrada cayó a cero. Por eso Talos destaca el caso: UAT-11985 parece tener su propio kit, pero la commoditización del proxy ya está madura.

Por qué el MFA tradicional no frena este ataque

El ataque evade la mayoría de las formas de MFA que se usan hoy. Si tu organización tiene Google Workspace con códigos SMS o TOTP, estás expuesto. Si tienes push notifications de Duo o Microsoft Authenticator, también, porque el proxy reenvía el push a la víctima, que aprueba sin pensar. Si tienes preguntas de seguridad adicionales, el proxy las reenvía también. Si tienes rate limiting por IP, el proxy usa la IP de la víctima para hablar con Google, así que tu defensa no aplica.

La única forma de MFA que detiene un proxy AitM en seco es FIDO2/WebAuthn con enlace criptográfico al origen. La diferencia técnica es que cuando te autenticas con una llave FIDO2 (YubiKey, Titan, llave integrada del dispositivo), el navegador firma un payload que incluye el dominio del sitio que te está pidiendo autenticación. Si el dominio no coincide con el certificado del origin real de Google (accounts.google.com), la firma criptográfica no se genera y la autenticación falla. El proxy puede capturar la pantalla, puede capturar lo que escribes, pero no puede falsificar el binding criptográfico entre el desafío y el dominio que el navegador ve.

Passkeys van por el mismo camino. Una passkey es una llave FIDO2 virtual almacenada en el llavero del dispositivo (iCloud Keychain en iPhone, Google Password Manager en Android, Windows Hello en PC). El handshake criptográfico es idéntico: el navegador genera un desafío ligado al dominio, la passkey lo firma, y el origin verifica la firma. El proxy no puede falsificar esa firma aunque tenga control total sobre la página que ves.

La forma más inmediata de reducir el riesgo sin migrar todo el mundo a FIDO2 de un día para otro es priorizar a los usuarios privilegiados (administradores de Workspace, owners de proyectos, gente con acceso a repositorios de código, controllers financieros). Un atacante que comprometa la cuenta de un admin de Workspace puede crear reglas de reenvío de correo, registrar apps OAuth con permisos amplios, o desactivar protecciones para el resto de la organización. Si tus admins usan FIDO2 y el resto sigue con TOTP, al menos la superficie de escalación queda minimizada.

El rol de la IA generativa en la personalización de los cebos

Lo que Talos enfatiza del informe y que a mí me preocupa especialmente es la atribución del contenido a IA generativa. El cuerpo de las invitaciones, los adjuntos, los hilos de seguimiento con preguntas de los “otros asistentes” para dar realismo, todo parece generado con un LLM capaz de producir texto plausible en chino, inglés, y japonés (los idiomas que Talos vio en las campañas documentadas). La víctima no detecta el cebo porque está bien escrito, está bien contextualizado, y replica patrones reales de invitaciones académicas que un investigador taiwanés recibe todos los días.

Esto cambia la heurística del phishing. Antes, la señal principal era el texto mal redactado, los saludos genéricos, los enlaces con dominios obviamente falsos. Ahora la señal principal desaparece: el texto está limpio, los saludos son personalizados con el nombre real de la víctima, los enlaces están en dominios legítimos comprometidos o en dominios nuevos con cámara y voces que pasan la inspección casual. Lo único que no se puede falsificar es la firma criptográfica del MFA con FIDO2.

El otro vector que Talos destacó es que la IA generativa permite escalar la operación. Un solo operador puede mantener conversaciones de seguimiento con decenas de víctimas simultáneamente, simulando hilos de correo donde otros asistentes hacen preguntas técnicas sobre el evento, donde el organizador responde dudas logísticas, donde se comparten archivos adjuntos. Eso antes requería un equipo humano bilingüe. Ahora un script y un LLM.

Indicadores de compromiso verificables

Talos publicó IoCs específicos que vale la pena traducir a reglas prácticas para Linux, con un par de comandos que puedes correr hoy en cualquier endpoint o en el SIEM de tu organización. Lo más accionable para un sysadmin que administra Google Workspace desde consola es auditar los últimos 30 días de eventos de login buscando patrones de proxy.

El primer chequeo: identificar cuentas con eventos de login desde dispositivos desconocidos o desde ASN de hosting/cloud que no son las habituales de tus usuarios. Google Workspace Admin Console exporta el log de login en CSV, y un análisis rápido con awk te separa las IPs por categoría:

# Bajar el log de login de Workspace de los últimos 30 días
# (Admin Console > Reporting > Audit log > Login audit)
# Filtrar entradas que NO vienen de tus rangos de IP conocidos
awk -F',' 'NR>1 {
  ip=$4; user=$2;
  if (!(ip ~ /^192.168./) && !(ip ~ /^10./) && !(ip ~ /^<tu-rango-vpn>/) && ip != "")
    print user","ip","$5
}' login_audit.csv | sort -u | head -20

Si aparecen entradas con ASN de hosting cloud (AS-13335 Cloudflare, AS-14061 DigitalOcean, AS-16276 OVH, etc.) donde normalmente no ves a tus usuarios, son candidatas para investigación manual. Eso no es una sesión comprometida necesariamente, pero es una anomalía que merece 5 minutos de revisión.

El segundo chequeo es buscar reglas de reenvío de correo sospechosas. Cuando el atacante entra a una cuenta de Workspace vía AitM, lo primero que configura para persistir es una regla de reenvío automático hacia un dominio externo. La regla suele tener nombres discretos (a veces solo espacios en blanco o caracteres Unicode invisibles) y se activa inmediatamente después del compromiso:

# Listar todas las reglas de reenvío activas en tu Workspace
# (Admin Console > Apps > Google Workspace > Gmail > Compliance > Content compliance)
# O via GAM si lo tienes instalado:
gam all users show forward | grep -E "enable|forwardingEmail" | head -20
# Regla sospechosa típica
# forwardingEmail: sesion-confirmada@<dominio-externo>
# disposition: leaveInInbox (la víctima sigue viendo los correos, no nota nada)

El tercer chequeo, más quirúrgico: buscar invitaciones de Calendar entrantes desde dominios externos en los últimos 30 días. Workspace no expone esto por defecto en la consola admin, pero se puede auditar desde el log de auditoría extendido:

# Activar el log de auditoría extendido en Workspace
# Admin Console > Reporting > Audit log > enable "Calendar event create"
# Después descargar el log vía Reports API o via GAM:
gam calendar events list users "<usuario-auditado>" after 2026-09-15 
  --fields id,summary,organizer.email,attendees.email | head -30
# Buscar organizadores externos con dominios que no están en tu allowlist

Si encuentras una invitación reciente desde un dominio externo sospechoso seguido de un login desde una IP de datacenter en las siguientes 24 horas, casi seguro tienes un caso activo. Lo correcto es revocar la sesión, forzar cambio de contraseña, eliminar las reglas de reenvío, revisar el log de OAuth apps autorizadas, y por último migrar al usuario a FIDO2 antes de devolverle el acceso.

Qué puedes hacer como sysadmin en tu organización

La parte práctica que más impacto tiene es endurecer la pila de autenticación. Lo dividís en cuatro acciones ordenadas por relación esfuerzo/impacto. La primera y más barata es auditar quién usa qué tipo de MFA hoy. Workspace Admin Console reporta el factor usado en el último login por usuario. Si tienes un script que identifique quién aún usa SMS o TOTP, ya tienes el universo a migrar.

# Inventario rápido de factores MFA en tu dominio via GAM
gam all users show lastlogin | grep -E "user|2sv" | head -50
# '2sv: true' = tiene 2FA activado
# '2sv_method: totp|sms|security_key|passkey' = qué método usa

La segunda acción es migrar primero a los privilegiados: admins del dominio, owners de proyectos críticos, controllers financieros, gente con acceso a producción. Esto se hace vía política de grupo en Workspace (Admin Console > Security > Authentication > 2-step verification) marcando “Only security key” para el grupo OU correspondiente. Los usuarios que aún no tengan llave FIDO2 registrada quedan forzados a registrar una antes de poder volver a entrar.

La tercera acción es habilitar Advanced Protection Program (APP) para los mismos usuarios. APP es un programa gratuito de Google que endurece los requisitos de seguridad de la cuenta: obliga a FIDO2 como único factor (no se puede usar TOTP ni SMS), restringe el acceso de apps OAuth de terceros a solo las verificadas por Google, bloquea el acceso desde apps móviles que no pasen las verificaciones de Google, y exige revisiones periódicas de dispositivos de confianza. Es la versión “hardcore” de la configuración de Workspace y es gratis. El costo es fricción operativa, pero para usuarios críticos vale la pena.

La cuarta acción, más defensiva, es auditar el log de OAuth apps autorizadas. Cuando un atacante entra a una cuenta vía AitM, lo segundo que hace (después de la regla de reenvío) es autorizar apps OAuth de terceros con permisos amplios: leer correo, administrar Drive, etc. La auditoría de apps es un one-shot que se hace con GAM:

# Listar todas las apps OAuth autorizadas en el dominio
gam all oauth list | grep -E "user|clientId|scopes" | head -30
# Buscar scopes sospechosos
# scope: https://mail.google.com/ = puede leer todo el correo
# scope: https://www.googleapis.com/auth/drive = acceso completo a Drive
# Cualquier app desconocida con scope amplio hay que revocarla

Una app OAuth sospechosa se revoca con gam user <user> deauthorize <clientId>. Después de la revocación, cambias la contraseña del usuario afectado y revisas el log de actividad de las últimas 72 horas en busca de cualquier acción que el atacante haya podido hacer. El último paso defensivo, aplicable a cualquier IdP, es forzar la reautenticación de toda la organización la próxima vez que abran el correo. Esto invalida las cookies de sesión que un atacante podría tener activas y obliga a un login fresco desde un dispositivo verificado:

# Forzar reautenticación inmediata en Workspace (vía GAM)
gam all users signout
# En Office 365 / Azure AD equivalente:
# AzureAD > Users > Sign-ins > Revoke sessions > usuario afectado
# En Okta:
# curl -X POST https://<tu-tenant>.okta.com/api/v1/users/<userId>/sessions 
#   -H "Authorization: SSWS ${OKTA_API_KEY}"
# Después de la reautenticación forzada, todas las cookies de sesión existentes
# quedan invalidadas y el atacante pierde acceso aunque tuviera credencial+MFA capturados

El costo operativo de esta acción es que todos van a tener que volver a iniciar sesión con su 2FA. En la práctica lo haces en una ventana corta (15-30 minutos) avisando por un canal secundario (Slack, Teams, llamada) que habrá un corte de sesión. Para una organización de 50 personas se resuelve en menos de una hora. Para una de 5000, mejor hacerlo en lotes por departamento y medir el impacto.

Resumen

El caso UAT-11985 que Talos publicó el 16 de octubre es importante para sysadmins hispanohablantes que administran Workspace, no porque el actor vaya a apuntar específicamente a tu organización mañana, sino porque la commoditización del phishing AitM ya está madura y el vector (invitaciones de Calendar) es transversal. Tu defensa principal no es un filtro antiphishing ni un WAF ni un EDR: es migrar a FIDO2, empezando por los usuarios privilegiados, y complementar con Advanced Protection Program. Esas dos decisiones cubren el 80% del riesgo real que el patrón expone. El otro 20% lo cubre la auditoría de reglas de reenvío y apps OAuth autorizadas, que vale la pena hacer de forma programada (una vez al mes con GAM, idealmente).

Lo que NO debes hacer es quedarte en TOTP pensando que “ya tenemos 2FA”. TOTP es vulnerable al relay que documenta Talos. SMS es directamente inseguro por el SIM swap. Push notifications son vulnerables porque el atacante reenvía el push. Solo FIDO2 con binding al dominio rompe la cadena. La migración toma tiempo y algo de fricción operativa, pero es la única decisión de defensa con retorno real contra este vector.

Preguntas frecuentes

¿Cómo sé si mi organización ya fue víctima de UAT-11985 o un ataque similar?

Los tres indicadores más rápidos: (1) reglas de reenvío de correo hacia dominios externos desconocidos en el log de Workspace, (2) sesiones OAuth con apps terceras que no recuerdas haber autorizado, (3) eventos de login desde IPs de datacenter (Cloudflare, OVH, DigitalOcean) que no son las habituales de tus usuarios. Si tienes cualquiera de los tres, hay que investigar manualmente.

¿Por qué FIDO2 frena el phishing AitM si TOTP no lo hace?

El handshake criptográfico de FIDO2 liga el desafío de autenticación al dominio del origin real (por ejemplo accounts.google.com). El proxy AitM no puede falsificar ese binding aunque controle la página que ves. TOTP en cambio es solo un código de 6 dígitos que se ingresa en un campo de texto plano: el proxy lo captura y lo reenvía sin problema.

¿Qué diferencia hay entre FIDO2, passkeys y las llaves físicas YubiKey?

FIDO2 es el estándar, las passkeys y las YubiKey son implementaciones. Una passkey es una llave FIDO2 virtual guardada en el llavero del dispositivo (iCloud Keychain, Google Password Manager). Una YubiKey es el mismo estándar pero en hardware dedicado. Ambas son resistentes al phishing AitM por la misma razón criptográfica.

¿Cuánto tarda migrar una organización de 50 usuarios de TOTP a FIDO2?

Depende de la urgencia. Para los 5-10 usuarios privilegiados (admins, owners, controllers), una tarde si tienes las YubiKey a mano. Para los 50 en una sola tanda, una o dos planes dedicadas con comunicación previa y un día de soporte one-on-one para los menos técnicos. La parte difícil no es la tecnología, es la gestión del cambio.

¿Qué hago si detecto un compromiso activo de AitM en mi organización?

Secuencia de contención: (1) revocar todas las sesiones activas de la cuenta afectada desde Workspace Admin, (2) forzar cambio de contraseña y eliminar TODAS las reglas de reenvío y apps OAuth autorizadas, (3) migrar la cuenta a FIDO2 antes de devolverle acceso, (4) auditar las últimas 72 horas de actividad (Drive, Calendar, Logs, Gmail) buscando acciones del atacante, (5) reportar internamente según tu política de incidentes.