Alerta del FBI sobre Kali365 (2026): cómo el phishing de OAuth device-code evade la MFA en Microsoft 365

La alerta del FBI en 60 segundos

La alerta del IC3 del FBI PSA260521 describe a Kali365 como un kit de phishing llave en mano vendido en canales de Telegram en ruso y foros clandestinos. Los operadores pagan aproximadamente 199 dólares al mes por páginas de aterrizaje alojadas, embudo automatizado de víctimas y un panel que muestra en tiempo casi real las sesiones de Microsoft 365 recién secuestradas. El FBI indica que los objetivos incluyen proveedores de servicios gestionados, firmas de contabilidad y abogados, redes sanitarias y empresas pequeñas o medianas que operan sobre Microsoft 365 pero carecen de políticas maduras de acceso condicional. La cobertura de BleepingComputer añade que varias firmas de respuesta a incidentes comenzaron a ver indicadores de Kali365 a finales de febrero de 2026, con un repunte pronunciado durante abril. Lo que hace que Kali365 sea distinto de los kits habituales de inicio de sesión falso es lo que pide hacer a la víctima: no escribir una contraseña, sino introducir un código de dispositivo corto en el dominio real microsoft.com.

Cómo funciona realmente el phishing de OAuth device-code

El flujo de autorización de dispositivo de OAuth, definido en el RFC 8628 e implementado por Microsoft Entra ID, fue diseñado para hardware que no dispone de un navegador real. Pensemos en televisores inteligentes, consolas Xbox, dispositivos IoT y herramientas de línea de comandos como la CLI de Azure o kubectl. En un día normal, el flujo se ve así:

1. El dispositivo solicita al endpoint de tokens de Microsoft un nuevo código de dispositivo. Microsoft devuelve dos cadenas: un código de dispositivo largo (que el dispositivo usa para sondear el token) y un código de usuario corto, normalmente de ocho o nueve caracteres como "FQRMNXSP".
2. El dispositivo muestra el código de usuario en su pantalla y dice: "ve a microsoft.com/devicelogin e introduce FQRMNXSP".
3. El usuario abre un navegador, inicia sesión en su cuenta de Microsoft 365 con normalidad (incluyendo la MFA) y escribe el código en la página de microsoft.com/devicelogin.
4. Microsoft enlaza la sesión autenticada con el código de dispositivo. El dispositivo, que sigue sondeando, recibe un token de acceso (Access Token) y un token de actualización (Refresh Token).

Ahora reemplaza "dispositivo" por "servidor del atacante" y observa cómo el flujo se rompe. Un operador de Kali365 inicia una petición de device-code contra el endpoint de Microsoft y recolecta el código de usuario. A continuación, llega a tu bandeja de entrada un correo de phishing que afirma que necesitas dar de alta una nueva sala de Teams, aprobar una sincronización de SharePoint o activar una licencia de Microsoft Defender for Endpoint. El correo te indica que visites microsoft.com/devicelogin y pegues un código generado por el atacante. Tú inicias sesión en tu cuenta real de Microsoft, escribes el código y haces clic en confirmar. Microsoft, haciendo exactamente lo que fue diseñado para hacer, envía un token de acceso y un token de actualización al servidor de sondeo del atacante. Tú nunca escribiste una credencial en nada malicioso, tu notificación push de MFA fue aprobada correctamente y, sin embargo, el atacante ahora posee una sesión indistinguible de la tuya.

Por qué la MFA no te salva

La autenticación multifactor (MFA) asume que el modo de fallo es una contraseña robada que se reproduce en un lugar donde no debería. El propósito mismo de un segundo factor es romper ese ataque de repetición. El phishing de device-code invierte la asunción. El atacante nunca intenta reproducir tu contraseña. Tú te autenticas exactamente como Microsoft espera, en el dominio real microsoft.com, en el dispositivo que siempre usas, contra el proveedor de identidad real de tu tenant. Se dispara el desafío de MFA y lo apruebas porque genuinamente estás iniciando sesión. El fraude no está en el paso de autenticación. Está en el paso de consentimiento, donde enlazas tu sesión recién autenticada con la pieza de hardware equivocada.

