Resumen de la publicación
Microsoft documentó una campaña activa desde mayo de 2026 en la que los atacantes llaman por teléfono haciéndose pasar por la mesa de ayuda, dicen que hay que actualizar la passkey y terminan sacando gigabytes de SharePoint, OneDrive y Exchange Online. En ninguna de las intrusiones se registró una passkey ni se rompió la criptografía.
Lo que se llevaron fue la sesión y el registro de métodos de autenticación, que son dos cosas distintas del inicio de sesión y que casi nadie mira. Acá va qué protege realmente una passkey, qué no, y la lista concreta de lo que revisaría el lunes en un tenant de Microsoft 365.
Vengo escuchando hace meses una frase que me pone incómodo: «nosotros ya estamos con passkeys, eso ya está resuelto». La entiendo, y las passkeys son lo mejor que le pasó a la autenticación en veinte años.
Pero el 9 de septiembre Microsoft publicó el análisis de una campaña que me parece el mejor material didáctico del año para explicar por qué esa frase es peligrosa.
Organizaciones con passkeys en el medio, y aun así les vaciaron el OneDrive.
Lo que pasó, en criollo
Microsoft Threat Intelligence viene siguiendo esto desde mayo de 2026, con varios grupos del mismo ecosistema de extorsión repitiendo el mismo libreto.
El arranque no tiene nada de técnico. Es un llamado o un SMS al teléfono personal del empleado, alguien que dice ser de la mesa de ayuda de su propia empresa, y una urgencia: hay que actualizar la passkey, el MFA o la configuración de SSO ya mismo o te quedás sin acceso.
El link lleva a una página calcada de la de inicio de sesión de Microsoft, con un detalle de oficio: el nombre de la empresa víctima va en el subdominio, del estilo contoso.add-passkey[.]com.
Y acá está la frase del informe que debería cerrar la discusión: «a pesar del uso frecuente de señuelos con temática de passkeys, registrar una passkey no suele ser el objetivo real del actor».
La passkey es el disfraz, no el blanco. Nadie intentó enrolar una.
Qué se rompió de verdad, y qué no
La criptografía no se rompió. Ni cerca.
Una passkey es un par de claves criptográficas donde la privada nunca sale del dispositivo, y está atada al dominio para el que se creó.
Eso es lo que quiere decir «resistente a phishing»: si el navegador está parado en contoso.add-passkey[.]com, no existe manera de que le entregue a esa página una firma válida para login.microsoftonline.com. No es que sea difícil, es que el protocolo no lo contempla.
Por eso el proxy del atacante no pidió passkey. Pidió usuario, contraseña y un segundo factor de los otros.
La sesión sí, y esa es la que importa
La técnica principal fue adversary-in-the-middle: una página intermediaria que le muestra al usuario el login real, le pasa lo que escribe a Microsoft y se queda con lo que Microsoft devuelve.
Lo que devuelve es un token de sesión, y un token es al portador. No pregunta quién sos ni cómo te autenticaste: el que lo tiene, es vos.
Una vez que el token está del otro lado, el método de autenticación dejó de existir como control. Ya se usó, ya cumplió, ya pasó.
Esto es exactamente el mismo problema estructural que comentamos cuando Chrome activó Device Bound Session Credentials: mientras la sesión sea un papelito que vale por sí solo, reforzar la puerta de entrada tiene un techo.
El device code flow, que es el que me preocupa de verdad
El flujo de código de dispositivo existe para autenticar cosas sin teclado (una pantalla de sala): muestra un código y vos lo escribís en una página legítima de Microsoft desde el celular.
El atacante te da el código y vos lo aprobás. Te autenticás en el sitio real, con el método más fuerte que tengas, passkey incluida, y el token que se emite al final va a parar a la aplicación del atacante.
No hay cookie robada ni página falsa. Hay una autorización perfectamente válida otorgada al cliente equivocado.
Microsoft es directa en su propia documentación: el device code flow «es un método de autenticación de alto riesgo» y recomienda acercarse «lo máximo posible a un bloqueo unilateral».
Y después, el registro de métodos
Con la sesión en la mano, lo primero que hicieron no fue robar archivos. Fue registrar su propio método de MFA: un teléfono nuevo, una app de autenticación, un token OTP por software.
En los registros de auditoría eso aparece como una operación «Update user» que toca StrongAuthenticationPhoneAppDetail, con un dispositivo fantasma cuyo nombre es literalmente NO_DEVICE.
A partir de ahí el atacante ya no depende de la víctima: cualquier desafío futuro lo resuelve él.
Después vino lo aburrido y masivo: reconocimiento con Microsoft Graph y descarga sistemática de SharePoint Online y OneDrive con python-httpx como user agent, por debajo de los 1.000 archivos por hora para no disparar alarmas.
El piso de tu tenant es el método más débil que seguís aceptando
Habilitar passkeys es sumar un método. No es sacar los otros. Y mientras la contraseña y el OTP sigan habilitados, el atacante elige con cuál se autentica, no vos.
Hay un detalle de Entra documentado en las fortalezas de autenticación: el Acceso condicional se evalúa después de la autenticación inicial, así que exigir «MFA resistente a phishing» no impide que el usuario igual escriba su contraseña primero.
A esto se le suma el calendario de Microsoft, que hizo las passkeys el método por defecto en Entra ID a partir del 1 de septiembre de 2026 y deja de entregar SMS y voz el 1 de febrero de 2027.
Me parece la decisión correcta. También me parece que va a generar exactamente la sensación equivocada: miles de organizaciones que este trimestre se enteran de que «ya tienen passkeys» sin haber cambiado una sola política.
Qué revisaría el lunes en tu tenant
Primeras dos horas: mirar, sin tocar
- Registros de inicio de sesión, filtro Authentication Protocol = Device code. Si el resultado es cero o son cuatro dispositivos de sala, ya sabés que podés bloquearlo sin romper nada.
- Registros de auditoría de los últimos 90 días buscando «Update user» con cambios en
StrongAuthenticationPhoneAppDetailoStrongAuthenticationUserDetails. Todo método de MFA agregado que nadie pueda explicar es un incidente hasta que se demuestre lo contrario. - Revisar si tenés habilitados los registros de actividad de Microsoft Graph y la auditoría de buzones. Si no están, todo el reconocimiento que describe Microsoft es invisible para vos y no hay forense posible después.
- Listar los service principals con permisos de Graph del tipo
Mail.Read,Files.Read.AllyDirectory.Read.All, y preguntarse quién aprobó cada uno.
Esta semana: políticas, arrancando en modo solo informe
- Una política de Acceso condicional que bloquee device code flow y transferencia de autenticación para todos, con las excepciones documentadas y nada más.
- Blindar la acción de usuario «Registrar información de seguridad»: exigir fortaleza resistente a phishing, frecuencia de inicio de sesión «siempre», ubicación o dispositivo administrado, y bloqueo directo si el riesgo del inicio de sesión es alto. Registrar un factor nuevo tiene que ser más caro que usarlo.
- Revisar la política de métodos de autenticación y ver quién todavía puede registrar SMS, voz o token OATH por software. Ese es tu piso real, no la passkey que enroló el equipo de infraestructura.
- Limitar los dispositivos no administrados a sesión web sin descarga ni sincronización, y desactivar los enlaces de uso compartido anónimo en SharePoint y OneDrive. Es lo que convierte «entraron a una cuenta» en «se llevaron 5 GB».
Este trimestre: lo que cuesta plata o política interna
- Evaluar protección de tokens, que ata el token de sesión al dispositivo. Está disponible en general para aplicaciones nativas en Windows, iOS y macOS contra Exchange, SharePoint y Teams. Para navegador sigue en versión preliminar y solo contra Azure Resource Manager, así que no alcanza sola, pero es la dirección correcta.
- Confirmar que evaluación continua de acceso esté activa, sabiendo lo que hace y lo que no: revoca cerca del tiempo real (puede demorar hasta 15 minutos) y no cubre cuentas invitadas.
- Escribir el procedimiento de verificación de identidad de la mesa de ayuda antes de cualquier reseteo de credencial o MFA, y generar una alerta por cada reseteo iniciado desde la mesa de ayuda. El vector de esta campaña es el teléfono, no el navegador.
- Acordar de antemano cómo se contiene una cuenta: revocar sesiones y tokens de actualización, resetear credenciales, eliminar los métodos de autenticación que registró el atacante y revisar las reglas de buzón que haya dejado. Cambiar la contraseña sola no echa a nadie.
La criptografía nunca fue el eslabón débil
Las passkeys funcionaron. Tan bien funcionaron que el atacante ni se molestó en atacarlas: las usó de excusa para llevarte a un flujo donde no participan.
Lo que esta campaña deja en evidencia es que el inicio de sesión es apenas uno de los cuatro momentos donde se decide quién sos. Los otros tres son el registro del método, la sesión que se emite después y el procedimiento de recuperación cuando alguien llama diciendo que perdió el acceso.
Invertimos casi todo el presupuesto de seguridad en el primero, y el atacante trabaja tranquilo en los otros tres.
Si me tuviera que quedar con una sola cosa de este informe, es esta: el día que hiciste el proyecto de passkeys, ¿alguien miró también quién puede registrar un teléfono nuevo en una cuenta, y desde dónde?
En la mayoría de los tenants que me tocó revisar, esa respuesta es «cualquiera, desde cualquier lado, con lo que tenga a mano». Y ahí está la puerta.
