TwinLoot convierte Microsoft 365 en un centro de mando para atacar redes corporativas

Un framework de Python que opera en la nube de Microsoft

Los investigadores del Ontinue Cyber Defense Center identificaron TwinLoot, un framework de malware modular escrito en Python que traslada el modelo living off the land a la nube. El sistema no se limita a utilizar herramientas ya presentes en Windows: construye su infraestructura de comando y control aprovechando servicios legítimos de Microsoft Azure y Microsoft 365.

La campaña seguía activa en julio, cuando se recuperaron los módulos del malware. La actividad fue detectada el 18 de agosto de 2026.

TwinLoot utiliza SharePoint Online y las API de Microsoft Graph para intercambiar comandos y datos, Microsoft Teams para obtener acceso interactivo y Microsoft Edge para hacer más creíbles las comunicaciones generadas desde el dispositivo comprometido. De este modo, el tráfico puede confundirse con la actividad habitual de usuarios y aplicaciones corporativas.

Los módulos de Python estaban protegidos con PyArmor 9.2.5. Tras descifrar la configuración incorporada, apareció una arquitectura compuesta por varios canales operativos, diseñada para reducir la visibilidad del atacante y mantener el control incluso después de la intrusión inicial.

SharePoint, Graph y Teams se convierten en la infraestructura C2

El componente de comando y control utiliza SharePoint Online como punto de intercambio, siguiendo el modelo de dead drop: el atacante deposita comandos o datos en un espacio de la nube y el malware los recupera mediante API legítimas de Microsoft.

Las API de Microsoft Graph desempeñan el papel de canal de aplicación. En lugar de conectarse a un servidor sospechoso o a un dominio con mala reputación, TwinLoot interactúa con una infraestructura ampliamente presente en las redes corporativas.

El framework incorpora además la infraestructura de relay TURN de Microsoft Teams. Esta tecnología, destinada normalmente a facilitar las comunicaciones interactivas, se aprovecha para mantener un enlace operativo con el sistema infectado. El resultado es un canal que puede parecer coherente con el tráfico generado por Teams, especialmente cuando se analiza sin correlacionar identidades, endpoints y actividad en la nube.

Microsoft Edge contribuye a ocultar aún más las solicitudes a las API de Graph. El navegador presente en el dispositivo de la víctima se utiliza para transportar las comunicaciones, mientras que la automatización del navegador y el posible uso de componentes headless dificultan distinguir una actividad maliciosa de la generada por una aplicación corporativa.

Según la evaluación de los investigadores, TwinLoot es el primer framework que han observado que combina en una única infraestructura el dead drop sobre Microsoft 365, el abuso del relay TURN de Teams y el transporte mediante navegador.

Capacidades: credenciales, comandos y pivoting en la red interna

TwinLoot incluye un módulo para robar credenciales de Windows. El malware muestra una pantalla de bloqueo falsa, diseñada para parecerse a la legítima del sistema operativo, y solicita al usuario que introduzca su contraseña.

La recopilación también se produce cuando el intento falla. Si la credencial es incorrecta, la víctima ve un mensaje compatible con un error normal de autenticación y puede volver a intentarlo. Si el siguiente intento tiene éxito, el comportamiento anómalo puede no resultar evidente.

Esta lógica permite capturar contraseñas sin generar necesariamente señales fáciles de reconocer para el usuario. Por ello, las solicitudes inesperadas de autenticación o las pantallas de bloqueo que aparecen fuera del flujo operativo habitual deben investigarse, especialmente si se repiten.

El framework también permite ejecutar comandos arbitrarios en el sistema comprometido. Así, el atacante puede recopilar información, modificar el comportamiento del endpoint y preparar nuevas actividades.

El componente más relevante para el movimiento lateral es un proxy interactivo SOCKS5. El proxy enruta el tráfico a través del proceso infectado y puede permitir el acceso a recursos de la red interna que no están expuestos directamente a Internet. De este modo, un único equipo comprometido se convierte en un punto de pivoting para realizar reconocimiento, acceder a otros sistemas e interactuar con servicios corporativos.

