El 2026-05-21 el FBI emitió el aviso de servicio público I-052126-PSA, alertando sobre un kit de Phishing-as-a-Service llamado Kali365 que secuestra cuentas de Microsoft 365. No roba contraseñas. No intercepta códigos MFA. La víctima inicia sesión en la propia página de Microsoft, completa la autenticación multifactor, y el atacante igualmente se lleva acceso persistente. Kali365 hace esto abusando de la concesión de autorización de dispositivo de OAuth 2.0 para capturar los tokens de acceso y de actualización que Microsoft emite tras un inicio de sesión totalmente legítimo.
No es una técnica nueva. En febrero de 2025 Microsoft documentó una campaña de phishing por código de dispositivo de Storm-2372, un actor que evalúa como alineado con intereses estatales rusos, activa contra objetivos de gobierno, defensa, telecomunicaciones y energía. Lo que cambió es el empaquetado. Kali365 convierte esa táctica en un kit por suscripción con señuelos generados por IA, de modo que un actor de baja habilidad puede ejecutarla. El login funciona, el aviso de MFA funciona, y la suposición debajo de ambos falla: que un evento de autenticación exitoso te dice quién tiene la sesión un minuto después.
Esa suposición es el verdadero objetivo. "El usuario se autenticó correctamente" dejó de ser un límite de confianza. La sesión activa, transportada por un token al portador atado a nada, lo es.
Qué automatiza realmente Kali365
El FBI describe Kali365 como una plataforma de PhaaS distribuida por Telegram, vista por primera vez en abril de 2026. Incluye señuelos de phishing generados por IA, plantillas de campaña automatizadas, paneles en tiempo real para rastrear a personas específicas, y captura de tokens OAuth. En palabras del FBI, "reduce la barrera de entrada, dando a atacantes menos técnicos acceso a señuelos de phishing generados por IA, plantillas de campaña automatizadas, paneles de seguimiento de individuos/entidades en tiempo real, y capacidades de captura de tokens OAuth."
Léelo como una división del trabajo. Las partes difíciles del phishing por código de dispositivo solían ser escribir un señuelo convincente y operar de forma fiable la infraestructura de captura y canje de tokens dentro de una ventana de 15 minutos. La IA escribe el señuelo. El kit ejecuta la fontanería de OAuth. El operador solo elige objetivos. Eso es lo que hace de esto un ejemplo más limpio de IA escalando el fraude que la mayoría: no inventa un ataque nuevo, elimina la habilidad que antes controlaba el acceso a uno existente.
El flujo de código de dispositivo, paso a paso
La concesión de autorización de dispositivo existe por una buena razón. Permite iniciar sesión en dispositivos donde es incómodo escribir, como televisores inteligentes, decodificadores y herramientas de línea de comandos. Ves un código corto, lo introduces en tu teléfono, el dispositivo queda autenticado. El diseño es legítimo y se usa constantemente en Microsoft 365.
Este es el mismo flujo convertido en ataque:
- El atacante envía un
POSTahttps://login.microsoftonline.com/common/oauth2/v2.0/devicecodeusando unclient_idpropio y público, a menudo Microsoft Office (d3590ed6-52b3-4102-aeff-aad2292ab01c) o Azure CLI (04b07795-8ddb-461a-bbee-02f9e1bf7b46). Son clientes de Microsoft con consentimiento previo, así que no hace falta registrar una app ni consentimiento de administrador. - Microsoft devuelve un
device_code, unuser_codeque una persona puede teclear, la URL de verificaciónhttps://microsoft.com/deviceloginy unexpires_inde 900 segundos. El atacante tiene ahora una ventana de 15 minutos. - El atacante engaña a la víctima para que abra
microsoft.com/devicelogine introduzca eluser_code. Microsoft Entra no admiteverification_uri_complete, la variante prerellenada del enlace, así que la víctima debe teclear el código a mano. Ese paso manual es exactamente lo que un señuelo de alta conversión escrito por IA está diseñado para impulsar. - La víctima se autentica en la página genuina de Microsoft, completa MFA y da su consentimiento. Cada elemento es real: el dominio es Microsoft, el certificado es válido, el aviso de MFA es el de siempre.
- El atacante consulta
https://login.microsoftonline.com/common/oauth2/v2.0/tokencongrant_type=urn:ietf:params:oauth:grant-type:device_codey eldevice_code, respetando elinterval(5 segundos) y absorbiendo las respuestasauthorization_pending, hasta que el endpoint devuelve unaccess_tokeny unrefresh_token.
No hay dominio falsificado que marcar ni payload en el endpoint que detectar. La parte fraudulenta es un flujo legítimo de Microsoft completado por la persona equivocada, y el token que produce es indistinguible de un token emitido a una sesión real.
Por qué MFA queda satisfecho y Acceso condicional lo deja pasar
Esta es la parte que pilla a los equipos por sorpresa. La víctima completó de verdad el inicio de sesión interactivo, incluido MFA, contra el endpoint real de Microsoft. Así que el inicio de sesión se registra como satisfecho por MFA, reflejado en el detalle de autenticación del registro de inicio de sesión de Entra y, en los tokens v1.0, en el claim amr con el valor mfa. Acceso condicional evalúa ese inicio de sesión como un login interactivo conforme y con MFA superado, y emite tokens en consecuencia.
El atacante no está saltándose MFA en el sentido de derrotar el desafío. El desafío se ejecutó y se superó. Lo que el modelo de token al portador nunca hace es atar el token emitido al dispositivo que superó el desafío. MFA respondió "¿se está autenticando la persona correcta ahora mismo?". No respondió "¿es el dispositivo correcto el que tiene este token treinta segundos después?", y nada en el flujo estándar lo hace.
El alcance del daño: tokens de actualización FOCI y escalada a PRT
Un token de acceso capturado es un problema durante una hora. El token de actualización es el verdadero premio, y el modelo de tokens de Microsoft lo hace peor que el compromiso de una sola app.
Los tokens de actualización emitidos a los clientes propios de Microsoft suelen ser tokens FOCI, Family of Client IDs. Un token de actualización de familia obtenido a través de un cliente puede canjearse por tokens de acceso como otros clientes de la familia, de modo que un token capturado vía Microsoft Office puede intercambiarse por acceso a Exchange Online, Teams, SharePoint y OneDrive, y Microsoft Graph. Un solo token de actualización robado es movimiento lateral por los datos del tenant, no un punto de apoyo en una app.
La aritmética de la vida útil lo agrava. Desde enero de 2021 las vidas útiles de los tokens de actualización ya no se pueden ajustar mediante políticas de vida útil de token; la ventana de inactividad por defecto del token de actualización es de 90 días y la edad máxima es, en la práctica, hasta su revocación. Donde el cliente y el recurso admiten Evaluación de acceso continuo, los tokens de acceso pueden extenderse a entre 24 y 28 horas, aunque son revocables casi en tiempo real ante eventos críticos. Para forzar la reautenticación ahora te apoyas en la frecuencia de inicio de sesión de Acceso condicional, no en la política de token.
El techo de escalada es aún más alto. En la actualización de febrero de 2025 de su informe sobre Storm-2372, Microsoft observó que el actor pasaba al cliente Microsoft Authentication Broker (29d9ed98-a469-4536-ade2-f981bc1d605e) para obtener un token de actualización, registrar un dispositivo controlado por el atacante en Entra ID y luego acuñar un Primary Refresh Token. Un PRT es material de identidad duradero y ligado al dispositivo que desbloquea un single sign-on amplio. El código de dispositivo es el punto de entrada; el PRT es el tenant.
"Autenticado correctamente" dejó de ser un límite de confianza
Durante años el modelo dominante fue simple: verifica al usuario en el login y luego confía en el token hasta que expire. Los backends registran el evento de autenticación, los proveedores de identidad alertan sobre patrones de inicio de sesión extraños, y una vez que la sesión existe la mayoría de las aplicaciones dejan de preguntar quién está del otro lado.
El phishing por código de dispositivo es una refutación limpia de ese modelo. El evento de login es genuino, el token es genuino, y lo único que está mal es que el token ahora lo tiene alguien distinto de la persona que se autenticó. Un token emitido para un usuario en su portátil en un país puede canjearse y reproducirse desde la infraestructura del atacante en otro, y Entra ve una sesión válida y satisfecha por MFA porque, en el momento de la autenticación, lo era.
Ayuda ver los tres caminos comunes de robo de tokens lado a lado. Todos terminan con un token válido posautenticación, pero tocan partes distintas de la superficie de ataque, lo que cambia tanto cómo evaden los controles como dónde aún puedes atraparlos.
| Ataque | Token capturado | Qué toca a la víctima | Dónde ocurre el uso malicioso | Brecha principal de telemetría |
|---|---|---|---|---|
| Phishing por código de dispositivo (Kali365) | OAuth de acceso y de actualización (a menudo FOCI) | Un mensaje de phishing más la página real microsoft.com/devicelogin | Canje y reúso del token desde la infraestructura del atacante | El inicio de sesión es el login MFA genuino de la víctima; el canje se le atribuye |
| Phishing adversary-in-the-middle | Token de sesión o cookie capturados en tránsito | Una página de login falsa con proxy inverso | Sesión reproducida desde la infraestructura del atacante | Existe un dominio parecido pero la sesión se ve válida aguas abajo |
| Malware infostealer | Cookies de sesión copiadas del disco | Malware ejecutándose en el endpoint | Sesión reanudada desde la cookie robada | Compromiso del endpoint, pero la sesión reanudada pasa las comprobaciones del servidor |
El hilo común es la última columna. En todos los casos la aplicación tiene un token válido y trata a quien lo posee como el usuario autenticado. El dispositivo que se autenticó y el dispositivo que ahora usa el token son distintos, y el modelo estándar no tiene comprobación nativa para esa diferencia.
Detectarlo y bloquearlo
Aquí hay dos tareas: cerrar el flujo y encontrar dónde ya se usó.
Bloquear el flujo en Acceso condicional de Entra
Esto se corresponde directamente con la recomendación principal del FBI. En Acceso condicional, usa la condición de flujos de autenticación y pon el flujo de código de dispositivo en Bloquear, y bloquea la transferencia de autenticación en la misma política. La propia guía de Microsoft es bloquear el flujo de código de dispositivo siempre que sea posible.
- Aplica la política a todos los usuarios y todos los recursos, y luego excluye las cuentas de emergencia y de acceso de respaldo para que una mala configuración no te deje fuera.
- Si un proceso legítimo registra dispositivos por el flujo de código de dispositivo, excluye el Servicio de registro de dispositivos (
01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9), ya que las políticas de flujos de autenticación se aplican allí cuando la política apunta a todos los recursos. - Audita el uso actual del código de dispositivo antes de aplicar, para que las excepciones genuinas se conozcan en lugar de adivinarse.
Buscar el uso previo en los registros de inicio de sesión
Los inicios de sesión por código de dispositivo son visibles en los registros de inicio de sesión de Entra ID. El filtro de detección más usado es el protocolo de autenticación:
SigninLogs
| where AuthenticationProtocol == "deviceCode"
| summarize logins=count() by UserPrincipalName, AppDisplayName, IPAddress, tostring(LocationDetails.countryOrRegion)
Vigila también OriginalTransferMethod == "deviceCodeFlow" para captar sesiones rastreadas por protocolo en renovaciones posteriores, y marca los eventos de registro de dispositivos realizados por el cliente Microsoft Authentication Broker donde no los esperas, que es la señal de la escalada a PRT.
La limitación honesta está en la tabla de arriba. El evento de autenticación que produjo el token es el inicio de sesión real y satisfecho por MFA de la víctima, así que la detección por registros es fuerte sobre el flujo en sí pero débil sobre el canje y el reúso que vienen después, que Entra atribuye a ese inicio de sesión legítimo.
Dónde se cierra de verdad la brecha del código de dispositivo: la capa de sesión
Un token robado tiene que usarse en algún lugar, y ese lugar casi nunca es el dispositivo que se autenticó. Ese desajuste es la señal que el modelo de token al portador descarta y la que cside está construida para conservar.
La huella digital avanzada de dispositivos de cside recopila más de 100 señales de navegador, dispositivo y red para crear un identificador persistente de cada visitante. En la autenticación, esas señales establecen una línea base para la sesión. Cuando un token se presenta más tarde desde un entorno distinto, una huella de TLS y de navegador distinta, un ASN o una salida por proxy residencial distintos, marcas de automatización o headless que no estaban en el login, la huella no coincide con la línea base, y ese desajuste puede activar la invalidación del token o un desafío adicional antes de que el atacante llegue a los datos. Profundizamos en esto en cómo los datos de ubicación avanzados detectan el reúso inseguro de tokens y en el cambio más amplio en por qué la sesión del navegador ya es un plano de control de seguridad.
cside también monitorea el entorno del lado del cliente en busca de los scripts maliciosos y las cargas de secuestro de sesión que operan por debajo de la capa de autenticación. Esa es la visibilidad a nivel de navegador que los registros de backend no pueden ofrecer, y es la parte de la superficie de ataque donde realmente se decide el robo de tokens. Para ver dónde encaja esto en un stack más amplio de apropiación de cuentas, nuestra guía para comparar soluciones de prevención de ATO mapea dónde se detiene MFA y dónde empiezan las señales a nivel de sesión.
Solicita una demo para ver cómo cside detecta sesiones comprometidas antes de que ocurra el daño.
Los controles de Microsoft 365, el comportamiento de Entra y la guía del FBI son correctos a fecha de 2026-05-31. Los flujos de los proveedores, los IDs de cliente y los avisos cambian; confirma las opciones actuales de flujo de código de dispositivo y de Acceso condicional de Microsoft antes de depender de una configuración específica.