La coincidencia de números (number matching) de Microsoft Authenticator, que cubrimos en el artículo sobre fatiga de MFA, tampoco ayuda aquí. La coincidencia de números derrota el bombardeo de notificaciones al obligar al usuario a escribir un número procedente de una pantalla de inicio de sesión que él no abrió. En el phishing de device-code, el usuario abre la pantalla de inicio de sesión él mismo. No hay ninguna anomalía que marcar.

Por eso el FBI usó la expresión "compromiso persistente post-MFA" en la alerta PSA260521. Una vez que el atacante posee el token de acceso y el token de actualización, puede leer el correo de Outlook, enviar mensajes desde tu dirección, enumerar el tenant de SharePoint, registrar su propio método de MFA en tu cuenta y refrescar la sesión silenciosamente durante todo el tiempo que viva el token de actualización. No se dispara ningún aviso futuro de MFA porque el atacante nunca vuelve a autenticarse. Simplemente sigue refrescando.

Lo que SafeBrowz ve en la red

Nuestro equipo de ingeniería de detección lleva mapeando la infraestructura de páginas de aterrizaje de Kali365 desde finales de febrero. Hay unos cuantos patrones que importan, y son los patrones que nuestra arquitectura de tres capas está específicamente afinada para detectar.

Primero, las páginas de aterrizaje casi nunca están alojadas en microsoft.com en sí. Viven en hosts similares (lookalike) que solo encaminan a la víctima hacia la URL legítima microsoft.com/devicelogin tras un intersticial falso de "verificar tu tenant" o "registrar tu dispositivo". El intersticial es donde ocurre la ingeniería social, y ese intersticial casi siempre se asienta en un dominio recién registrado. A partir de las campañas que hemos analizado, la edad típica del dominio similar de Kali365 es de menos de siete días en el momento del compromiso. Algunos tienen menos de doce horas. Esta es la señal más fuerte del lado del servidor que tenemos para esta familia de kits, y encaja perfectamente con cómo se comportan nuestras consultas de reputación de la Capa 2: Google Safe Browsing, PhishTank y URLhaus sacan a la luz dominios maliciosos recientes en horas, y nuestra extensión lee esas fuentes en cada navegación.

Segundo, los nombres de host similares se agrupan en torno a un puñado de variantes estructurales. Vemos "ms-teams-rooms-{tenant}.{tld}", "microsoft365-activate-{region}.{tld}", "m365-defender-onboard.{tld}", "office-licensing-portal.{tld}", "azureportal-verify.{tld}", "sharepoint-sync-{department}.{tld}" y una larga cola de nombres creativos puntuales. Muchos utilizan TLD baratos o abusados (.shop, .top, .xyz, .live, .click) porque son económicos a escala. Microsoft es una de las más de 550 marcas en nuestra base de datos de detección local, y la firma específica de marca detecta cada una de las variantes de sufijo similar en el momento en que comienza la navegación, antes incluso de que la página se renderice.

Tercero, el contenido de la página de aterrizaje tiene un indicador que nuestro análisis de contenido por IA de la Capa 3 es excepcionalmente bueno detectando. El kit necesita convencer a una persona real para que copie un código de usuario OAuth real y lo pegue en una página real de Microsoft. Eso requiere texto escrito de ingeniería social: instrucciones como "se te ha emitido un código de incorporación de un solo uso: XXXX-XXXX", "abre microsoft.com/devicelogin en una nueva pestaña", "este código caduca en 8 minutos". Este lenguaje es raro en superficies legítimas de Microsoft. Microsoft no suele pedirle a un humano que copie códigos de dispositivo entre dos ventanas. Cuando nuestro análisis profundo por IA ve ese patrón combinado con marca Microsoft en un host que no es microsoft.com, el veredicto es "peligro" sin excepción. No escribimos una regla específica para Kali365. No tuvimos que hacerlo. El patrón general "marca similar + instrucción de entrega OAuth" se dispara para toda la familia del kit porque la familia del kit no puede dejar de producir esas instrucciones y seguir funcionando.

