← Volver al blog de ciberseguridad

Te llaman de soporte, registras un passkey y el que queda activo es el del atacante

Por Thilina Manana · COO y Director Técnico de Seguridad hard2bit · Publicado: 03 de agosto de 2026 · Actualizado: 03 de agosto de 2026
Pink vishing secuestro passkey

Un grupo de extorsión llamado Pink (rastreado como O-UNC-066) llama por teléfono a empleados fingiendo ser el soporte interno y les guía para registrar un passkey nuevo en Microsoft 365. La web es falsa, el operador va en directo y, al terminar, la credencial que queda activa en la cuenta real es la del atacante. No se rompe la criptografía FIDO2: se abusa del momento del alta, que gobierna Conditional Access y la verificación en el servicio de ayuda, no el estándar del passkey.

Durante meses el mensaje ha sido que el passkey es la credencial que el phishing no puede robar. En lo criptográfico es cierto: un passkey FIDO2 está atado al dominio legítimo y no viaja por un formulario falso. Pero la campaña que documentó Okta Threat Intelligence a partir de abril de 2026 encontró el punto por donde colarse. No ataca el passkey; ataca el instante en que se da de alta.

El método no tiene nada sofisticado: una llamada de teléfono y una web clonada. Alguien llama, dice ser del soporte de la empresa y pide dar de alta un passkey nuevo por motivos de seguridad. Al otro lado hay un operador que conduce la conversación en tiempo real. Cuando el empleado cree que ha terminado, el passkey activo en su cuenta de Microsoft 365 responde a quien llamó, no a él.

Quién está detrás y a quién telefonea

Okta sigue a este actor como O-UNC-066 y observa la campaña desde abril de 2026 contra organizaciones de alimentación y bebidas, tecnología, sanidad, automoción, construcción y aviación. Palo Alto Networks Unit 42 rastrea al mismo grupo bajo el nombre Pink, una marca de extorsión que, según recogen The Hacker News y BleepingComputer, se sitúa en la órbita de The Com, la red criminal difusa a la que se han vinculado antes grupos como Scattered Spider, ShinyHunters y LAPSUS$.

El grupo roba datos y extorsiona; cifrar no entra en sus planes. Publicó un sitio de filtraciones a finales de mayo de 2026 para presionar a las víctimas, y sus comunicaciones de extorsión —enviadas desde cuentas de Teams y correo ya comprometidas— suelen conceder un plazo corto para pagar. Esas cifras y plazos son afirmaciones del atacante y conviene tratarlas como tales, no como hechos verificados.

Cómo se ejecuta la llamada

El pretexto: un aviso legítimo convertido en excusa

El gancho funciona porque encaja con algo que las empresas ven a diario. Microsoft lleva meses empujando el paso a passwordless con campañas de registro que invitan al usuario a darse de alta de un passkey durante el inicio de sesión, y en ciertos casos ese aviso aparece de forma predeterminada. Recibir una llamada que insiste en configurar un passkey no suena extraño: suena a la política que la organización acaba de activar.

El kit y la web clonada

El operador dirige a la víctima a una dirección que incluye la palabra passkey en el dominio y reproduce el portal real de registro de Entra con la marca de su propia empresa. La página no es estática: el atacante adapta las pantallas según el segundo factor que use la cuenta —código por SMS, aplicación de autenticación o notificación push— porque hay una persona pilotando cada paso. Ese control en directo es lo que hace que el vishing esquive las defensas automáticas: no hay un patrón fijo que un filtro pueda reconocer.

El registro del passkey del atacante

Con la contraseña y el código de un solo uso que la víctima acaba de teclear, el atacante inicia sesión en la cuenta real de Microsoft 365 y añade su propio passkey FIDO2 a través del portal legítimo de información de seguridad. A partir de ahí ya no necesita a la víctima. Tiene una credencial passwordless registrada a su nombre dentro del inquilino, indistinguible a primera vista de cualquier alta correcta.

Por qué los controles habituales dejan pasar el registro

La garantía de FIDO2 cubre la autenticación, no la ceremonia de alta. Cuando alguien registra un método de autenticación nuevo, la legitimidad de ese registro la determinan la política de Conditional Access del inquilino y, antes que nada, la verificación humana de quién pide el cambio, no el estándar del passkey. Ahí es donde la campaña mete la mano.

El segundo problema es la persistencia. Como el passkey del atacante es una credencial dada de alta por la vía correcta, el acceso no se cae con un cambio de contraseña ni con una revocación de sesiones, las respuestas reflejas de casi cualquier protocolo. Mientras el método de autenticación siga registrado, la puerta sigue abierta.

El tercero es la ausencia de ruido. No hay malware que un EDR pueda cazar ni un exploit que deje traza en un IDS. Lo que hay es un inicio de sesión legítimo seguido de un alta de credencial impecable. Para detectarlo hay que mirar el sitio adecuado.

Detección: dónde queda el rastro

El registro deja huella en los logs de auditoría de Entra. La señal de partida es un evento de alta de método de autenticación —passkey o FIDO2— asociado a un usuario, sobre todo si llega desde un dispositivo o una ubicación que esa cuenta no había usado y poco después de un inicio de sesión marcado como de riesgo. Correlacionar ese registro con los logs de inicio de sesión suele reconstruir la secuencia completa: sesión desde una IP anómala y, minutos más tarde, credencial nueva.

Conviene alertar de forma específica sobre altas de passkey que ocurran fuera de dispositivos gestionados o fuera de las campañas de registro previstas, y revisar si la cuenta afectada recibió una llamada o un contacto por soporte en esa franja. Cuando el equipo de detección no cubre esta ventana, el hueco es justo el que la campaña explota; contar con capacidad de búsqueda proactiva de amenazas (threat hunting) sobre los eventos de identidad puede marcar la diferencia entre detectarlo en horas y descubrirlo cuando llega la nota de extorsión.

