La llamada que te pide configurar la passkey: Microsoft documentó la estafa paso a paso

Si te suena el celular personal y del otro lado hay alguien que dice ser del soporte técnico de tu empresa, que hay que actualizar la passkey ahora mismo y que si no lo hacés te quedás sin acceso, no estás ante un trámite: estás ante la primera pantalla de un ataque que Microsoft acaba de documentar paso a paso. El informe salió el 9 de septiembre de 2026 en el blog de seguridad de la compañía, y describe intrusiones en la nube que su equipo viene observando desde mayo de 2026.

Lo que sigue a esa llamada no es lo que el nombre sugiere. Microsoft lo dice con todas las letras: a menudo la inscripción de la passkey no es el verdadero objetivo del atacante. Es la excusa para que vos hagas otra cosa.

Qué te conviene hacer hoy: entrá a la configuración de seguridad de tu cuenta y mirá la lista de métodos de inicio de sesión registrados —teléfonos, aplicaciones autenticadoras, tokens—. Si hay uno que no reconocés, ese es el problema, y no se arregla cambiando la contraseña: hay que quitar el método y además cerrar las sesiones activas. Microsoft lo dice con todas las letras en su guía de contención, y más abajo está el porqué.

Lo que vas a encontrar acá

• Por qué el señuelo llega al teléfono personal y no al corporativo.
• El dato que da vuelta el título fácil: a menudo la passkey es solo la excusa.
• El método de MFA que el atacante se registra a nombre tuyo.
• La línea de tiempo real: qué toca la sesión intrusa en la primera hora.
• Qué está probado y qué no: dónde Microsoft afirma y dónde acota su propia evidencia.

El falso soporte técnico entra por el teléfono personal

La secuencia suele arrancar, según el informe, con «una llamada o un mensaje aparentemente rutinario al número de teléfono personal del usuario, de alguien que dice ser de la mesa de ayuda de TI de la organización». El que llama fabrica urgencia: hay que actualizar ya la configuración de passkey, de MFA o de inicio de sesión único (SSO) para evitar una interrupción del servicio. Después dirige a la persona a un sitio que imita el inicio de sesión de Microsoft, y el enlace puede llegar por SMS al mismo celular.

Que el contacto llegue al teléfono personal no es un detalle de color, y el informe explica por qué importa tanto: si la víctima abre el enlace en un dispositivo móvil propio que no está incorporado a Microsoft Defender for Endpoint, esa actividad puede no aparecer en la telemetría del endpoint. Traducido: la empresa no lo ve. Microsoft llega a decir que, en muchas investigaciones, «el recuerdo del empleado de una llamada telefónica o un mensaje de texto se convierte en la primera y a veces única evidencia» de cómo empezó todo.

La passkey, a menudo, no es el objetivo: es la excusa

Acá está el nudo de la noticia, y conviene leerlo despacio porque el titular fácil apunta justo para el lado contrario. El informe dice, textual: «A pesar del uso frecuente de señuelos con temática de passkey, la inscripción de la passkey a menudo no es el verdadero objetivo del actor. En cambio, el relato de la passkey sirve como un pretexto convincente para guiar a las víctimas a través de flujos de phishing adversary-in-the-middle (AiTM) o de autenticación por código de dispositivo».

O sea: el informe no describe ninguna falla técnica de las passkeys. Hay una palabra técnica, nueva y con buena prensa, usada como argumento telefónico. Y la señal más clara de que la tecnología no es la víctima está en la propia guía de Microsoft: entre sus recomendaciones para reducir riesgo futuro figura «exigir MFA resistente a phishing (FIDO2/passkeys, Windows Hello for Business)» mediante Acceso Condicional. La passkey de verdad es la defensa que recomiendan; el ataque solo le pidió prestado el nombre.

Los dos caminos que describe el informe son distintos entre sí:

• AiTM: el atacante se pone en el medio y captura credenciales y tokens de sesión. Es el mismo mecanismo del que ya hablamos en la nota sobre el token de sesión robado: lo que se llevan no es tu contraseña, es la sesión que ya está abierta.
• Código de dispositivo: acá no hace falta robar nada. Se convence a la persona de escribir un código en la página de autenticación legítima de Microsoft, y esa aprobación emite un token a un cliente controlado por el atacante «sin robar una cookie del navegador». El informe registra que después reprodujeron ese token y así saltearon el MFA.

