Saltar al contenido
Beveiligingsnieuws

TWINLOOT: robo de credenciales con SharePoint y Teams

TWINLOOT SharePoint Teams

Un nuevo implante malicioso, conocido como TWINLOOT, está llamando la atención por su forma de esconder la comunicación de mando y control dentro de servicios confiables de Microsoft. Según un informe técnico compartido por Ontinue, el framework está construido como un implante modular en Python, endurecido con PyArmor, y diseñado para operar con una infraestructura de C2 distribuida en componentes legítimos de Microsoft 365.

Lo más preocupante es que TWINLOOT no se limita a ejecutar tareas: también busca credenciales, posibilita movimiento lateral dentro de la red y persiste en el equipo comprometido, todo mientras intenta que el tráfico resultante sea indistinguible del comportamiento normal de la organización.

Cómo funciona TWINLOOT con servicios Microsoft

TWINLOOT basa su arquitectura en varios canales de C2, cada uno apoyado en una pieza distinta del ecosistema de Microsoft. De acuerdo con el reporte, los elementos clave son:

  • SharePoint Online como punto de dead-drop para recibir tareas mediante llamadas relacionadas con la Graph API.
  • Teams TURN como infraestructura de relevo para el acceso interactivo del operador.
  • Navegador Edge del propio equipo del objetivo en modo headless, usado como “transporte” para ofuscar el tráfico hacia la Graph API.

Esta combinación busca un objetivo claro: aprovechar servicios que, en condiciones normales, serían considerados legítimos dentro de una empresa, reduciendo señales que alerten a los sistemas defensivos.

La tarea se “desbloquea” desde SharePoint

En el canal de SharePoint, TWINLOOT autentica contra el inquilino (tenant) de Azure del atacante y realiza un sondeo periódico para identificar instrucciones. El reporte indica una cadencia de aproximadamente cada 15 segundos. Con ese flujo, el operador puede ordenar acciones y también recibir datos exfiltrados de vuelta hacia el servidor.

Además, el implante utiliza el navegador Edge para que las comunicaciones con la Graph API ocurran de manera que parezcan parte del tráfico ordinario de red, al transportar las solicitudes desde una instancia controlada en segundo plano.

Acceso interactivo y movimiento lateral con SOCKS5

El segundo gran componente de TWINLOOT permite una operación más “humana”: una forma de acceso interactivo que se apoya en un túnel inverso SOCKS5. Tras desplegarse en la máquina víctima, el operador obtiene un listener local (referenciado como 127.0.0.1:1080) y realiza un enrutamiento de tráfico hacia la red interna del objetivo mediante un proceso proxy.

Este túnel puede emplear dos variantes: una conexión directa por TLS/WebSocket hacia el servidor del atacante o un relevo a través de Teams TURN mediante WebRTC DataChannels.

Desde la perspectiva de la víctima, las conexiones hacia otros sistemas internos aparentan ser del propio host comprometido. El reporte menciona destinos y puertos típicos para administración y servicios remotos, como:

  • 445 (SMB)
  • 3389 (RDP)
  • 5985 (WinRM)
  • 1433 (MSSQL)

En otras palabras, TWINLOOT no solo “manda” instrucciones: también crea condiciones para ampliar el impacto y escalar dentro del entorno.

Robo de credenciales con pantallas de bloqueo falsas

La función de recolección de credenciales es uno de los puntos más delicados del ataque. TWINLOOT utiliza pantallas de bloqueo falsas que, según el informe, están diseñadas para ser lo suficientemente convincentes como para provocar la introducción del password por parte de la víctima.

El mecanismo se activa cuando el atacante envía el comando “credz_waiting”. Una vez que la pantalla falsa aparece, el usuario ingresa su contraseña. El reporte añade un detalle relevante: la contraseña introducida no se valida contra la autenticación real de Windows. Independientemente de lo que se escribe, el sistema muestra un mensaje de error del tipo “la contraseña es incorrecta”, lo que probablemente empuje a la víctima a intentarlo nuevamente.

Cuando se introduce el password (y tras el flujo indicado), la pantalla falsa se cierra de forma automática. A continuación, TWINLOOT cifra las credenciales capturadas y las sube por el canal de SharePoint para que puedan ser utilizadas después a través del túnel SOCKS5.

Ese robo no termina en el exfiltrado: las credenciales se usan para pivotar hacia el siguiente host, habilitando acceso por protocolos como RDP o WinRM.

Canal a través de Edge: por qué el tráfico parece legítimo

Un rasgo distintivo descrito por Ontinue es el uso de una instancia sin interfaz del navegador Edge para “mover” el tráfico que interactúa con la Graph API. El implante activa un modo headless y usa una combinación de técnicas que hace que la comunicación se refleje como actividad cercana a lo que un navegador real podría generar.

