Nadie rompió la criptografía de FIDO2. Eso es lo primero que hay que entender de la campaña que Microsoft documentó esta semana: los atacantes llaman al empleado, le dicen que tiene que actualizar su passkey antes de perder el acceso, y con ese pretexto lo empujan a un portal falso donde lo que se roba es el token de sesión. El passkey nunca se inscribe. Es solo el guion.
Desde mayo de 2026, Microsoft observa intrusiones en la nube que empiezan con una llamada telefónica y terminan con descargas masivas de SharePoint y OneDrive vía Microsoft Graph. Detrás no hay un grupo, hay un ecosistema de extorsión: los clusters que Redmond rastrea como Storm-3121 y Storm-3032 — asociados a ShinyHunters, Falcon, BlackFile y la marca que hoy se llama Helix. Google Threat Intelligence venía documentando lo mismo bajo el cluster UNC6671.
Qué pasó
Microsoft Security Research publicó el análisis de dos campañas distintas que comparten el mismo ADN: mucha investigación previa, suplantación de identidades confiables y cero exploits.
La segunda —la que importa para cualquiera que administre un tenant— arranca con reconocimiento. Los operadores levantan el organigrama de la víctima con fuentes públicas: redes sociales, perfiles profesionales, directorios. Con eso identifican a quién llamar y en nombre de quién hablar.
"El actor parece invertir fuertemente en investigación previa al ataque, probablemente recolectando información sobre empleados y estructura organizacional desde fuentes públicas como redes sociales y plataformas de perfilado profesional." — Microsoft Security Research
Después viene la llamada o el mensaje, casi siempre al teléfono personal del empleado, no al corporativo. El actor se presenta como el help desk de TI y plantea una urgencia operativa: hay que actualizar la configuración de passkey, MFA o SSO ya, o se pierde el acceso a los sistemas. El link llega por SMS al celular del empleado — fuera del perímetro de filtrado de correo, fuera de la vista del SOC.
De ahí, dos caminos. El primero es AiTM clásico: un proxy inverso entre la víctima y el login legítimo de Microsoft que captura credenciales y, sobre todo, la cookie de sesión ya autenticada. El segundo es device code phishing, más elegante y más difícil de detectar: el atacante inicia un flujo de autenticación de dispositivo, y guía a la víctima para que introduzca el código en las páginas legítimas de Microsoft. El usuario ve un dominio real, un certificado real, un prompt real de MFA — y termina autorizando a un cliente controlado por el atacante.
Por qué importa
Aquí está el punto incómodo. El passkey es la mejor defensa antiphishing que tenemos: está ligado al origen, no hay secreto compartido que viaje, no hay nada que teclear en un portal falso. Y precisamente por eso el atacante no lo pelea de frente. Ataca el proceso de enrollment, no el protocolo.
El momento en que un usuario "configura su passkey" es, por diseño, un momento de confusión legítima: hay pantallas nuevas, pasos que no reconoce, y una expectativa razonable de que TI lo va a acompañar por teléfono. Las organizaciones llevan un año empujando migraciones a passkey precisamente con ese guion. Los atacantes no inventaron un pretexto: copiaron el proyecto interno de seguridad.
El segundo punto es que la victoria del atacante no depende del factor de autenticación. Robar la sesión posterior al login deja el MFA irrelevante, porque el MFA ya se cumplió. El passkey autenticó correctamente al usuario correcto; lo que se secuestra es lo que pasa después.
Y el tercero: la persistencia. Microsoft observa que tras los inicios de sesión sospechosos los actores agregan sus propios métodos de autenticación a la cuenta comprometida. Con eso, resetear la contraseña no sirve de nada — el atacante ya tiene su propia llave registrada en la identidad de la víctima.
El detalle técnico
La fase de recolección es lo que delata la operación en la telemetría. Una vez dentro, el patrón es consistente con automatización sobre identidades comprometidas usando infraestructura de proxy:
- Volumen anómalo de actividad contra Microsoft Graph desde una sola identidad.
- Descargas masivas de SharePoint y OneDrive en ventanas cortas.
- Recolección de buzones vía REST API, no vía cliente de correo.
- Registro de nuevos métodos de autenticación inmediatamente después del primer sign-in exitoso.
La infraestructura de phishing sigue una convención de nombres bastante legible: dominios que combinan el vocabulario del proyecto de identidad con el nombre de la empresa víctima. Microsoft compartió ejemplos como passkeyhelpdesk[.]com, secure-passkey[.]com, setupmypasskey[.]com, add-passkey[.]com, integratedsso[.]com, oktasession[.]com, keysyncos[.]com y oskeysync[.]com. El truco de credibilidad es meter el nombre del cliente en el subdominio: nombre-de-la-empresa.secure-passkey[.]com. Para un empleado apurado, en un celular, eso se lee como un portal corporativo.
La primera campaña del reporte, aunque menos sofisticada técnicamente, merece una nota porque marca tendencia: más de un millón de correos fraudulentos entre el 3 y el 5 de agosto de 2026, enviados abusando de infraestructura de entrega de correo de terceros — es decir, desde remitentes con buena reputación. El señuelo era una supuesta renovación anual de ServiceNow, con facturas fabricadas, hilos de correo falsos que incluían la "aprobación" del pago, y firmas con los nombres y direcciones reales del CEO o CFO de la empresa objetivo. Microsoft señala evidencia de IA generativa en la creación de las plantillas y en la personalización de cada correo. Dominios como service-nowinc[.]com y domainlify[.]net sostuvieron la operación, dirigida sobre todo a cuentas por pagar de empresas estadounidenses de servicios de TI, consumo, bienes raíces y manufactura.
Lo que une ambas campañas es el abandono del exploit como vector. No hay CVE que parchar en ninguna de las dos. El activo atacado es el proceso: quién autoriza un pago, quién ayuda a un empleado con su MFA.
Qué hacer
En orden de retorno sobre esfuerzo:
- Cierra el device code flow. En la mayoría de tenants nadie lo necesita. Una Conditional Access policy que bloquee
authenticationFlows: deviceCodeFlowpara todos, con excepción explícita y acotada para los casos reales (dispositivos sin navegador, kioscos), mata el vector más difícil de detectar de esta campaña. - Phishing-resistant MFA con enforcement, no como opción. Passkeys y llaves de hardware sirven — pero solo si la política las exige y no deja un fallback a OTP o push que el atacante pueda proxear.
- Token protection y binding de dispositivo. Conditional Access con requisito de dispositivo compliant o híbrido unido convierte una cookie robada en un objeto inútil fuera del endpoint corporativo. Es la contramedida directa contra AiTM.
- Alerta sobre el registro de métodos de autenticación. Nuevo método MFA agregado debe ser un evento de detección, no una línea de log. En esta campaña es la señal de persistencia.
- Detección por comportamiento en Graph. Umbrales de descarga de SharePoint/OneDrive por identidad y por ventana de tiempo, y alerta sobre acceso a buzones vía REST desde ASNs de proveedores de proxy o VPS.
- Arregla el proceso humano. Esta es la que de verdad cierra el hueco: define y comunica un canal único y verificable para soporte de identidad, con la regla explícita de que TI nunca va a llamar al teléfono personal para pedir que configures un passkey. Si el proyecto de migración a passkeys de tu organización no incluye esa frase en su comunicación, tu proyecto de seguridad es el pretexto del atacante.
- Caza los dominios. Busca en tus logs de DNS y proxy registros que combinen el nombre de tu empresa con
passkey,sso,keysync,sessionoverify. Y monitorea registros nuevos con esa forma.
Para quienes estamos migrando clientes a passwordless, la lectura es clara y no es un argumento para frenar: el passkey sigue siendo el destino correcto. Lo que esta campaña demuestra es que la ventana de migración es la superficie de ataque, y que un rollout de identidad sin un plan de comunicación anti-vishing entrega el guion perfecto a la extorsión.