Resumen ejecutivo
Desde abril de 2026, un actor de amenazas identificado como O-UNC-066, que opera un sitio DLS con el nombre Pink (reportado como "CL-CRI-1147" por la Unidad 42 de Palo Alto Networks), ha desplegado un kit de phishing controlado por panel dirigido al proceso de inscripción de claves de acceso para clientes de Microsoft 365.
Okta ha observado que este grupo de actividades se dirige a organizaciones empresariales de los sectores de alimentación y bebidas, tecnología, sanidad, automoción, construcción y aviación. La principal motivación de los actores de amenazas es la extorsión de datos.
El atacante registra dominios que incorporan la palabra "passkey" como parte de un esquema de phishing activado por voz ("vishing"). Posteriormente, el atacante llama por teléfono a los usuarios objetivo para intentar persuadirlos de que deben registrar una nueva clave de acceso.
Los usuarios son redirigidos a un kit de phishing que imita fielmente el proceso de registro de clave de acceso de Microsoft. Parece estar diseñado para convencer al usuario objetivo de que está en proceso de registrar una clave de acceso con Microsoft, mientras que el atacante registra simultáneamente su propia clave de acceso en la cuenta de Microsoft del usuario objetivo.
Este pretexto llega en el momento oportuno: desde mayo de 2026, los administradores de Microsoft han podido crear campañas de registro de claves de acceso que recuerdan o “incitan” a los usuarios a registrarse para obtener claves de acceso al iniciar sesión, y en algunas circunstancias, estas incitaciones están activadas por defecto.
Los ciberdelincuentes han utilizado esta mejora de seguridad, que tenía buenas intenciones, como pretexto para abusar del proceso de registro y así lograr sus objetivos.
Nuestro análisis del kit de phishing reveló que no intenta gestionar la federación con proveedores de identidad de terceros como Okta. Posteriormente, no hemos observado ninguna vulneración directa de las cuentas de Microsoft.
No obstante, hemos publicado en una entrada de blog aparte consejos sobre cómo aplicar la resistencia al phishing al registro y la recuperación de autenticadores.
Análisis de amenazas
En la actividad maliciosa que observamos, el atacante crea subdominios específicos para cada objetivo que imitan las páginas de inicio de sesión de Microsoft Entra ID. Las páginas se personalizan utilizando la imagen de marca legítima de cada organización víctima. El estilo genérico de Microsoft se carga desde la red de distribución de contenido de Microsoft, mientras que los elementos de marca relevantes para cada organización víctima (logotipo y fondo) se preparan previamente por subdominio como parte de la configuración para cualquier objetivo determinado y se sirven desde el backend del kit de phishing.
Este kit no es un proxy transparente de tipo Adversary-in-the-Middle (AitM), uno de los tipos de kits de phishing más frecuentes diseñados para recopilar credenciales, tokens MFA y tokens de sesión. Se trata de un panel PHP controlado por un operador en el que un atacante guía a las víctimas a través de varias etapas de autenticación prácticamente en tiempo real mediante un mecanismo de sondeo de latidos de 1 segundo. El operador puede utilizar el kit para adaptar la experiencia del usuario a los requisitos de autenticación multifactor de cada víctima (TOTP, notificación push con coincidencia de número, OTP por SMS) durante la sesión. Este diseño operativo es coherente con las técnicas de vishing documentadas en la publicación del blog público de Okta de noviembre de 2025 titulada "Los kits de phishing se adaptan al guion de quienes llaman". El atacante puede controlar y ajustar en tiempo real qué páginas de phishing y notificaciones ve el usuario objetivo.
Es probable que el actor de amenazas utilice el kit para tomar el control de la cuenta del usuario y engañarlo para que apruebe el registro de una clave de acceso iniciada por el atacante.
Okta Threat Intelligence utilizó código derivado del kit de phishing para recrear el siguiente flujo, que se asemeja mucho al proceso de registro de clave de acceso para Microsoft Entra.
La primera página del kit de phishing (/gate) muestra un icono de carga de página mientras el kit de phishing realiza comprobaciones anti-análisis. La segunda página (/identify) solicita un nombre de usuario. En el momento de nuestro análisis, el kit de phishing no redirigía a un proveedor de identidad federado.
Figura 1. La página de inicio de sesión de Microsoft O-UNC-066, regenerada utilizando código extraído del kit de phishing.
La siguiente página (/password) le pide al usuario que ingrese una contraseña. Las credenciales capturadas se envían en una solicitud POST con una marca de tiempo y un ID a un panel de operador en /backend.php.
Figura 2. Página de desafío de contraseña O-UNC-066 de Microsoft, regenerada utilizando código extraído del kit de phishing.
Partimos de la base de que un operador de un kit de phishing (que puede ser una persona distinta a la que llama por teléfono) captura las credenciales del usuario objetivo en cuestión de segundos y las introduce en la página de inicio de sesión legítima de Microsoft para el inquilino objetivo.
El usuario objetivo ve entonces una página (/processing) que presenta otra pantalla de carga mientras el kit de phishing espera la siguiente instrucción del operador. Partimos de la base de que este pequeño retraso es necesario para que un atacante se autentique en la cuenta legítima de Microsoft del usuario utilizando las credenciales robadas, observe qué desafíos de autenticación multifactor se presentan y seleccione la siguiente página del kit de phishing que se mostrará al usuario.
siguiente página del kit de phishing que se presentará al usuario.
- Si el operador elige o se ve obligado a completar un desafío OTP por SMS, el usuario es dirigido a una página llamada /submit-otp. La OTP capturada se envía en una solicitud POST al panel del operador en /backend.php.
- Si el operador elige o se ve obligado a completar un desafío TOTP, el usuario es dirigido a una página llamada /submit-authenticator. La OTP capturada se envía en una solicitud POST al panel del operador en /backend.php.
- Si el operador elige o se ve obligado a completar un desafío de autenticación multifactor (MFA) mediante notificaciones push, el usuario es dirigido a una página llamada /approve-authenticator (ver imagen a continuación) y se le pide que ingrese el número proporcionado por el operador en su aplicación de autenticación.
Figura 3. La página de desafío de autenticación multifactor O-UNC-066, regenerada utilizando código extraído del kit de phishing.
En esta fase del ataque, el usuario ha sido engañado por teléfono para que autorice al atacante a acceder a su cuenta de Microsoft 365.
Siguiendo con el pretexto de la clave de acceso, los ciberdelincuentes pueden dirigir a los usuarios a la página /passkey/register, donde se les pide que creen una clave de acceso.
Figura 4. La página de registro de la clave de acceso O-UNC-066, regenerada utilizando código extraído del kit de phishing.
El kit de phishing parece aprovecharse de la falta de familiaridad del usuario con la autenticación mediante clave de acceso. En una ceremonia real de registro de clave de acceso, el usuario podría esperar un cuadro de diálogo del sistema para registrar una clave de acceso en su dispositivo. Las páginas de claves de acceso de este kit de phishing parecen imitar este proceso sin registrar ninguna clave de acceso.
En la página /passkey , al usuario objetivo se le muestra una página con la marca Microsoft que lo anima a “guardar su clave de recuperación” de una lista de frases BIP-39 controlada por el atacante. Esto se asemeja mucho a los métodos utilizados en algunas aplicaciones de criptomonedas para generar frases semilla fáciles de recordar.
Figura 5. La página opcional de clave de acceso O-UNC-066, que utiliza código extraído del kit de phishing.
Una página posterior /passkey/check solicita al usuario que verifique la última palabra utilizada en la frase semilla.
No tenemos conocimiento de ninguna aplicabilidad directa de las frases semilla BIP-39 a Microsoft Entra o a su proceso de registro de claves de acceso. Un atacante que ya haya obtenido acceso no autorizado a una cuenta de usuario puede crear sus propios códigos de recuperación mediante un proceso que no requiere ninguna intervención del titular real de la cuenta.
Es probable que estas páginas con temática de clave de acceso estén disponibles para el operador del kit de phishing como una artimaña. Se trata de una distracción para mantener al usuario ocupado en una tarea mientras el atacante introduce su propia clave de acceso en la cuenta de usuario legítima de Microsoft.
La página /done confirma que el registro de la clave de acceso se realizó correctamente. Un usuario desprevenido que no comprenda del todo cómo se registra una clave de acceso puede creer sinceramente que la ha registrado con Microsoft simplemente al completar estas tareas que, de otro modo, carecerían de sentido.
Figura 7.º La página de confirmación de la campaña O-UNC-066, que utiliza código extraído del kit de phishing.
El operador puede elegir cuándo mostrar la página /done al usuario. Como mínimo, ayuda a la operación de phishing a mantener el pretexto original. Cada vez que un usuario registra una clave de acceso con Microsoft, el propietario de la cuenta comprometida recibe un correo electrónico legítimo de Microsoft para notificarle que se ha registrado una nueva clave de acceso en su cuenta. Durante un ataque, la clave de acceso fue registrada directamente por el atacante con Microsoft, y este tiene la posibilidad de nombrar la clave de acceso con algo que el usuario objetivo considere inofensivo (quizás incluso tomando prestada la frase semilla seleccionada por el usuario objetivo). Por el contrario, es probable que la configuración de registro mediante clave de acceso que el usuario objetivo experimentó en el sitio de phishing solo exista para engañar al usuario y hacerle creer que el registro del atacante era el suyo propio.
Infraestructura
Se observó que los ciberdelincuentes creaban subdominios para cualquier entidad objetivo determinada bajo los siguientes dominios:
- assignpasskey[.]com (14/06/2026, Internet Domain Service BS Corp., DDoS-Guard)
- deploypasskey[.]com (21/04/2026, Tucows, DDoS-Guard)
- passkeydeploy[.]com (23/04/2026, Internet Domain Service BS Corp, DDoS-Guard)
- passkeyadd[.]com (08/05/2026, Tucows, DDoS-Guard)
- setpasskey[.]com (23/05/2026, IQWeb FZ-LLC)
Por lo tanto, una campaña dirigida a "exampleentity" podría ser algo así:
exampleentity[.]setpasskey[.]com
La infraestructura de phishing observada por Okta Threat Intelligence estaba alojada en DDoS-Guard (AS57724, Rusia) e IQWeb FZ-LLC (AS59692, EE. UU.).
Impacto
Desde abril de 2026, un actor malicioso vinculado a O-UNC-066 ha operado un sitio de filtración de datos con el nombre Pink (informado como "CL-CRI-1147" por la Unidad 42 de Palo Alto Networks).
Figura 7.º El sitio Pink DLS (extorsión de datos)
Recomendaciones
Si bien no se ha observado que este grupo de actividades maliciosas suplante la identidad de Okta, campañas similares han combinado ingeniería social basada en voz y kits de phishing controlados por operadores:
Entrada de blog pública (disponible públicamente)
Aviso urgente (solo para clientes de Okta)
Aviso sobre amenazas (solo para clientes de Okta)
Las siguientes recomendaciones son específicas para la defensa de los clientes de Okta.
ATT&CK
|
Táctica
|
Recomendación de control
|
T1566
|
phishing
|
Inscriba a los usuarios en sistemas de autenticación robustos como Okta FastPass, claves de acceso o tarjetas inteligentes, e implemente medidas de protección contra el phishing en las políticas.
Establecer, comunicar y promover métodos para verificar la identidad del personal de soporte técnico cuando se pongan en contacto con los usuarios.
|
T1078
|
phishing
|
Rechace las solicitudes procedentes de lugares donde su organización no ofrece servicios. Las zonas de red de Okta permiten a los administradores establecer políticas que deniegan el acceso a las aplicaciones protegidas por Okta según la geolocalización (país), el número autónomo (ASN), la dirección IP u otros criterios.
|
T1078
|
Cuentas válidas
|
Las políticas de autenticación de Okta se pueden utilizar para restringir el acceso a las cuentas de usuario en función de una serie de requisitos previos configurables por el cliente. Recomendamos a los administradores restringir el acceso a aplicaciones sensibles a los dispositivos que estén gestionados por herramientas de gestión de dispositivos y protegidos por herramientas de seguridad de dispositivos. |
T1078
|
Cuentas válidas
|
Notificar a los usuarios sobre cada evento del ciclo de vida del autenticador (factor) mediante notificaciones al usuario final.
|
T1098
|
Manipulación de cuentas (registro de dispositivos)
|
Aplique las políticas de administración de cuentas de Okta que limitan la capacidad de agregar o modificar autenticadores en función del contexto de la red, el estado de administración del dispositivo y los autenticadores registrados. En la siguiente entrada del blog se ofrece información específica al respecto: |