El MFA que el atacante registra a nombre tuyo

Conseguido el ingreso, el primer objetivo del atacante —dice el informe— fue convertir un acceso temporal en uno permanente. ¿Cómo? No confiando solo en las credenciales robadas, sino inscribiendo un método de MFA bajo su control: típicamente un número de teléfono nuevo, una aplicación autenticadora o un token OTP por software. Eso inserta un factor del atacante dentro de tu identidad, de modo que los futuros desafíos de autenticación se resuelven sin que vos participes.

Y acá viene la frase que convierte todo esto en una instrucción práctica: «si bien la inscripción de MFA por sí sola no sobrevive a un restablecimiento completo de credenciales y sesiones, proporciona un mecanismo de persistencia duradero cuando se combina con tokens robados, sesiones no revocadas o el acceso posterior a credenciales válidas».

Leelo al revés y tenés el error más caro que se puede cometer después de un incidente: cambiar la contraseña y quedarse tranquilo. Si la sesión no se revoca y el método agregado por el atacante sigue ahí, la puerta sigue abierta.

Hay un tercer patrón que documentaron, y da escalofríos por lo prolijo: el atacante inició sesión con credenciales comprometidas y aprobó el MFA con un método PhoneAppOTP registrado previamente. Microsoft escribe que eso sugiere que había registrado la aplicación autenticadora días antes de lanzar la campaña. Esa actividad, agrega, se llevó adelante principalmente con un sistema automatizado desarrollado con Node.js y Microsoft Graph.

Del ingreso a Teams en 16 minutos, y una hora adentro

El informe publica la línea de tiempo de una de las investigaciones. La velocidad es el primer dato: entre el ingreso y el acceso a los servicios de colaboración pasan 16 minutos. El segundo es que después no se van a ningún lado: «la investigación reveló que las sesiones del actor persistieron durante aproximadamente una hora mientras enumeraban archivos sensibles y aplicaciones internas».

Qué está probado y qué no

Acá hay dos niveles de evidencia que conviene no mezclar, porque son los que deciden qué se puede afirmar.

Lo que Microsoft sí afirma, a nivel campaña. Hubo descargas: dice haber observado «actividad de acceso y descarga de alto volumen» contra SharePoint Online y OneDrive for Business, con algunas intrusiones extendiéndose a Exchange Online por API REST, y precisa que esa actividad generó «volúmenes significativos de eventos FileAccessed y FileDownloaded, lo que indica una recuperación sistemática de documentos alojados en la nube y datos de la organización». La recolección está afirmada. Lo que el informe marca como sospechada es la exfiltración, es decir la salida de esos datos hacia el atacante.

Lo que no está probado, en la línea de tiempo de ese incidente puntual. Ahí Microsoft acota una y otra vez el alcance de su propia telemetría, y esas aclaraciones también son parte de la noticia:

• Sobre SharePoint: «los eventos de inicio de sesión no prueban que se haya abierto o descargado un documento».
• Sobre el escritorio virtual: la autenticación al portal interno tuvo éxito, pero «no se confirmó» que se haya lanzado ningún recurso.
• Sobre el adjunto del minuto 15: es «más significativo que un acceso genérico al buzón», pero «la telemetría de inicio de sesión no prueba que se haya descargado un adjunto».

Microsoft evalúa además que la secuencia «es consistente con» recolección automatizada desde identidades comprometidas usando infraestructura asociada a proxies. Y avisa algo útil para cualquiera que esté por armar reglas de bloqueo: una coincidencia de IP o de dominio no es concluyente por sí sola.

Sobre quién está detrás, Microsoft Threat Intelligence lo redacta como evaluación y no como sentencia: este acceso inicial «lo usa un abanico de actores de amenazas», entre ellos Storm-3121 —cuya actividad deriva en extorsión de ShinyHunters y Falcon— y Storm-3032, un desprendimiento del grupo BlackFile que hoy opera bajo la marca Helix.

Qué hacer, según quién seas