Por qué la defensa en el navegador supera al solo correo aquí

La alerta sobre Kali365 va a enmarcarse en algunos sitios como una razón para comprar más pasarelas seguras de correo. Nuestra perspectiva es más dura. Las pasarelas de correo son necesarias, pero para esta clase de ataque son insuficientes por diseño.

SPF, DKIM y DMARC validan que el dominio remitente controle el mensaje. Los operadores de Kali365 envían rutinariamente desde tenants legítimos comprometidos (el kit secuestra buzones de Microsoft 365 y los usa como plataformas de lanzamiento para la siguiente oleada), por lo que el correo pasa todas las comprobaciones de autenticación. El dominio remitente es real. El nombre visible es real. El bloque de firma es real. Aislar el enlace en un sandbox tampoco ayuda mucho, porque la página de aterrizaje suele presentar contenido benigno a agentes de usuario no humanos y renderiza el intersticial de OAuth solo cuando detecta por fingerprint que es un navegador real.

Cuando el usuario hace clic en el enlace, la pasarela ya ha aprobado el mensaje. La defensa tiene que estar donde ocurre el renderizado. Eso es el navegador. Un escáner del lado del navegador que mantiene una base de datos de más de 550 marcas, lee fuentes de reputación globales y ejecuta análisis de contenido con modelos de lenguaje sobre la página renderizada es la única capa que ve el momento del compromiso. Esa es la capa en la que se sitúa SafeBrowz, y por eso lo construimos como lo construimos.

Cómo SafeBrowz bloquea esta amenaza

SafeBrowz ejecuta una arquitectura de detección de tres capas: Local + APIs + Inteligencia Artificial.

• Capa 1 - Detección local: más de 60 patrones de URL más más de 550 firmas específicas de marca (Microsoft y las variantes Microsoft365 / Outlook / Teams / SharePoint / Azure incluidas), reconocimiento de homógrafos cirílicos y Punycode, y listas de la comunidad ejecutándose directamente dentro de la extensión antes de que la página se renderice. Los patrones estructurales de host similar descritos arriba (ms-teams-rooms-*, microsoft365-activate-*, m365-defender-onboard-*, office-licensing-portal-*) coinciden todos con la familia de reglas de suplantación de marca en la Capa 1 y bloquean antes del renderizado.
• Capa 2 - Reputación por APIs: agregación del lado del servidor de Google Safe Browsing, PhishTank, URLhaus, ScamAdviser y más de 30 comprobaciones de TLD de estafa. Los dominios similares de Microsoft recién registrados (edad típica del dominio Kali365 inferior a siete días) aparecen en PhishTank y URLhaus en cuestión de horas, a menudo en minutos. Nuestra extensión lee esas señales en cada navegación.
• Capa 3 - Análisis profundo por IA (Premium): un analizador de contenido multilingüe que lee la página renderizada y razona sobre la intención. Para Kali365, la firma reveladora es "marca Microsoft similar más instrucciones de entrega de código de dispositivo OAuth más código de usuario con caducidad". Cuando ese patrón aparece en un host que no es microsoft.com, el veredicto es peligro. El mismo motor funciona en más de 100 idiomas, lo que importa porque Kali365 distribuye páginas de aterrizaje localizadas en español, portugués, árabe, francés y alemán.

Las firmas de detección provienen de investigación de inteligencia de amenazas y de nuestra base de datos de marcas, no de los datos de navegación del usuario. El historial de URL por usuario nunca se almacena.

Lo que las empresas y los consumidores deben hacer ahora mismo

Si gestionas un tenant de Microsoft 365, no esperes al próximo trimestre para abordar Kali365. Pasos específicos en orden de prioridad:

1. Audita tu actividad de inicio de sesión en aka.ms/signin. Busca concesiones OAuth desde nombres de dispositivo que no reconozcas, discordancias geográficas y entradas de dispositivo "Otro cliente" en cuentas que deberían ser solo de navegador.
2. Revoca las sesiones activas a nivel de todo el tenant para los usuarios de alto riesgo. En el centro de administración de Microsoft 365, ve a Usuarios, selecciona la cuenta, abre Actividad de inicio de sesión y pulsa Revocar. Los tokens de actualización persisten incluso después de un restablecimiento de contraseña; revocar las sesiones es la única forma de matarlos a la fuerza.
3. Establece políticas de Acceso Condicional que deshabiliten el flujo device code excepto para personas explícitas. Microsoft Entra ahora incluye una plantilla integrada de Acceso Condicional para "Bloquear flujos de autenticación - Flujo de código de dispositivo" (referencia de la política). La mayoría de los tenants deberían bloquear el device code para todos excepto operadores de TI que realmente usen Azure CLI o kubectl. Este único cambio acaba con Kali365 en tu tenant.
4. Inspecciona el registro de consentimientos OAuth. Administración de Microsoft 365, Aplicaciones empresariales, Registros de auditoría. Filtra por ConsentEvents en los últimos 30 días. Busca identificadores de aplicación desconocidos, especialmente cualquier cosa que se parezca a nombres genéricos de herramientas CLI o de script. Los consentimientos desconocidos otorgados en torno al momento de inicios de sesión sospechosos son la prueba irrefutable.
5. Aplica MFA resistente al phishing en las personas de mayor riesgo. Llaves de seguridad FIDO2 o passkeys de plataforma para finanzas, jurídico, administradores ejecutivos y operadores de TI. El phishing de device-code es el raro ataque que funciona contra la MFA basada en app autenticadora. Las passkeys puras siguen elevando el listón porque el servidor de sondeo del atacante no puede conducir una sesión enlazada con passkey.
6. Si sospechas que una cuenta de Microsoft Authenticator ha sido tocada por un atacante, elimínala de la app, restablece la MFA desde un dispositivo limpio y vuelve a registrarla. Aprovecha para auditar los métodos de MFA registrados en el objeto de usuario; a los atacantes les encanta añadir silenciosamente un número de teléfono o un secreto TOTP propio como puerta trasera.
7. Entrena a los usuarios en una frase concreta. "Microsoft nunca te enviará por correo un código para pegar en microsoft.com/devicelogin". Si un usuario ve esa redacción en un correo, el correo es hostil, punto. Esta única frase es más eficaz que cualquier formación genérica de concienciación sobre phishing porque nombra el ataque exacto.

Para cuentas de Microsoft de consumidor (outlook.com, hotmail.com, Xbox) aplica la misma lógica, solo que más estrecha. Revisa account.microsoft.com/security para ver la actividad reciente, cierra sesión en todas partes y rota la contraseña. El lado consumidor no expone políticas de Acceso Condicional, pero el flujo device code es mucho más raro en escenarios de consumidor, por lo que un aviso inesperado de device-code debe tratarse como hostil garantizado.

Lo que viene a continuación: nuestra predicción de pivote de marca

Kali365 es el primer kit de phishing como servicio que industrializa el abuso del device-code OAuth, pero la técnica no es específica de Microsoft. Cualquier proveedor de identidad que ofrezca un flujo de autorización de dispositivo OAuth está estructuralmente expuesto. La predicción de nuestro equipo de detección para los próximos doce meses, basada en lo que vemos en nuestra base de datos de marcas y en lo que empezamos a encontrar en registros tempranos de dominios similares:

• Phishing de device-code para Google Workspace. Google admite el flujo de dispositivo para Google TV, la CLI de Workspace y gcloud. Los tenants de Workspace sin Acceso Consciente del Contexto (Context-Aware Access) son los más expuestos. Esperamos un clon estilo Kali365 dirigido a identidades de Google en cuestión de meses.
• Abuso del device flow de GitHub. La CLI de GitHub usa el device flow para autenticar a los desarrolladores. Una sesión de GitHub robada puede llevar directamente a la exfiltración de código fuente, commits maliciosos en dependencias de cadena de suministro y robo de secretos de Actions. Objetivo muy apalancado, y muy pocas organizaciones aplican Acceso Condicional a GitHub.
• Tokens de autenticación de la API de Anthropic Claude y de la API de OpenAI. Las APIs de IA no usan actualmente flujo OAuth de dispositivo, pero el patrón más amplio (tokens de API de larga vida sustraídos a desarrolladores vía páginas de consentimiento similares) ya es real. Hemos empezado a añadir "Claude" y "Anthropic" a nuestra base de datos de marcas precisamente por eso.
• Autorización de dispositivo de AWS IAM Identity Center (antes SSO). AWS admite un flujo de autorización de dispositivo para "sso login" de la CLI v2. Una organización que depende de sesiones de SSO de AWS de larga vida para operadores de terraform y kubectl está a un kit estilo Kali365 de una brecha cloud en el peor de los casos.
• Atlassian, Slack, Zoom. Todos exponen pantallas de consentimiento OAuth que parecen altamente confiables y rara vez se auditan. Los kits acabarán dirigiéndose a ellos cuando la mitigación de Microsoft 365 cierre el punto de entrada más lucrativo.

Una observación más. El modelo económico de phishing como servicio (PaaS) es la verdadera historia aquí, no el kit específico. A 199 dólares al mes con un canal de soporte en Telegram y un panel de control alojado, Kali365 significa que un atacante ya no necesita entender OAuth en absoluto. Necesita una tarjeta de crédito (o USDT en una billetera de Telegram) y una lista de objetivos. El piso de habilidad para la toma de cuentas en la nube altamente persistente e inmune a la MFA ha caído a casi cero. Todo defensor en la capa del navegador debería planificar en torno a ese cambio, no en torno al nombre concreto que figura en la alerta de este mes.

Preguntas frecuentes

¿Qué es Kali365 en una frase?

Kali365 es un kit de phishing como servicio, señalado por el FBI en la alerta PSA260521 del 21 de mayo de 2026, que secuestra cuentas de Microsoft 365 al abusar del flujo de autorización de dispositivo de OAuth 2.0 para que las víctimas aprueben la sesión del atacante en el dominio real microsoft.com.

¿En qué se diferencia Kali365 de un kit habitual de phishing de Microsoft?

Los kits habituales de phishing de Microsoft engañan al usuario para que escriba una contraseña y un código MFA en una página de inicio de sesión falsa. Kali365 nunca pide credenciales. Engaña al usuario para que pegue un código corto de dispositivo OAuth en la URL real microsoft.com/devicelogin tras autenticarse con normalidad. El atacante recibe el token de sesión, la MFA se satisfizo legítimamente y no hay un robo de credenciales evidente que detectar.

¿Por qué la autenticación multifactor no bloquea Kali365?

Porque la víctima realiza un inicio de sesión real y válido en su propia cuenta de Microsoft, incluyendo un desafío MFA real que aprueba correctamente. La acción maliciosa ocurre en el paso de consentimiento, donde la sesión recién autenticada se enlaza al código de dispositivo del atacante. La MFA no se evade en sentido criptográfico; se vuelve irrelevante al engañar al usuario para que se autentique en nombre del atacante.

¿Cuál es la solución más eficaz para una empresa?

Bloquear el flujo de autenticación device code en Acceso Condicional para todo el que no lo necesite específicamente. Microsoft Entra incluye una plantilla de un solo clic para esto. La mayoría de las organizaciones tienen cero uso legítimo de device-code fuera de operadores de TI en Azure CLI o kubectl. Bloquearlo a nivel de tenant para los usuarios normales acaba con Kali365 en tu entorno inmediatamente.

¿Cómo detecta SafeBrowz Kali365 si el kit rota dominios constantemente?

