Empieza por aquí: cuando quien dice ser de TI te pide «actualizar la passkey ahora mismo», el peligro no es que hayan copiado la clave privada. Es que les has entregado un inicio de sesión vivo. Los kits de adversario en el medio se llevan la sesión. En la ruta del código de dispositivo, la página puede ser un anfitrión real de Microsoft. Cambiar la contraseña cubre solo esa capa. No retira un autenticador que ya inscribieron. En este dispositivo puedes contrastar la ruta de la llamada, el hostname de la barra de direcciones y si Información de seguridad creció un aparato que no es tuyo —no la frase «yo ya uso Passkey».
Responde a la intención de búsqueda en una frase
Una passkey, según WebAuthn, deja la clave privada en este dispositivo o en un llavero sincronizado y la ata al origen del sitio de confianza. Un anfitrión de inicio de sesión falso no puede exportar esa clave. Ahí «resistente al phishing» es verdad. Donde deja de serlo: te apresuran a terminar un inicio de sesión y el token de sesión aterriza con ellos; o escribes un código que te dictaron en una página genuina de Microsoft, y el token se emite a un cliente que controlan.
Esta nota es para quien ya registró una clave de acceso y aun así recibe una llamada o un SMS que dice «actualízala», y para desarrolladores y operaciones que tienen que explicar por qué una Passkey no es un salvoconducto contra el vishing. No sustituye el escrito de incidente de Microsoft, ni es una guía para apagar las passkeys. Lo que te llevas es qué capa cubre el guion, qué capa roban la sesión y el código de dispositivo, por qué cambiar la contraseña no basta, y qué puedes contrastar en este equipo cuando cuelgas.
Qué capas separó este aviso
El 9 de septiembre de 2026, Microsoft Security Research publicó un informe en inglés. Siguen intrusiones de identidad en la nube que aún están activas: inicios de sesión anómalos, métodos de autenticación que el actor añadió, tráfico intenso de Microsoft Graph, descargas de SharePoint y OneDrive, y recolección de buzones por API REST. El escrito dice que esta actividad se observa desde mayo de 2026.
No abre con un correo de phishing pulido. Abre con una llamada o un SMS al móvil personal. Quien llama se hace pasar por la mesa de ayuda de la empresa y fabrica urgencia: la passkey, la autenticación multifactor o el inicio de sesión único hay que actualizarlos ya o la cuenta se corta. El enlace suele llegar en un segundo SMS al mismo número personal. Microsoft lo dice sin rodeos: aunque el guion hable de Passkeys, registrar una clave de acceso casi nunca es el objetivo real. El cuento sirve para empujarte a una de dos rutas técnicas: phishing de adversario en el medio (AiTM) o autorización por código de dispositivo.
La ruta AiTM captura credenciales y tokens de sesión. En la del código de dispositivo, convencen a la víctima de escribir un código corto en la propia página de autenticación de Microsoft; el token se emite a un cliente que controla el actor, así que no necesitan la cookie del navegador. Cualquiera de las dos puede dejar que el acceso posterior se salte la MFA. Si el enlace se abre en un móvil personal que no está en Defender, la telemetría del endpoint puede estar casi vacía. En esos casos, el recuerdo de la llamada o del SMS suele ser la primera —y a veces la única— prueba de cómo empezó la intrusión.
La infraestructura está hecha para parecer familiar. Entre los anfitriones temáticos del escrito están passkeyhelpdesk.com, setupmypasskey.com, add-passkey.com y secure-passkey.com, más el nombre de la empresa metido en un subdominio, por ejemplo contoso.add-passkey.com. El mismo nombre puede colgar también de un anfitrión con tema SSO como integratedsso.com. Los dominios pueden entrar en servicio horas después del registro, así que la ventana de bloqueo es corta. En algunos casos el actor usa además una cuenta de un compañero ya comprometida para mandar el mismo «actualiza la passkey» por Teams, y apila la confianza interna encima de la llamada.
Microsoft liga el acceso inicial a varios clústeres, entre ellos Storm-3121 y Storm-3032. Storm-3121 suele alimentar las extorsiones de ShinyHunters y Falcon. Storm-3032 se describe como una escisión de BlackFile que ahora opera bajo la marca Helix. Eso es ecología, no una prueba de que cada «llamada de TI» que recibes sea la misma banda. Lo que cabe en una nota de relevo es el guion más las dos rutas técnicas, no el nombre de una banda.
La passkey para un anfitrión falso. No para una sesión que entregas
Leer «resistente al phishing» como «a mí no me van a hablar hasta que caiga» suelda la capa de la credencial con la de la sesión. Una passkey queda atada al origen del sitio en el registro. Un clon de la página de inicio de Microsoft en otro anfitrión sigue sin poder extraer la clave privada que guardaste para login.microsoftonline.com. Esa ventaja frente a reutilizar contraseñas es real. No hay que deshacerla.
Una línea de tiempo de la investigación marca dónde se acaba la ventaja. En T+0 minutos, un contexto no gestionado toca OfficeHome y recibe el error 50074, que pide un segundo factor. En T+1, la MFA termina —el escrito habla de adversario en el medio más MFA no resistente al phishing— y el 50140 interrumpe «mantener la sesión iniciada». En el mismo minuto la autenticación tiene éxito y nace una sesión. Durante la hora siguiente, esa misma sesión abre My Apps, el perfil, la gestión de aprobaciones e Información de seguridad, y recorre SharePoint y Outlook por Graph. Con la sesión viva, ya no necesitan tu passkey.
Así que «yo ya uso Passkey» solo sostiene una afirmación estrecha: un anfitrión falso difícilmente exportará esa clave privada. No sostiene: no te van a apurar a meter una contraseña o un SMS en una página clon; un kit de adversario en el medio no puede llevarse el token que acaba de acuñar ese inicio; Información de seguridad no va a crecer su autenticador. Esas últimas frases piden otra prueba: si el hostname que abriste es un anfitrión oficial de inicio, y si Información de seguridad muestra un dispositivo que no añadiste.
No uses una cuenta de trabajo real para «probar» el enlace o el código de dispositivo de la llamada. Basta una línea desechable: cuelga y llama por el canal de TI que tu empresa publicó por escrito. Contrastas la ruta de la llamada y la barra de direcciones, no les entregas otro inicio de sesión vivo.
Por qué el código de dispositivo funciona en un anfitrión real
El adversario en el medio todavía tiene que levantar una página que parezca el inicio de sesión. El código de dispositivo quita esa capa. El flujo oficial es: un cliente muestra un código corto; abres la página de inicio por dispositivo de Microsoft en el navegador; escribes el código; eso aprueba que «ese cliente» actúe como tú. La página es real. El certificado es real. La barra de direcciones aguanta el «¿es Microsoft?». El truco se mueve a otra pregunta: quién generó este código, y qué aplicación recibe la autorización.
La segunda secuencia de ataque del escrito es exactamente esa: tras el guion de la passkey, la víctima escribe un código que le dio el actor en una página de autenticación legítima, y el token se emite a un cliente que controlan. Después reutilizan ese token, enumeran el directorio y los archivos, y se saltan tanto el robo de cookies como otro reto de MFA. Para quien está entrenado a mirar el candado y el hostname, esto cuesta más pillarlo en el momento: la capa que te enseñaron a inspeccionar está en verde.
Así que «la barra de direcciones es Microsoft» solo sostiene: no escribiste una contraseña en un clon tipo add-passkey.com. No sostiene: este código pertenece a tu propio portátil; después de aprobarlo, el token se queda en tu navegador. Un código que te dictan por teléfono, por SMS o por el chat hay que tratarlo por defecto como su cliente, no como «página oficial, luego es seguro».
Por qué cambiar la contraseña no cubre un autenticador que ya inscribieron
Cuando entran, el primer movimiento casi nunca es seguir hojeando archivos. Es escribir su propio método de autenticación en tu identidad. El escrito lista un número nuevo, una app autenticadora o un token de contraseña de un solo uso por software. Una muestra real de auditoría del 4 de septiembre de 2026 muestra un registro recién añadido cuyo nombre de dispositivo es NO_DEVICE, cuya etiqueta es SoftwareTokenActivated y cuyo campo de función hash es hmacsha1. Eso no es «pusieron otra contraseña». Es «el próximo segundo factor lo pueden completar ellos».
La remediación de Microsoft ante un compromiso confirmado es una secuencia: revocar sesiones activas y tokens de actualización, restablecer credenciales, borrar los métodos que inscribieron, quitar reglas de buzón que añadieron y volver a registrar con un método resistente al phishing. Cambiar la contraseña y saltarse Información de seguridad deja una llave que ya encajaron. Una tercera secuencia de investigación muestra que pueden volver días después con un PhoneAppOTP que inscribieron antes y recorrer Graph con una automatización en Node.js: contraseña correcta, segundo factor «pasado», y el factor es suyo.
El comprobador de contraseñas local contrasta la cadena con una lista pública de contraseñas filtradas habituales. La contraseña no se sube, y la comprobación no es un cruce Have I Been Pwned de toda la web. Puede decirte que la cadena es demasiado común. No puede decirte que Información de seguridad creció una fila NO_DEVICE, ni demostrar que la llamada era falsa. Una contraseña débil y una sesión secuestrada no son la misma columna de datos. No sustituyas una por la otra.
| Lo que ves | Qué sí sostiene | Qué no sostiene |
|---|---|---|
| Ya registré una passkey | Un anfitrión falso difícilmente exportará esa clave privada | Nadie puede apurarte a entregar un inicio de sesión vivo |
| La barra de direcciones es un anfitrión de Microsoft | No escribiste una contraseña en un clon | La autorización del código de dispositivo es para tu propio cliente |
| Quien llama nombró la empresa y un departamento | Hicieron reconocimiento de fuentes abiertas | La llamada usó un canal de retorno que tu empresa verificó |
| Cambié la contraseña | La capa de la contraseña se rotó | Los autenticadores extraños y las sesiones sin revocar están muertos |
| Abrí el SMS en el móvil; el PC del trabajo se ve limpio | El registro de endpoint de este puesto puede estar vacío | No se estableció ninguna sesión de identidad en la nube para ellos |
| Un compañero también me escribió por Teams para actualizar la Passkey | El mensaje salió de una cuenta interna con sesión iniciada | Esa cuenta la sigue controlando la persona que nombra |
Cuando cuelgas, qué capas puedes contrastar ahora
Una consigna no es prueba. Contrasta solo lo que controlas: si la llamada usó un canal que ya confías, el hostname que vas a abrir, y si Información de seguridad creció un dispositivo. No uses una cuenta de producción para abrir el enlace de la llamada como experimento.
- Cuelga. Contacta con TI por el portal de tickets, el sitio interno o el número de retorno que tu empresa publicó por escrito. No llames al número que acaba de sonar. No pulses el enlace del SMS. Microsoft pide a las empresas que den al personal un canal verificado para denunciar peticiones de autenticación no solicitadas.
- Si ya abriste el enlace: mira solo el hostname. Un nombre de empresa en el subdominio con un sufijo como
add-passkey.com,setupmypasskey.comosecure-passkey.comno es un anfitrión de inicio de Microsoft. No escribas ahí una contraseña, un código SMS ni una confirmación de passkey. - Si alguien te pide «escribir un código en el sitio oficial»: pregunta qué aplicación y qué dispositivo lo generaron. Un código que te dictó otra persona es su cliente. La página oficial de código de dispositivo puede ser genuina y la autorización aterrizar igual en su app.
- Cuando inicies sesión por una ruta en la que confías, abre Información de seguridad / My Sign-Ins y lee cada método. Números, autenticadores y tokens de software de más —sobre todo un nombre de dispositivo que no es tu teléfono— se revocan y se borran por el proceso del administrador. No te quedes en el cambio de contraseña.
- Cuando tengas que entregar un secreto corto de un solo uso a un compañero que ya verificaste, cambia a un canal de texto cifrado. Abre Burn-Link y escribe un canario desechable como
canary-fp-20260921-passkey-lure. Abre Network en las herramientas para desarrolladores y marca Preserve log. Tras generar el enlace, busca ese canario: el cuerpo dePOST /secretsdebería llevar texto cifrado, caducidad y número de lecturas, no el texto en claro ni la clave que va tras#. La forma del enlace ess.html?id={id}#{key}. RFC 9110 indica que el URI de destino de la petición no incluye el fragmento.
Los cuatro primeros pasos cierran el canal que toma la identidad. El quinto cubre otro error habitual: capturar «el código que pidió TI» o una contraseña temporal y soltarla en el chat. Los alojadores de imágenes y los álbumes guardan píxeles y, a menudo, OCR. La nota anterior ya lo cubrió. Burn-Link solo sube texto cifrado; la clave se queda detrás de #. No mezcles los dos canales: no captures primero al chat y luego pegues la URL completa del Burn-Link en la misma imagen.
No pongas el enlace completo y el texto en claro en el mismo camino. Un código de dispositivo dictado por teléfono, una captura en el chat y la cadena entera s.html?id=…#… son tres superficies de fuga distintas. Si la llave y la cerradura viajan en el mismo mensaje, la almohadilla ya no protege a quien pueda ver ese mensaje.
Tres formas de leer de más «yo tengo Passkey»
Primero, leer resistente al phishing como resistente a la ingeniería social. Una passkey está atada al origen. Eso apunta a una página de inicio falsa que intenta exportar la clave privada. Una llamada, un SMS o un chat interno pueden rodear esa capa y dejarte en un adversario en el medio o en un código de dispositivo. La propia lista de mitigación de Microsoft pone la formación contra el phishing de voz y de correo junto a «imponer MFA resistente al phishing», y también dice bloquear el flujo de código de dispositivo cuando no lo necesitas.
Segundo, leer «la página es oficial» como «la autorización es mía». La página de código de dispositivo puede ser un anfitrión real. El icono del candado no te dice a quién se emite el token. La prueba es de dónde salió el código: un aviso en tu propio dispositivo y un número que te dictó alguien no son el mismo acontecimiento.
Tercero, leer el cambio de contraseña como el cierre. Contraseña, sesión, autenticadores que inscribieron y reglas de reenvío del buzón son interruptores distintos. El escrito pide tratarlos juntos. Generar una contraseña nueva en local solo cubre los servicios que aún usan contraseña: abre el generador de contraseñas —listo para usar, longitud 6–128, 16 por defecto, aviso por debajo de 8, el cálculo ocurre en el navegador, no se sube nada—. Eso no revoca sesiones. No borra un método que no inscribiste.
Preguntas frecuentes
Ya tengo una passkey registrada. ¿Esta llamada puede funcionar igual?
Sí, y casi nunca porque hayan copiado la Passkey. El guion usa la clave de acceso como pretexto. Lo que buscan es la sesión que captura un kit de adversario en el medio, o el código de dispositivo que escribes en un anfitrión real de Microsoft para su cliente. La passkey está ligada al origen del sitio de confianza. Eso impide que una página falsa exporte la clave privada. No impide que autorices su aplicación.
Si la barra de direcciones parece Microsoft, ¿puedo introducir el código de dispositivo?
La página de código de dispositivo está pensada para ser un anfitrión genuino de Microsoft. El riesgo no es «¿es un sitio falso?». Es «quién generó este código y qué aplicación recibe la autorización». Un código que te dictan por teléfono o por SMS autoriza su cliente, no tu propia sesión del navegador.
Si cambio la contraseña, ¿se acaba el incidente?
No. Microsoft escribió que, una vez dentro, inscriben su propio número, autenticador o token de software. Cambiar la contraseña sin revocar sesiones ni borrar esos métodos deja un factor que ya controlan. Los dispositivos de más en Información de seguridad hay que quitarlos con los pasos oficiales.
Un compañero me pide un código de un solo uso por el chat. ¿Puedo mandar una captura?
No sueltes un OTP vivo ni un código de dispositivo en el álbum del chat. Cifra el texto corto en esta pestaña con AES-256-GCM y envíalo por Burn-Link, con la clave detrás de #. La forma es s.html?id={id}#{key}. Crear y leer están listos para usar; sin cuenta. Confirma a la persona por un canal que tu empresa ya haya publicado, no por la llamada que acaba de decir que es TI. El material de más de 32 KB pertenece a la caja de cifrado: un archivo de hasta 5 GB, salida .lock / .enc.
Pasa un secreto corto por un canal listo para usar
Si quieres una página que deja por escrito el límite de cálculo, para practicar «devuelve una contraseña, sáltate la captura», abre el Burn-Link de FastPwd. Sin registro. Escribe el canario de arriba, deja el recuento de lecturas en 1, genera el enlace y contrasta Network como en el quinto paso: el cuerpo debería llevar solo texto cifrado, no el texto en claro ni la clave que va tras la almohadilla. Usa este camino solo cuando el compañero ya esté verificado. No captures antes. No le dictes un código de dispositivo a un desconocido al teléfono.
Si un historial de chat o un ticket todavía apila teléfonos y números de documento, pasa un enmascarado por reglas en la limpieza de privacidad antes de decidir si envías. La limpieza se queda en este dispositivo. El texto de origen no se sube como dato de negocio y no se escribe en analytics. En los sitios que aún usan contraseña, genera una única en local. No reutilices la cadena que te apuraron a escribir. El comprobador de contraseñas solo responde «¿es una contraseña débil pública habitual?». No responde «¿esa llamada era falsa?».
La próxima vez que alguien diga «actualiza la passkey ahora», quédate con tres frases. Primera: la Passkey del guion suele ser solo el pretexto; buscan una sesión o una autorización por código de dispositivo. Segunda: un anfitrión real no te impide emitir un token a la aplicación de otro. Tercera: el cierre es Información de seguridad más revocar sesiones, no un cambio de contraseña solo. Esas tres frases sí pueden ir en una nota de relevo. «Activé las passkeys, así que puedo ignorar la llamada» no.
Lecturas relacionadas
Después de recortar una contraseña hacia un alojador de capturas, un hash de acceso no cubre el texto OCR ni el Image ID: véase Por qué el texto OCR y el Image ID de un alojador de capturas son más peligrosos que un hash de contraseña. Un enlace de un solo uso puede demostrar que el servidor borró el texto cifrado; no puede demostrar que el destinatario no hizo una captura: véase Por qué un enlace de un solo uso puede demostrar que el servidor borró el texto cifrado, pero no que el destinatario no hizo una captura. Por qué lo que va detrás de # no entra en HTTP: véase Por qué el hash de una URL puede guardar una clave, y cuándo esa protección falla.