Persistencia sin privilegios administrativos

TwinLoot también adopta una técnica de persistencia denominada por los investigadores “Corrupting the Hive Mind”. El método crea offline un hive de perfil obligatorio, o mandatory profile hive, utilizando API legítimas de Windows.

La técnica no requiere privilegios administrativos ni modifica directamente el Registro durante la instalación. Por ello, puede no generar los eventos que normalmente se asocian con una modificación del Registro o con una operación de elevación de privilegios.

Esto reduce la eficacia de algunas reglas de detección tradicionales. Una organización que busque únicamente claves del Registro alteradas, procesos administrativos o actividad con privilegios elevados podría no detectar esta persistencia.

Ontinue describe este comportamiento como el primer uso malicioso de este método observado en actividad real. La persistencia aprovecha funciones nativas del sistema operativo y deja una huella operativa menor que las técnicas basadas en cambios evidentes de configuración.

Preparación minuciosa, pero atribución aún incierta

La arquitectura observada apunta a una preparación de siete semanas. Antes del uso operativo se habrían configurado dos dominios caducados, una aplicación específica de Azure AD y un sitio de SharePoint destinado a actuar como dead drop.

El framework de Python también integraba una herramienta presentada originalmente durante una conferencia tecnológica. Los dominios se habían preparado varias semanas antes que el resto de la infraestructura.

La operación no se ha atribuido a un grupo concreto. El nivel de integración entre offensive security, Python, identidades en la nube y servicios de Microsoft hace plausible la participación de un operador profesional o de un desarrollador con conocimientos avanzados del ecosistema de Azure y Microsoft 365.

No se han divulgado las versiones de los productos de Microsoft implicados, ni las direcciones IP, los dominios utilizados, los hashes u otros indicadores concretos. Tampoco se han comunicado identificadores CVE, una puntuación CVSS ni una inclusión en el catálogo KEV de CISA; por tanto, no hay una fecha de incorporación ni un plazo de mitigación KEV que indicar.

Cómo buscar TwinLoot sin depender únicamente de los indicadores

El tráfico hacia Microsoft 365 no debe considerarse fiable por definición. La defensa debe centrarse en las desviaciones respecto al comportamiento esperado de usuarios, dispositivos, aplicaciones y servicios.

Las organizaciones deberían establecer líneas base para SharePoint, Teams y las API de Graph, teniendo en cuenta volúmenes, frecuencia, horarios, destinos y métodos de acceso. Las secuencias inusuales de llamadas a Graph, especialmente cuando están asociadas a una cuenta o un dispositivo que normalmente no las realiza, requieren una investigación.

También es necesario revisar las aplicaciones OAuth y las concesiones de consentimiento de Azure AD. Las aplicaciones inesperadas, los permisos desproporcionados o las nuevas integraciones con SharePoint y Graph pueden indicar la preparación del canal C2.

La telemetría de SharePoint y Teams debe correlacionarse con la de los endpoints. Los sitios, archivos, sesiones de relay y flujos de comunicación anómalos adquieren especial relevancia cuando coinciden con un uso inusual de Edge, automatización del navegador, scripts de Python o módulos protegidos con PyArmor.

Las reglas de detección también deben incluir solicitudes repetidas de autenticación, pantallas de bloqueo inesperadas e intentos de acceso fallidos seguidos de una autenticación correcta. En el caso de TwinLoot, la contraseña introducida por el usuario podría haber sido capturada ya en el primer intento.

Por último, conviene buscar señales compatibles con un proxy SOCKS5, conexiones interactivas no previstas y accesos a recursos internos procedentes de endpoints que normalmente no realizan tareas de administración o pivoting. La correlación entre identidad, nube y endpoint es esencial: analizar estos tres niveles por separado deja amplios márgenes de maniobra al atacante.