Las reglas de suplantación de marca de la Capa 1 se disparan ante el patrón estructural similar, no ante un dominio específico. Las fuentes de reputación de la Capa 2 (Google Safe Browsing, PhishTank, URLhaus) sacan a la luz los hosts recién registrados en cuestión de horas tras el primer abuso. El análisis de contenido por IA de la Capa 3 identifica el lenguaje de ingeniería social del device-code OAuth independientemente de dónde se aloje la página. El kit tiene que seguir produciendo textos que piden a los usuarios pegar códigos en microsoft.com/devicelogin, y ese texto es lo que reconocemos.

Creo que un usuario de mi tenant aprobó un código de dispositivo de Kali365. ¿Qué hago en los próximos 15 minutos?

Abre el centro de administración de Microsoft 365, busca al usuario, abre Actividad de inicio de sesión, pulsa Revocar sesiones. Esto invalida todos los tokens de actualización ligados a la cuenta. Restablece la contraseña del usuario. Restablece los métodos MFA en el objeto de usuario y elimina cualquier autenticador registrado que el usuario no reconozca. Abre Aplicaciones empresariales y revisa las concesiones OAuth para ese usuario, revocando cualquier cosa que no sea tuya. Después ve al registro de auditoría y extrae cada acción que ejecutó la sesión del atacante.

¿SafeBrowz recopila datos sobre las URLs que visitan mis usuarios?

No. SafeBrowz realiza la detección de la Capa 1 localmente dentro del navegador, sin que ninguna URL salga del dispositivo. Las comprobaciones de reputación de la Capa 2 consultan listas globales de bloqueo solo con el dominio, nunca con la identidad. El análisis profundo por IA de la Capa 3, disponible para usuarios Premium, envía extractos del contenido renderizado para análisis y los descarta tras el veredicto. No almacenamos historial de URL por usuario, identificadores de instancia ni asociaciones IP a URL. Las fichas de Chrome Web Store, AMO y Edge certifican que la extensión no recopila historial web.

¿La MFA resistente al phishing como las llaves FIDO2 detendrá a Kali365?

Sí, indirectamente. Una llave de seguridad FIDO2 o una passkey de plataforma no puede ser conducida por el servidor de sondeo de un atacante porque el desafío criptográfico está ligado al dominio de origen que el usuario está navegando. Incluso si se manipula socialmente al usuario para que copie un código, la sesión del atacante solo puede completarse si el device flow está permitido para esa cuenta. Combina MFA resistente al phishing con una política de Acceso Condicional que deshabilite el device code flow para ese usuario, y la ruta del ataque queda cerrada.

Lecturas relacionadas

• Cómo detectar un correo falso de Microsoft - el ataque previo que a menudo conduce al phishing de device-code
• Ataque de fatiga MFA por bombardeo de notificaciones - la otra gran clase de evasión de MFA, y por qué la coincidencia de números la derrota
• Evasión de 2FA por adversario en el medio (AiTM) - phishing de proxy inverso que también produce tokens de sesión persistentes
• Estafa de popup falso de soporte técnico de Microsoft (DOJ 2026) - la prima del lado consumidor de la suplantación empresarial de Microsoft

En resumen: Kali365 no es un exploit nuevo e ingenioso. Es un abuso productizado de un flujo OAuth documentado, empaquetado para no expertos a 199 dólares al mes, que convierte los propios endpoints de autenticación de Microsoft en el mecanismo de entrega para un compromiso persistente de cuentas. La solución en tu tenant es concreta: bloquear el device code flow en Acceso Condicional, auditar el registro de consentimientos OAuth, revocar sesiones a cualquier usuario que haya hecho clic y poner una arquitectura de detección en la capa del navegador delante de la bandeja de entrada. La alerta PSA260521 del FBI es el aviso. Los próximos doce meses determinarán qué organizaciones la trataron como una llamada de atención y cuáles siguieron confiando en las pasarelas de correo y en las notificaciones MFA para defender una nube donde ninguna de las dos es suficiente por sí sola.