Si sos usuario

• Ninguna área de soporte legítima te va a apurar por teléfono para que configures una passkey. Cortá y volvé a llamar vos por el canal interno de siempre.
• Revisá tus métodos de inicio de sesión y borrá los que no reconozcas. Un teléfono ajeno o una app autenticadora que no registraste es la señal.
• Si sospechás que entraste a un sitio falso: cerrá todas las sesiones activas, no solo cambies la contraseña. El paso a paso por servicio, con los plazos de cada uno, está en la nota sobre el token de sesión robado.
• Desconfiá de cualquier pedido de escribir un código que te dictan por teléfono, aunque la página donde lo escribís sea la de Microsoft. Ese es precisamente el truco del código de dispositivo.

Si administrás el entorno

• Lo primero, porque es gratis y cierra la rama más difícil de detectar: Microsoft recomienda «bloquear los flujos de código de dispositivo y de transferencia de autenticación mediante Acceso Condicional, salvo donde exista una necesidad de negocio explícita». Es un interruptor, y desactiva justo el camino que corre sobre la página legítima.
• Del mismo bloque, y a medida de una PyME: entrenar a la gente contra el phishing de voz y de correo que apunta al MFA y a la inscripción de passkeys, y ofrecer un canal verificado para reportar pedidos de autenticación no solicitados. Si el empleado tiene a quién avisar, la llamada se muere ahí.
• Revisar los métodos de autenticación recién registrados en usuarios con inicios de sesión inusuales y quitar los no autorizados tras validar a la persona. El procedimiento está en su documentación de Entra.
• Contención: revocar sesiones activas y refresh tokens, restablecer credenciales, eliminar los métodos de autenticación registrados por el atacante, eliminar las reglas de buzón que haya creado y exigir un nuevo registro seguro de los métodos.
• Reducción de riesgo: MFA resistente a phishing por Acceso Condicional, y exigencia de dispositivo administrado y conforme para Exchange, SharePoint y las apps con privilegios de Graph.

Preguntas que quedan dando vueltas

Ya di el código por teléfono. ¿Qué hago en los próximos diez minutos?

En este orden: cerrá todas las sesiones activas de la cuenta, cambiá la contraseña, y recién ahí entrá a los métodos de inicio de sesión y borrá cualquiera que no hayas registrado vos. El orden importa: si quitás el método pero dejás la sesión viva, el atacante sigue adentro; y si solo cambiás la contraseña, el factor que él se agregó sigue sirviéndole. Si es una cuenta del trabajo, avisá a quien administre el entorno en el momento, porque del lado del tenant hay que revocar también los refresh tokens y revisar si te crearon reglas de buzón.

¿Un antivirus me protege de esto?

Parcialmente, y conviene saber dónde está el límite. La protección web de una suite de seguridad puede bloquear el sitio falso de la rama AiTM, si esa dirección ya figura en sus listas. Pero no puede hacer nada contra la rama del código de dispositivo, porque ahí la página es la legítima de Microsoft y el permiso se lo das vos; ni contra el tercer patrón, donde el atacante ya tenía su método registrado de antes. Es una de las tres ramas y encima condicional: por eso esta nota no te vende una suite como solución. Lo que corta el ataque es revisar los métodos de inicio de sesión, revocar sesiones y no aceptar apuros telefónicos.

¿Esto le pasa solo a empresas grandes?

El informe describe intrusiones en organizaciones y no publica un desglose por tamaño ni por país, así que cualquier afirmación sobre víctimas en la región sería inventada. Lo que sí es trasladable es el mecanismo: la línea de tiempo del informe muestra el MFA resuelto por AiTM porque el factor en uso no era resistente a phishing, y eso alcanza a cualquier cuenta de Microsoft 365 que se valide por SMS o por aplicación autenticadora.

¿Te llamaron alguna vez «del soporte»? Contanos abajo ⬇️

Fuentes

• Microsoft Security Blog — «Passkey-themed social engineering leads to identity and cloud compromise», 9 de septiembre de 2026. Las citas del cuerpo son traducción propia del original en inglés.
• Microsoft Learn — gestión de los métodos de autenticación de un usuario en Microsoft Entra.