Noticias
TWINLOOT: el «soporte técnico» te llama por Teams y te roba la contraseña con una pantalla de bloqueo falsa de Windows
La firma de seguridad Ontinue publicó este martes el análisis de TWINLOOT, un implante de Windows escrito en Python que esconde toda su infraestructura de control adentro de servicios legítimos de Microsoft: recibe órdenes por un SharePoint Online, saca el tráfico por el navegador Edge de la propia víctima y, cuando el operador lo decide, dibuja una pantalla de bloqueo falsa de Windows para quedarse con la contraseña.
La puerta de entrada no fue una vulnerabilidad. Fue una llamada de Microsoft Teams en la que alguien se hizo pasar por el soporte técnico de la empresa y convenció a un empleado de pegar un comando de PowerShell. El resto lo hizo el implante.
- Qué es TWINLOOT y qué encontró Ontinue
- La llamada del «soporte técnico» que abre la puerta
- El centro de mando que vive adentro de Microsoft
- La contraseña siempre está mal: así funciona el engaño
- NTUSER.MAN: la persistencia que no pide permisos de administrador
- Qué corta la cadena, según el propio informe
- ¿Y esto qué significa para vos?
- Preguntas frecuentes
Qué es TWINLOOT y qué encontró Ontinue
TWINLOOT es un marco de implante modular escrito en Python y endurecido con PyArmor. El nombre no se lo puso el atacante: se lo puso Ontinue, por la carpeta de SharePoint que el implante usa como buzón de órdenes, llamada TwinLoot. El informe completo, firmado por el investigador Rhys Downing, salió el 18 de agosto de 2026 y describe un hallazgo del Cyber Defense Center de la empresa durante la investigación de una campaña en curso en julio.
El detalle que le da peso al análisis es cómo lo abrieron. El cargador de primera etapa venía sin ofuscar, pero la segunda —unos 120 módulos— estaba protegida con PyArmor 9.2.5 Pro. Ontinue descifró 115 de esos ~120 módulos de forma estática, con una herramienta de código abierto y sin necesidad de un entorno aislado. De ahí salió todo lo demás: cada dirección de control, cada comando del operador y cada mecanismo de persistencia. Hasta las rutas de la máquina donde se compiló quedaron adentro del bytecode, con los módulos fechados el 24 de julio de 2026 entre las 18:13 y las 18:15 UTC.
| Dato | Detalle |
|---|---|
| Nombre | TWINLOOT (por la carpeta TwinLoot del SharePoint de control) |
| Quién lo publicó | Ontinue — Cyber Defense Center, 18 de agosto de 2026 |
| Qué es | Implante modular en Python, endurecido con PyArmor 9.2.5 Pro |
| Acceso inicial | Llamada de Teams haciéndose pasar por soporte de TI + un comando de PowerShell |
| Canales de control | SharePoint Online (buzón), túnel SOCKS5 inverso, retransmisión TURN de Teams |
| Robo de credenciales | Pantalla de bloqueo falsa de Windows 10 y 11, sin validación alguna |
| Atribución | Ninguna: Ontinue dice no haber hallado vínculo con ningún actor conocido |
| Nivel de sigilo | Tan alto que el mérito del informe es haber podido contarlo |
La llamada del «soporte técnico» que abre la puerta
Acá no hay exploit, ni día cero, ni parche pendiente. Según Ontinue, el vector de acceso inicial fue una llamada por Microsoft Teams en la que el atacante se presentó como soporte de TI y logró que la persona ejecutara un comando de PowerShell. Ese comando baja un archivo comprimido con dos cosas: un intérprete de Python legítimo y firmado, y una carga compilada de 39 MB llamada bootstrap-fat.pyc que hace de cargador.
El informe es explícito sobre lo que eso implica, y conviene leerlo entero antes de sacar conclusiones sobre qué software te habría salvado:
El acceso inicial se logró a través de una llamada de Teams suplantando al soporte de TI, una técnica que no requiere ningún exploit técnico y elude por completo los controles de endpoint.Ontinue, informe «Living Off the Cloud» — vía el análisis original
Es la misma familia de problema que vimos en otro ataque reciente que no explota un bug sino una función que Windows tiene documentada: cuando la cadena arranca en algo que el sistema considera normal, la defensa deja de ser técnica y pasa a ser una decisión de la persona que está del otro lado.
El centro de mando que vive adentro de Microsoft
Una vez adentro, el implante corre como pythonw.exe y levanta dos canales en paralelo: un buzón que consulta una unidad de SharePoint cada 15 segundos buscando órdenes y devolviendo lo que robó, y un túnel SOCKS5 inverso que le da al operador acceso interactivo con hasta 128 conexiones simultáneas.
Acá está el punto que la cobertura no suele aclarar y que cambia por completo cómo hay que leer la noticia: el SharePoint que se usa no es el tuyo. El implante se autentica con credenciales embebidas contra el inquilino del atacante, así que en los registros de inicio de sesión de la organización víctima no queda ningún rastro.
El entorno de Microsoft 365 de la organización víctima no participa en este flujo de autenticación.Ontinue, informe «Living Off the Cloud» — vía el análisis original
El tercer truco es el más incómodo para quien tiene que detectarlo. En vez de hablar con la API de Microsoft Graph desde el proceso de Python, el implante abre el propio Edge de la víctima en modo headless, se conecta al navegador por su interfaz de depuración y lanza los pedidos desde adentro de una pestaña. Para la telemetría de red, el tráfico de control es el navegador del usuario hablando con Microsoft, porque literalmente lo es. Ontinue lo resume así: cualquier regla de detección que se fije en python.exe o pythonw.exe comunicándose con Graph va a pasar esto por alto por completo. Un resquicio queda, y el informe lo señala: el pedido del token todavía lo hace Python por su cuenta, y ahí sí hay costura.
El canal interactivo tiene además una variante que viaja por la infraestructura de medios de Teams: retransmisiones TURN de Microsoft, con credenciales robadas en vivo de los puntos de acceso para invitados anónimos de Teams. Es el segundo caso observado en el mundo real de abuso de TURN de Teams —el primero fue Backdoor.Turn, de DragonForce, documentado por Symantec en junio de 2026— y el primero que usa canales de datos WebRTC propiamente dichos.
| Canal | Por dónde sale | Para qué sirve | Por qué cuesta verlo |
|---|---|---|---|
| Buzón de SharePoint | graph.microsoft.com y un SharePoint del atacante | Órdenes, resultados y robo de datos, cada 15 segundos | Es tráfico normal hacia dominios de Microsoft |
| Túnel SOCKS5 inverso | TLS/WebSocket directo o TURN de Teams | Acceso interactivo y salto a otras máquinas | Sale del propio pythonw.exe de la víctima |
| Transporte por Edge headless | El navegador de la víctima, vía depuración remota | Llevar el tráfico de Graph sin que lo emita Python | Es el navegador del usuario, con su perfil real |
El informe también señala dónde sí queda una costura: pythonw.exe abriendo conexiones hacia varias direcciones internas por puertos administrativos —445, 3389, 5985, 22, 1433, 135 y 389— no es comportamiento normal de una estación de trabajo, sin importar con qué credenciales se haga.
La contraseña siempre está mal: así funciona el engaño
Cuando el operador manda el comando credz_waiting, el implante dibuja una pantalla de bloqueo falsa. Y no es un cartel genérico: usa kits distintos para Windows 10 y Windows 11 —elegidos según el número de compilación del sistema— y los rellena con tus datos reales. El nombre para mostrar de la cuenta, la foto de perfil sacada de la carpeta de imágenes de cuenta de Windows y el fondo de pantalla de bloqueo leído del registro. Antes de aparecer, un fundido a negro de 250 milisegundos tapa la transición. La ventana va a pantalla completa, siempre encima y con el botón de cerrar desactivado.
Lo que sigue es el detalle más importante de todo el informe para un usuario común, y es el que casi nadie contó: esa pantalla no valida absolutamente nada. No compara lo que escribís contra la autenticación de Windows ni contra ningún otro mecanismo. Cada intento se empaqueta, se cifra y se sube al SharePoint del atacante.
Entonces, ¿por qué te dice que la contraseña está mal? Porque es el diseño. Tras el primer intento siempre muestra el mensaje «The password is incorrect. Try again» —igual que la pantalla real cuando te equivocás— y se cierra después del segundo. Ontinue explica el resultado sin rodeos: así se llevan normalmente tanto la contraseña mal tipeada como la correcta. El que se equivoca una vez y acierta a la segunda le entregó las dos.
Hay una decisión de diseño del atacante que vale la pena conocer: el bloqueo de la ventana es deliberadamente mínimo. Está en pantalla completa y siempre encima, pero el informe dice que no instala enganches de teclado ni usa BlockInput —lo declara en el código y no lo llama—. El desarrollador cambió encierro por confiabilidad. Que la pantalla sea inescapable es, en este implante, más apariencia que mecanismo.
Un último matiz que el informe pide expresamente no malinterpretar: la variante HTML de esa pantalla toma prestado el maquetado de un proyecto público de GitHub y descarga en caliente un video de fondo, así que solo se dibuja en equipos con salida a internet. Ontinue aclara que buscó y no encontró nada que conecte a ese proyecto ni a quienes lo mantienen con la campaña —parece haber sido elegido de manera oportunista, como maquetado ya hecho—, y que por eso lo dejó deliberadamente fuera de la tabla de indicadores: no es infraestructura del atacante. Avisa además de algo más: bloquear esa descarga hace que la pantalla no aparezca, pero que la pantalla no aparezca no prueba que el implante haya fallado.
NTUSER.MAN: la persistencia que no pide permisos de administrador
TWINLOOT trae cuatro mecanismos para quedarse en la máquina, y en la muestra analizada ninguno se activa solo: los dispara el operador. Tres son conocidos —un secuestro de COM por TypeLib, una manipulación del registro de tareas programadas al estilo GhostTask que vuelve la tarea invisible para el Programador de tareas, y un mecanismo de autoactualización—. El cuarto es el que convierte al informe en noticia técnica: es, según Ontinue, la primera vez que se registra su uso malicioso en el mundo real.
La técnica se llama forjado de perfil obligatorio y la investigó Praetorian en enero de 2026. Funciona así: Windows, al cargar el perfil de un usuario, revisa primero si existe un archivo NTUSER.MAN y solo después usa el NTUSER.DAT habitual. Si el .MAN está, manda él. El implante fabrica ese archivo completamente fuera de línea, con una función y una biblioteca del propio Windows, y lo deja en la carpeta del perfil del usuario. Las consecuencias, según Ontinue:
- No hace falta ser administrador: el usuario es dueño de su propia carpeta de perfil.
- No genera eventos de modificación del registro, porque nunca se escribe sobre el registro vivo.
- Sobrevive a los cierres y aperturas de sesión.
- La mayoría de las herramientas que buscan persistencia no lo marcan.
Dicho de otro modo: el mecanismo que más cuesta encontrar es también el que menos privilegios necesita. Es exactamente al revés de la intuición.
Qué corta la cadena, según el propio informe
Ontinue cierra con una lista de recomendaciones, y lo honesto es decir de entrada que están escritas para equipos con administración de TI. Igual hay dos que cualquier PyME con Microsoft 365 puede aplicar, y una que es gratis y rompe una pata entera del ataque.
La más concreta son dos directivas de Microsoft Edge. El transporte por navegador necesita el modo headless y la depuración remota; el informe dice que deshabilitar cualquiera de las dos rompe la técnica. Microsoft las documenta con nombre propio: HeadlessModeEnabled, «Control use of the Headless Mode» y RemoteDebuggingAllowed, «Allow remote debugging», las dos bajo Plantillas administrativas / Microsoft Edge. Y no es solo para quien tiene editor de directivas: la misma documentación publica la ruta de registro, SOFTWARE\Policies\Microsoft\Edge, con el valor HeadlessModeEnabled de tipo REG_DWORD. La salvedad, que el informe también hace: hay que excluir las máquinas de desarrollo donde el navegador headless es una herramienta de trabajo.
| Medida del informe | Qué corta | ¿Aplicable en una PyME chica? |
|---|---|---|
| Deshabilitar modo headless o depuración remota en Edge | El transporte del tráfico de control por el navegador | Sí: por directiva de grupo o por la clave de registro que Microsoft documenta |
| Restringir el acceso externo de Teams | La llamada del falso soporte técnico | Sí, es una opción de administración de Microsoft 365 |
| Sospechar de Python corriendo desde carpetas del usuario | La ejecución del implante | Parcial: requiere alguien mirando la telemetría |
| Vigilar conexiones a SharePoint ajenos a la organización | El buzón de órdenes | Difícil sin herramientas de red |
| Resetear la contraseña de quien vio la pantalla falsa y revocar sus sesiones | El uso posterior de la credencial robada | Sí, y es lo primero que hay que hacer |
| Llaves FIDO2 y passkeys | El robo de credenciales, de raíz | Sí: es la única que el informe describe como eliminación total, y la pide para toda la organización |
Sobre la última —métodos de autenticación resistentes al phishing, como llaves FIDO2 y passkeys—, el informe no se anda con matices, y el alcance va adentro de la propia frase:
Implementarlos en toda la organización elimina por completo la técnica de robo de credenciales, sin importar lo convincente que sea la pantalla de bloqueo falsa.Ontinue, informe «Living Off the Cloud» — vía el análisis original
Conviene saber también que esto no es un caso cerrado: Ontinue dice haber verificado que el canal desde el que el implante refresca su configuración seguía activo al momento de publicar, y lee eso como actividad en curso del operador. Y publicó los indicadores de compromiso en un repositorio público: el documento lleva en el nombre la fecha en que se observó la actividad, el 27 de julio, pero el archivo se subió al repositorio el 17 de agosto, un día antes del informe. Dicho de otro modo, la ventaja que le lleva la defensa al atacante acá se mide en horas, no en semanas.
¿Y esto qué significa para vos?
Si trabajás solo en tu casa, la probabilidad de que TWINLOOT te toque es baja: está armado para moverse por redes con dominio y máquinas vecinas. Pero la parte reutilizable del ataque es la que menos tecnología tiene: alguien te contacta por una herramienta que usás en el trabajo, dice ser de soporte y te pide que ejecutes algo. El resto del informe describe lo que pasa después de ese sí.
Tres cosas para llevarse, sin humo. La primera: ningún soporte técnico legítimo te va a pedir que pegues un comando en PowerShell durante una llamada que no pediste. La segunda: una pantalla de bloqueo no prueba nada por sí sola —esta copia a la verdadera hasta en el rechazo del primer intento—, así que ante la sospecha la contraseña se cambia desde otro equipo y se cierran las sesiones abiertas. La tercera: el ataque no roba tu contraseña para entrar a tu máquina, en la que ya está; la roba para saltar a las demás.
Ese último punto es el que ordena la decisión de compra, y conviene decirlo sin exagerar: un antivirus de consumo no es un sistema de detección corporativo y no ve un túnel escondido dentro de tráfico legítimo de Microsoft. Lo que sí resuelve es la cobertura, que en las oficinas chicas suele ser el agujero real —una licencia en la máquina del dueño y nada en las otras cuatro—. Si ese es tu caso, una licencia de Bitdefender Premium Security para 10 dispositivos cubre el parque entero, incluidos los teléfonos y las Mac. Y las dos medidas gratis que el informe destaca —las passkeys, que eliminan el robo de credenciales, y las directivas de Edge, que rompen el transporte por navegador— no cuestan un peso.
Preguntas frecuentes sobre la pantalla de bloqueo falsa
¿Hackearon el SharePoint de mi empresa?
No. El informe de Ontinue es explícito: el implante se autentica contra un inquilino de Azure del atacante, no contra el de la víctima, y por eso el entorno de Microsoft 365 de la organización afectada no participa en ese flujo. En los registros de inicio de sesión de la empresa no aparece nada. La detección tiene que buscarse en el equipo y en la red.
¿Cómo sé si una pantalla de bloqueo de Windows es falsa?
Por diseño, casi no se puede: usa tu nombre real, tu foto de perfil y tu fondo de pantalla. Y el rechazo del primer intento tampoco sirve de pista, porque imita el comportamiento de la pantalla verdadera. Ontinue no ofrece ninguna señal visual. Lo que queda es la política: si sospechás, cambiá la contraseña desde otro equipo y revocá las sesiones abiertas.
¿Un antivirus me protege de este ataque?
El informe no lo evalúa: no menciona antivirus de consumo en ningún momento y las herramientas de detección que nombra son corporativas. Y las dos cosas que sí dice apuntan en contra: el acceso inicial «elude por completo los controles de endpoint», y la persistencia más nueva «no la marca la mayoría de las herramientas estándar». Lo que llama definitivo contra el robo de la contraseña es FIDO2 o passkeys.
¿Se sabe quién está detrás de TWINLOOT?
No. Ontinue dice no haber encontrado solapamiento de infraestructura, herramientas compartidas ni linaje de código que lo conecte con ningún actor o familia de malware conocida. Anota parecidos operativos con un grupo que Sophos rastrea como STAC4749, pero aclara que con la evidencia actual no hay vínculo directo.
🛒 Te puede servir
¿Y vos qué opinás? Dejalo en los comentarios ⬇️
Cubrí todos los equipos, no solo el tuyo →
