Anzuelo, hilo y token de autenticación: anatomía del kit de modelo de phishing como servicio Kali365 / Octopi365

Divulgación: se utilizó asistencia de IA para partes de esta publicación de blog y su análisis.

Agradecimientos: un agradecimiento especial a Lindsey O’Donnell-Welch y Matt Anderson por sus contribuciones a esta investigación y redacción.

Resumen

A mediados de mayo, el SOC de Huntress observó eventos de autenticación mediante código de dispositivo que, tras una investigación más profunda, llevaron a una sospechosa operación de PhaaS de Kali365 / Octopi365.

Lo que encontré no fue solo una página de phishing aislada ni un simple robo de credenciales. La actividad apuntaba a un ecosistema más amplio y maduro, construido para capturar tokens, mantener el acceso, abusar de buzones comprometidos y respaldar fraudes posteriores. Esto incluía múltiples variantes de paneles, plantillas de señuelos integradas, gestión de tokens, funciones de compromiso de correo empresarial (BEC) asistidas por IA, y aplicaciones de escritorio complementarias capaces de convertir el acceso robado en sesiones reales del navegador y actividad de phishing saliente. A lo largo de la investigación, también surgió un comportamiento consistente con tácticas que Microsoft describió previamente en su informe sobre Storm-2372, incluido el uso del ID de cliente de Microsoft Authentication Broker para obtener tokens de actualización que pueden respaldar el registro posterior de dispositivos y el acceso al correo.

La actividad sospechosa de código de dispositivo puede ser la puerta de entrada a un problema mucho mayor después del compromiso, y estos eventos deben investigarse como una señal de abuso de tokens más amplio, acceso a buzones, persistencia y actividad de infraestructura relacionada, y no descartarse como un señuelo de phishing aislado o una anomalía de inicio de sesión puntual. Este blog ofrece una mirada más detallada a la cadena de ataque, la experiencia de la víctima, la infraestructura de phishing y las herramientas del operador detrás de la campaña.

Contexto

A partir del 18 de mayo de 2026, el SOC de Huntress comenzó a observar eventos de autenticación mediante código de dispositivo provenientes de direcciones IP de Tencent Cloud en AS132203. Esto alcanzó su punto máximo el 20 de mayo, con más de 80 eventos exitosos de ‘UserLoggedIn’.

Figura 1: Eventos de autenticación mediante código de dispositivo desde direcciones IP de Tencent Cloud (18 al 27 de mayo)

Este tipo de incremento me hizo pensar que había algún tipo de campaña nueva en curso, así que investigué más a fondo. Descubrí que se trataba de un kit de PhaaS bastante nuevo conocido como Kali365. De forma similar a lo que reportamos sobre EvilTokens a principios de este año, este kit de phishing utiliza el flujo de código de autenticación de dispositivo para engañar a los usuarios y lograr que les permitan entrar a los entornos, manteniendo el acceso incluso si se usa MFA y se cambian las contraseñas después del compromiso.

Los analistas del SOC cuando vieron usuarios iniciando sesión desde Tencent Cloud en masa
(Crédito: @vxunderground)

Esto me llevaría a toda una cacería. Usando Validin, pudimos encontrar más de 150 direcciones IP que alojaban varias variantes de este panel de kit de phishing. La mayoría eran una variante alojada en Tencent Cloud, pero una investigación más profunda reveló todo un ecosistema. Pero primero, retrocedamos unos pasos para ver el ataque en sí.

La expedición de phishing

En al menos un caso, los usuarios recibieron correos que los llevaban a un sitio web alojado en Canva, afirmando que el correo estaba encriptado.

Figura 2: Sitio web alojado en Canva

Un análisis más detallado de este sitio web muestra que, una vez que los objetivos hacen clic en el gran botón “CLICK HERE” (en la Figura 2), se les lleva a una página web que luce bastante legítima y que les da un código.

Figura 3: Se comparte un código con los objetivos como parte del ataque

Al hacer clic en “View” se abre una página de inicio de sesión legítima de Microsoft.

Figura 4: Se pide a los objetivos que inicien sesión y luego ingresen el código