Cómo cerrar el registro de credenciales

El control decisivo es tratar el alta de métodos de autenticación como una operación sensible y no como un trámite. Conditional Access permite aplicar una política a la acción de usuario «Registrar información de seguridad», de modo que solo se pueda dar de alta un método desde un dispositivo de confianza o cumpliendo una condición fuerte, y bloquearlo cuando Entra ID Protection detecta riesgo en el usuario o en la sesión.

Sobre esa base ayudan las fortalezas de autenticación, que definen qué métodos se admiten para completar una operación, y acotar quién puede autorregistrar passkeys mediante campañas de registro con alcance controlado en lugar de dejarlo abierto a toda la plantilla. Ninguna de estas piezas es nueva; lo que la campaña demuestra es el coste de tenerlas sin afinar.

La capa que Okta sitúa en el centro es humana: verificar la identidad de quien contacta con el servicio de ayuda y no ejecutar cambios de credencial a partir de una llamada entrante. El mensaje al usuario es igual de directo —el equipo de IT no telefonea para guiar el alta de un passkey— y forma parte del mismo trabajo de defensa de la identidad que sostiene el resto del inquilino. Es el mismo terreno de otras tomas de cuenta en Microsoft 365, desde el robo de tokens con AiTM hasta el phishing por código de dispositivo, y del abuso de la confianza que también aprovecha el fraude del CEO con voz clonada.

En clave normativa, la gestión de identidades y accesos y la notificación de incidentes entran de lleno en el alcance de NIS2 y DORA para las entidades sujetas. Un secuestro de cuenta con credencial persistente puede ser un incidente reportable según el marco aplicable, con la dirección respondiendo de que existían los controles razonables. Endurecer el alta de credenciales y tener lista una respuesta a incidentes que sepa retirar métodos fraudulentos forma parte de esa diligencia. Si el inventario de cuentas de servicio y credenciales automáticas aún no está bajo control, el problema se extiende a las identidades no humanas.

Lo que este caso deja claro

El fallo no está en el passkey, sino en el paso humano que ata una credencial a una cuenta. El modelo sin contraseña quita la contraseña, no el mostrador de recepción: alguien sigue decidiendo, en algún momento, que ese método de autenticación entra. Mientras ese momento dependa de una llamada de teléfono sin verificar, el atacante no necesita romper nada. Le basta con que le abran.

La pregunta operativa que deja la campaña Pink es concreta y medible: quién puede añadir una credencial en el inquilino, desde dónde y después de qué comprobación. Una organización que sepa responderla con una política y un registro, y no con la buena fe de quien atiende el teléfono, ha cerrado el vector sin depender de quién descuelgue.

Este artículo describe la campaña con fines defensivos y de detección. Las referencias a Conditional Access y a los eventos de auditoría de Entra deben validarse en un entorno de pruebas y adaptarse a la configuración de cada inquilino antes de aplicarse en producción. Las cifras y plazos difundidos por el grupo de extorsión se citan como afirmaciones no verificadas del atacante; las atribuciones a grupos pueden evolucionar a medida que avance la investigación.

Preguntas frecuentes

¿El passkey deja de ser seguro con este ataque?

No. La criptografía FIDO2 sigue intacta y el passkey continúa atado al dominio legítimo. Lo que se abusa es el proceso de alta de la credencial, que gobiernan Conditional Access y la verificación de identidad en el servicio de ayuda, no el estándar del passkey.

¿Cómo entra el atacante si no roba el passkey de la víctima?

Consigue la contraseña y el código MFA por teléfono y a través de una web falsa, inicia sesión en la cuenta real de Microsoft 365 y registra su propio passkey FIDO2 en el portal legítimo de información de seguridad. A partir de ahí ya no necesita a la víctima.

¿Por qué el acceso persiste tras cambiar la contraseña?

Porque el passkey del atacante es una credencial dada de alta por la vía correcta. Cambiar la contraseña o revocar sesiones no la elimina: hay que enumerar los métodos de autenticación de la cuenta, retirar el que no se reconozca y revocar tokens y sesiones.

¿Qué señal delata el ataque en Entra?

Un evento de alta de método de autenticación de tipo passkey o FIDO2 desde un dispositivo o ubicación nuevos, especialmente si ocurre poco después de un inicio de sesión marcado como de riesgo. Correlacionar ese registro con los logs de inicio de sesión reconstruye la secuencia.

¿Qué política corta el vector?

Una política de Conditional Access sobre la acción de usuario «Registrar información de seguridad» que exija dispositivo de confianza o un método fuerte para dar de alta credenciales, con bloqueo por riesgo mediante Entra ID Protection y fortalezas de autenticación que acoten los métodos admitidos.

¿Sirve la formación del usuario?

Sí, como capa complementaria. El mensaje debe ser inequívoco: el equipo de IT no llama por teléfono para guiar el alta de un passkey. Ante una llamada así, lo correcto es colgar y verificar por un canal oficial antes de tocar ninguna credencial.

¿Afecta esto a NIS2 y DORA?

La gestión de identidades y accesos y la notificación de incidentes entran en el alcance de ambos marcos para las entidades sujetas. Un secuestro de cuenta con credencial persistente puede ser un incidente reportable, y la dirección responde de que existieran controles razonables sobre el alta de credenciales.

¿Qué hago si sospecho un registro fraudulento?

Aislar la cuenta, enumerar y eliminar los métodos de autenticación no reconocidos, revocar sesiones y tokens, revisar reglas de reenvío de correo y aplicaciones OAuth conectadas, y activar el procedimiento de respuesta a incidentes para acotar el alcance dentro del inquilino.