Este enfoque busca disminuir el contraste con tráfico normal y complicar la correlación para defensores. En entornos donde el navegador se usa rutinariamente para tareas relacionadas con Microsoft 365, el camuflaje resulta especialmente valioso.

Cómo llega TWINLOOT al sistema: ingeniería social vía Teams

El acceso inicial del ataque, según el análisis, se basa en una campaña de ingeniería social usando Microsoft Teams. El atacante se hace pasar por soporte de TI y persuade al objetivo para ejecutar un comando de PowerShell.

Ese comando, en el flujo descrito, descarga un archivo de paquete que contiene el runtime de Python y un payload compilado de aproximadamente 39 MB, identificado como bootstrap-fat.pyc. Ese archivo actúa como cargador para desplegar TWINLOOT.

Persistencia y endurecimiento del implante

Una vez instalado, el malware establece persistencia en función de una configuración de build (indicada como PERSIST_ENABLED con valores verdaderos o falsos). El reporte describe que utiliza cuatro métodos para mantener el acceso:

  • Hijacking de TypeLib mediante scriptlet COM.
  • Manipulación estilo GhostTask relacionada con TaskCache.
  • Actualización propia usando un manifiesto reobf.json.
  • Uso de una herramienta de código abierto llamada Swarmer para convertir exportaciones del Registro en hives de Windows.

En el método que usa Swarmmer se busca crear claves en HKEY_CURRENT_USER (HKCU) de forma sigilosa, incluso cuando no hay privilegios de administrador. El informe explica que TWINLOOT arma un perfil obligatorio (mandatory profile hive) de manera offline mediante APIs como RegLoadAppKeyW y utilidades de librería de registro fuera de línea (referida como offreg.dll), y luego escribe el resultado en %USERPROFILE%\NTUSER.MAN.

Como consecuencia, cuando Windows carga el perfil de usuario, revisa si existe NTUSER.MAN antes de usar NTUSER.DAT. Si el archivo existe, sus contenidos toman prioridad.

Ecosistema: una tendencia hacia el abuso de TURN y navegación headless

Este hallazgo no ocurre en el vacío. El reporte contextualiza que, a lo largo de 2026, actores maliciosos han adoptado mecanismos basados en relevo TURN para ocultar tráfico de C2 dentro de infraestructuras asociadas a Teams.

En junio de 2026, por ejemplo, se detalló el uso del mecanismo TURN por parte de un RAT vinculado a ransomware (Backdoor.Turn) para ocultar su comunicación. Más adelante, también se observó otro malware basado en Rust (msaRAT) con un patrón similar pero dirigido a Twilio, usando señalización y WebRTC para construir un túnel encubierto.

Lo relevante aquí es que TWINLOOT se suma a la lista de herramientas que, de forma independiente, convergen en ideas como: apoyarse en el navegador como transporte y usar canales de relevo para esconder comunicaciones.

¿Quién está detrás de TWINLOOT?

Por ahora no hay certeza sobre el responsable del toolkit. Sin embargo, Ontinue señala paralelismos operativos con un conjunto conocido por orquestar campañas de vishing por Teams (asociadas a STAC4749) y, al mismo tiempo, menciona coincidencias como el uso de un backdoor Python ofuscado, un proxy inverso SOCKS5 y persistencia tipo HKCU Run Key.

Aun así, el informe remarca que la implementación subyacente difiere de forma significativa: TWINLOOT emplea ejecución directa de .pyc, implementación integrada de un multiplexor SOCKS5 y un enfoque de dead-drop con SharePoint, mientras que otras herramientas mencionadas utilizan empacado distinto y componentes diferentes.

Capacidades adicionales más allá del robo

Más allá de credenciales y movimiento lateral, TWINLOOT también se describe con funciones de reconocimiento y recolección, captura de pantallas y capacidad de recuperación de configuración en caso de fallar un método específico relacionado con dead-drop usando almacenamiento de Azure Blob. El reporte indica además que una parte relacionada con resolución basada en Ethereum no estaría activada en el build analizado, lo que sugiere desarrollo continuo del framework.

Conclusión

TWINLOOT ejemplifica una evolución peligrosa de las amenazas: no solo intenta infectar, sino que construye una cadena operativa donde cada etapa se apoya en servicios legítimos de Microsoft. Al abusar de SharePoint Online para tareas, usar Teams TURN para accesos interactivos y transportar comunicaciones a través de Edge en modo headless, el implante intenta reducir señales que normalmente delatarían el comportamiento malicioso.

Para organizaciones, el mensaje es claro: la seguridad no puede basarse únicamente en bloquear “malware conocido”, sino que debe reforzar detecciones sobre patrones de abuso en Microsoft 365, telemetría de cambios en ejecución de scripts, y señales de comportamiento anómalo en endpoints y accesos laterales.

Fuente: https://thehackernews.com/2026/08/twinloot-abuses-sharepoint-and-teams-to.html