Una vez que el usuario inicia sesión, se le pide que ingrese el código que se le dio. Si se ingresa el código, el atacante entra, y el usuario es redirigido a una página web que simplemente dice “Document Expired”. En tan solo 42 segundos, el atacante ha obtenido acceso persistente.

Figura 5: Historial del navegador desde el endpoint de una víctima de este ataque

Mira el phishing mediante código de dispositivo en acción

Ha aparecido un nuevo enemigo: Kali365 (¿y Octopi365?)

Kali365 es un kit de phishing más nuevo habilitado por IA; según el FBI, se observó por primera vez en abril de 2026. Este panel de PhaaS, programado con ayuda de IA de forma informal, tiene varias variantes y un par de nombres distintos. Por el momento, no está claro por qué existen múltiples nombres.

Antes de continuar, una aclaración sobre todos los nombres que hemos observado en esta plataforma. El nombre más utilizado que hemos visto hasta ahora es “Kali365”. Algunas indagaciones con Validin nos llevaron a paneles idénticos con el nombre “Octopi365”. Este nombre también se mencionaba en uno de los ejecutables (hablaremos de eso más adelante) que encontramos en VirusTotal. Un tercer nombre que encontramos alojando un panel fue “Freedom365”, pero ese parece haber tenido una vida más corta. Todos están relacionados, pero no está claro si esto se debe a un cambio de marca, a kits robados, o a algún otro tipo de maniobra de los operadores.

Los paneles son aplicaciones de una sola página basadas en React. Eso significa que pudimos ver lo que ocurría detrás de escena con solo presionar F12. Descubrimos al menos tres variantes, cada una con distintas capacidades. Con la ayuda de nuestro asistente de IA, revisamos casi 100.000 líneas de JavaScript (la mayoría eran simplemente bibliotecas importadas) para descifrar qué podía hacer cada variante. Lo que descubrimos fue que Kali365 (¿o es Octopi365?) es un kit de PhaaS con todas las funciones, con al menos 33 señuelos distintos integrados, más de 100 endpoints de API, RBAC, un flujo completo de pagos, pagos de autoservicio a través de la pasarela de pago con criptomonedas OxaPay, y una aplicación de escritorio para los operadores: todo un ecosistema de cibercrimen.

Analizamos tres “ediciones” distintas de esto, que llamaremos (de forma arbitraria) E1, E2 y E3. Estos nombres no implican que una sea “superior” a las otras; es solo el orden en que se analizaron.

Temas comunes

Entre las tres ediciones había algunas coincidencias. Cada una tiene incorporadas las mismas 33 plantillas de señuelos de phishing. En algunas variaciones, algunos señuelos están etiquetados como “pro”, lo que sugiere que podría existir un sistema de niveles.

También común entre los tres fue una serie de rutas frontend (en el lenguaje de React, "páginas"). La lista completa está en el Apéndice A

Solo con estos endpoints, podemos obtener bastante información interesante. Primero, el endpoint de "keywords" sugiere que los operadores pueden agregar palabras clave específicas para monitorear una vez que están dentro de la cuenta de una víctima. Frases como "invoice", "wire transfer", "payment", etc. son comunes para que los atacantes las intercepten.

La ruta /domains, combinada con algunos de los endpoints de API que encontramos, muestra que el panel tiene todo un mercado integrado. Es un revendedor de dominios dentro del panel, basado en créditos; los dominios comprados se alimentan directamente a la canalización de vinculación del CF-Worker. Los operadores pueden comprar un dominio y usarlo en sus señuelos, todo sin salir de la comodidad de sus paneles.

Variantes de Kali365

E1

E1 es la que vimos principalmente en Tencent, y es la configuración base del panel: una aplicación de una sola página en React/Vite que captura sesiones de Microsoft 365 mediante Adversary-in-the-Middle (AiTM), robo de cookies por proxy inverso y señuelos con flujo de Device Code. Los operadores pueden acceder a estas sesiones a través de una bóveda de tokens, una biblioteca de 33 plantillas de señuelo, y un proxy de correo web de Outlook integrado en /dash/outlook/{id}, que les permite leer los buzones de las víctimas directamente en el panel. Los operadores reciben notificaciones de captura a través de un Bot de Telegram configurado. El tráfico de los señuelos se enruta a través de Cloudflare Workers con dominios personalizados vinculados, y Cloudflare Turnstile filtra los Bots. También hay un geo-proxy residencial opcional que hace que los registros de inicio de sesión de Microsoft parezcan originarse en el país de la víctima.

Incluso en su forma básica, E1 incluye funciones de infraestructura que lo distinguen de los kits de AiTM más antiguos. Ofrece un mercado de dominios basado en créditos en /dash/marketplace/* para obtener nuevos dominios de señuelo, una canalización de recolección de contactos que extrae los buzones de las víctimas y verifica las direcciones para

segmentación B2B, monitores de palabras clave con alertas, escaneo de MFA y administración en los tokens capturados, y un generador de scripts de sesión para los operadores que quieran reproducir sesiones manualmente.

E2

E2 es la versión de weaponization posterior al compromiso. Incluye un módulo de BEC impulsado por IA (/dash/bec/analyze, /dash/bec/drafts, /dash/bec/regenerate) que toma un mensaje capturado y lo califica según la estrategia de fraude y el nivel de confianza. Luego crea un borrador de respuesta que el operador puede enviar desde el buzón de la víctima. Este proceso se apoya en una cola de clasificación de correos de alto valor (/dash/highvalue) que resalta automáticamente los hilos de transferencias bancarias, facturas y nómina. Además del BEC, E2 tiene un escáner de credenciales que busca en los buzones capturados frases semilla, datos bancarios, claves de API y otra información sensible. También incluye un módulo de Exchange Admin que usa los tokens de administrador capturados para crear conectores de correo falsos, cambiar reglas de flujo de correo y activar o desactivar la firma DKIM para cada dominio aceptado. También puede listar los buzones del inquilino usando Graph.

E2 comparte una capa de plataforma más amplia con E3. Esto incluye un pipeline de flujo de trabajo estilo Kanban (nuevo → reconocimiento → explotación → cobro), una interfaz de claves API para operadores y un modelo de Cloudflare Worker de una sola cuenta (/dash/my-worker/*). También ofrece facturación de administrador con compra de cupos respaldada por OxaPay, y la aplicación complementaria de escritorio OctoLink Live, disponible en /downloads/, que abre una ventana real de Chromium preautenticada hacia admin.microsoft.com, entra.microsoft.com u outlook.office.com. Este enfoque evita las detecciones que buscan tráfico de Graph generado por scripts. E2 elimina por completo el nivel de revendedor. Las rutas /admin/agents/* y /agent/* que ves en E1 y E3 simplemente no están en E2. Esto concuerda con su enfoque posterior al compromiso. E2 está pensado para operadores que quieren cobrar directamente a partir del compromiso en lugar de revender acceso al panel.

E3

E3 es la edición de revendedor y autoservicio. Usa la misma capa de plataforma que E2, incluyendo el pipeline de flujo de trabajo, el modelo de Cloudflare Worker de una sola cuenta, las claves API de operador, la facturación de administrador y Kali365/Octopi365 Live. Sin embargo, no incluye los módulos posteriores al compromiso de E2, como el analizador de BEC, el escáner de credenciales, Exchange Admin o la clasificación de alto valor. En cambio, agrega los endpoints sin autenticación /api/recover-account y /api/extend-subscription. El parámetro track_id de estos endpoints acepta una URL de pago de OxaPay, un ID numérico sin procesar o un hash de transacción en cadena. Esta configuración permite que operadores nuevos o suscriptores vencidos se aprovisionen de principio a fin contra un pago en criptomonedas sin revisión humana. La recuperación de cuenta y el restablecimiento de contraseña pasan por el mismo bot de Telegram que gestiona las notificaciones de captura. Al usar /dash/forgot-password, se envía un código de seis dígitos al Telegram del operador, y /dash/reset-password completa el proceso.

En general, E3 está diseñado para distribuir acceso al panel a gran escala, con funciones de incorporación de operadores y facturación acordes, en lugar de enfocarse en maximizar el rendimiento por víctima como hace E2.

Un recorrido interactivo

Construimos un backend sencillo para mostrar cómo se ve el panel según el rol. Las siguientes capturas de pantalla contienen datos falsos, pero se generaron con los paquetes reales.

1. El engaño

Figura 6: Administrador de señuelos

El administrador de señuelos. Seis páginas de phishing desplegadas, cada una suplantando a un producto distinto de Microsoft (OneDrive, SharePoint, Teams, Outlook, DocuSign, Correo de voz) y alojada en su propio dominio personalizado con Cloudflare al frente. Los conteos de visitas y capturas a la derecha son cómo el operador mide qué está funcionando.

2. La cosecha

Figura 7: Bóveda de tokens

La Bóveda de tokens. Cada fila es una sesión en vivo de Microsoft 365 sobre la que el operador puede actuar ahora mismo. La columna de etapa (RECON / EXPLOIT / CASHOUT / DONE) es el propio rastreador de flujo de trabajo del operador; las etiquetas ADMIN marcan cuentas con privilegios a nivel de inquilino. Los botones INBOX y EXPORT a la derecha hacen exactamente lo que dicen.

3. El espionaje

Figura 8: Módulo de bandeja de entrada

Al hacer clic en el botón INBOX de un token capturado, se abre el buzón de la víctima en una vista de correo web completamente funcional, servida desde el panel.

4. Weaponization

Figura 9: Módulo BEC Intelligence

Según el código de la página, el módulo BEC Intelligence usa Claude Sonnet para evaluar conversaciones de correo interceptadas, identificar posible fraude y generar borradores de respuesta contextuales. Lo que se muestra aquí es un borrador para redirigir una transferencia bancaria, con información bancaria falsa y una falsa sensación de urgencia, preparado para que el atacante lo use desde la cuenta comprometida.

Las aplicaciones de escritorio

Mencionamos las aplicaciones de escritorio un par de veces, y logramos conseguir un par de ejecutables.

OctoLink Live

OctoLink Live (también conocido como Kali365 Live) es la aplicación de escritorio que los operadores ejecutan junto al panel de phishing. Esto es lo que convierte un token robado en un verdadero dolor de cabeza para los defensores. La aplicación es un programa de Electron creado para una sola tarea: tomar un token que el panel ya capturó y entregarle al operador una ventana de Chromium, con la sesión iniciada como la víctima. Una vez que un operador inicia sesión en /dash/auth, obtiene una bóveda de tokens desde /dash/tokens, con botones para abrir el buzón de la víctima en OWA, OneDrive, SharePoint o admin.microsoft.com. Cada apertura genera una nueva BrowserWindow en su propia partición de sesión (persist:svc-{tokenId}-{service}), de modo que los operadores pueden tener varios centros de administración abiertos a la vez sin que las cookies se mezclen entre ellos.

El detalle clave en el que los defensores deben enfocarse es cómo la aplicación logra que Microsoft emita cookies ESTSAUTH para la víctima sin ningún inicio de sesión interactivo. Para OWA, envía el access_token robado directamente a outlook.office365.com/owa/auth.owa con token_type=Bearer, copiando el flujo de inicio de sesión al estilo de autenticación basada en formularios y obteniendo cookies de sesión de OWA en una sola redirección. Para OneDrive, SharePoint y el centro de administración, la aplicación usa session.webRequest.onBeforeSendHeaders para inyectar Authorization: Bearer en los dominios de servicio permitidos, y luego se detiene en cuanto detecta una respuesta Set-Cookie. En ese momento, las cookies de sesión reales quedan almacenadas y el token bearer ya no se necesita. Si cualquiera de los dos métodos redirige a login.microsoftonline.com, la aplicación cancela la navegación y usa el refresh_token capturado dos veces en /common/oauth2/v2.0/token. Las dos solicitudes son intencionales: la primera pide openid profile offline_access, lo que hace que Microsoft establezca las cookies ESTSAUTH en esa partición; la segunda pide un alcance específico del servicio (https://outlook.office365.com/.default offline_access, https://admin.microsoft.com/.default offline_access, o el dominio de SharePoint correcto), de modo que la partición también obtenga un token de acceso utilizable para el servicio cuando la ventana visible se recarga. Un comentario en serviceWindow.js explica por qué ambos pasos ocurren en una BrowserWindow real en lugar de una llamada HTTP normal:

Figura 10: Un comentario en el código que dice “Intercambia un refresh token en el endpoint de tokens de Microsoft dentro de una ventana de navegador real oculta. Esta es la única forma de lograr que Microsoft establezca las cookies ESTSAUTH; debe ser una carga de página real de Chromium, no fetch() ni net.request.”

Una vez que esas cookies están en la partición, la ventana visible inicia sesión como la víctima sin ningún desafío de MFA y sin ningún token bearer en algún encabezado que los defensores normalmente revisarían. Si el token capturado no tiene un client_id, la aplicación usa d3590ed6-52b3-4102-aeff-aad2292ab01c, que es el ID oficial de la aplicación Microsoft Office utilizado por muchos inicios de sesión legítimos. Por sí solo, esto no es un indicador útil; solo importa cuando se combina con los otros comportamientos descritos aquí (concesión de refresh token sin inicio de sesión interactivo, la segunda concesión específica del servicio, la solicitud de token en ventana oculta y el user agent de Electron).

Para efectos de detección, esto significa que todo lo que hace un operador en estas ventanas se ve como una sesión de navegador normal que usa cookies de SSO, como si una persona real estuviera frente al teclado, y no un cliente automatizado de Graph. Los registros de inicio de sesión mostrarán la IP del operador y un User-Agent de Electron. Detectar esto es un poco complicado, especialmente con una fuerza laboral remota. Los operadores suelen usar proxies residenciales, pero los usuarios finales también forman parte frecuentemente (sin saberlo) de estas redes de proxies residenciales. Los user agents en las muestras que obtuvimos sí contienen específicamente octolink-live y octolink-sender; sin embargo, estas muestras eran versiones más antiguas, y no hemos observado que realmente aparezcan en los registros. Buscar user agents desactualizados de Chrome/Edge es lo más cercano que hemos encontrado hasta ahora.

OctoLink Sender

OctoLink Sender es la herramienta de envío masivo de correos que funciona junto con el panel para el phishing lateral. Al igual que OctoLink Live, es una aplicación basada en Electron. La aplicación toma los tokens de las víctimas desde el panel, los reactiva con un nuevo refresh token de Microsoft y envía correos como la víctima a través de Microsoft Graph. Los operadores inician sesión en el panel con una cookie de sesión (POST {panel}/login) o con una X-API-Key del panel. Los tokens se obtienen de {panel}/dash/tokens y /dash/token/{id}/raw, y se renuevan en login.microsoftonline.com/common/oauth2/v2.0/token usando un client_id por token (generalmente d3590ed6-52b3-4102-aeff-aad2292ab01c, que es la aplicación legítima de Microsoft Office) y scope graph.microsoft.com/.default offline_access. La aplicación verifica el token con una llamada a Graph /me y lo almacena en una base de datos SQLite local. El client ID d3590ed6-… por sí solo no es un buen indicador; aparece por todas partes en los inicios de sesión normales de Office. Las detecciones deben buscar los otros comportamientos: concesiones de refresh token sin inicio de sesión interactivo, el patrón “crear borrador -> enviar borrador -> eliminar/verificar” y la cadencia por oleadas.

¿Qué es el patrón “crear borrador -> enviar borrador -> eliminar/verificar”, te preguntarás? El código tiene un comentario que nos lo explica muy bien:

Figura 10: Comentario en el código que explica el enfoque de dos pasos de OctoLink Sender

Crea un borrador con POST /me/messages, lo envía con POST /me/messages/{id}/send, espera 1,5 segundos y luego verifica con GET /me/messages/{id}?$select=id,isDraft si el borrador desapareció (404 significa que se envió), y elimina cualquier borrador huérfano que Exchange haya dejado atrás. Al administrar los borradores directamente, el motor puede detectar y limpiar sus propias huellas. El motor solo ejecuta un trabajo a la vez (MAX_CONCURRENT_JOBS = 1 en ipc/sender.js), así que cada instancia de Sender es un único flujo de salida por servidor. Si estás monitoreando el volumen desde un endpoint, espera un rendimiento lineal, no paralelo. Dentro de ese flujo, el motor está ajustado para cuidar la reputación: un límite fijo de 2.500 envíos por token al día, envíos en oleadas de 80 con un enfriamiento de 120 segundos (el token se renueva discretamente durante la pausa), un retraso base de 4 segundos con variación aleatoria, un aumento gradual cada 10 envíos y "pausas humanas" aleatorias de 5 a 12 segundos cada 12 a 19 envíos. Si Exchange arroja errores como bad outbound sender, 550 5.1.8, 5.7.1, suspected of sending spam, o sender was not authenticated, el motor detiene el trabajo y le indica al operador que espere de 1 a 4 horas. No se reanuda automáticamente, pero deja de consumir el token. Si encuentra un error 401 / InvalidAuthenticationToken en medio de un trabajo, renueva el token y vuelve a intentar con el mismo destinatario.

Que un borrador no exista parecería ser un evento bastante singular, sobre todo después de haberse enviado, así que esto podría ser una buena oportunidad de detección. Sin embargo, la falla crítica es que Microsoft, al parecer, no registra los 404 en el UAL. Dada esta limitación, buscar anomalías en los patrones de envío probablemente sea la mejor forma de detección. Este es realmente un caso donde "más vale prevenir que curar".

Otra función interesante de OctoSender: el latido de la suscripción falla en modo abierto. Si recibe cualquier error o una respuesta que no sea 2xx, checkSubscriptionStatus simplemente devuelve { active: true, tier: 'pro', days_left: 999 } con un comentario de que un 404 o error significa "todavía activo". Así que desconectar el panel no detiene un Sender en ejecución. La herramienta simplemente se otorga a sí misma una suscripción premium si no puede comunicarse con el C2.

Conclusión

Una investigación a fondo del ecosistema más amplio de Kali365 revela una plataforma de PhaaS madura que apunta a tokens y busca lanzar ataques secundarios de BEC y fraude a través de buzones de correo comprometidos. Ya vimos el impacto del PhaaS con EvilTokens en febrero de 2026, pero un análisis más reciente de varias variantes de Kali365 muestra lo rápido y efectivo que es el flujo de ataque.

Si un empleado ocasionalmente necesita entrar a la oficina durante la noche, no dejas la puerta sin seguro todo el tiempo: le das una llave. Permitir que cualquier persona en la organización use el flujo de código de dispositivo es dejar tu oficina virtual sin seguro. Microsoft recomienda que "las organizaciones se acerquen lo más posible a un bloqueo unilateral del flujo de código de dispositivo", y estamos de acuerdo. Si un empleado tiene una necesidad legítima de usarlo, se puede crear una excepción, pero la gran mayoría nunca la necesitará.

Los "posibles IoC" enlazados abajo son una combinación de direcciones IP que Huntress ha observado iniciando sesión activamente en cuentas, y otras en las que encontramos el panel de Kali365 en ejecución. Por brevedad, algunas IP individuales se han consolidado en rangos más grandes. A la fecha de esta publicación, muchas todavía tienen el panel en ejecución, pero los ataques desde estas direcciones en general se han reducido a un goteo.

Los indicadores de compromiso (IoC) de esta amenaza se han compartido en el Github de Huntress Labs.

Reglas de búsqueda:

let operatorASNs = dynamic(["132203"]);

let operatorCIDR = "43.173.64.0/20";

SigninLogs

| where ResultType == "0"

| where AutonomousSystemNumber in (operatorASNs)

or ipv4_is_in_range(IPAddress, operatorCIDR)

| where UserAgent contains "python-requests"

| project TimeGenerated, UserPrincipalName, IPAddress, AutonomousSystemNumber,

UserAgent, AppDisplayName, AppId, AuthenticationProtocol,

ResourceDisplayName, Location

| sort by TimeGenerated desc

Referencias:

PSA del FBI, “El kit Kali365, basado en el modelo de phishing como servicio, secuestra tokens de acceso de Microsoft 365”