SynkLoader: el malware que llega por Microsoft Teams

En pocas palabras: Detectado por Expel el 18 de agosto de 2026, SynkLoader es un malware multi-etapa que llega vía phishing en Microsoft Teams suplantando soporte IT. Tres módulos —loader Python, PhishLocker y TrafficRedirector— roban credenciales de Windows con pantalla de bloqueo falsa y usan la PC como proxy hacia la red interna.

Expel detectó el 18 de agosto de 2026 SynkLoader, un malware que llega por Microsoft Teams haciéndose pasar por el soporte IT de la empresa, roba contraseñas de Windows con una pantalla de bloqueo falsa y usa la máquina de la víctima como proxy para meterse en la red interna.

SynkLoader es un loader malicioso multi-etapa descubierto por la firma de ciberseguridad Expel durante una respuesta a incidente en el entorno de un cliente. Se propaga mediante mensajes de phishing en Microsoft Teams enviados desde tenants externos de Microsoft 365 y despliega tres módulos: el loader principal escrito en Python, PhishLocker (robo de credenciales con pantalla de bloqueo falsa) y TrafficRedirector (reverse proxy con control interactivo vía VNC y PowerShell).

¿Qué es SynkLoader y cuáles son sus componentes?

SynkLoader es el nombre que Expel le dio a una familia de malware modular compuesta por tres piezas que trabajan en cadena: un loader principal, un capturador de credenciales llamado PhishLocker y un proxy inverso llamado TrafficRedirector. Cada módulo cumple una función específica y llega de forma selectiva desde varios servidores C2, según el análisis técnico publicado en dev.to.

Módulo	Función	Cómo opera
SynkLoader	Loader principal	Se instala en LocalAppData, persiste con una tarea programada y ejecuta PowerShell y Python en memoria
PhishLocker	Robo de credenciales	Muestra una pantalla de bloqueo de Windows falsa a pantalla completa y envía la contraseña al C2
TrafficRedirector	Acceso remoto	Convierte el equipo en reverse proxy y habilita control interactivo con shells de PowerShell y VNC

Lo llamativo es el diseño modular. Los atacantes no tiran todo de una: entregan piezas según lo que necesitan en cada etapa, lo que complica la detección porque cada componente aislado parece actividad genérica.

¿Cómo funciona la campaña de phishing de SynkLoader en Microsoft Teams?

Ponele que estás trabajando y te suena un mensaje de Teams: alguien del “Service Desk de IT” te avisa que detectaron un problema en tu equipo y te pide ejecutar una “herramienta de reparación” de PowerShell. Suena creíble. Y acá viene lo bueno: el mensaje no llega por mail, llega por Teams, desde un tenant externo de Microsoft 365.

La jugada tiene varios ingredientes que la hacen efectiva, según el equipo de Threat Research de Expel. Primero, Teams es un canal de trabajo donde la gente espera mensajes de colegas y de soporte, así que el filtro de desconfianza baja solo. Segundo, el enlace apunta a Azure Blob Storage, infraestructura legítima de Microsoft con certificado válido, que no dispara ninguna alerta en el navegador. Tercero, el archivo se llama PowershellCleaner, un nombre que suena a utilidad corporativa aburrida, exactamente el tipo de cosa que nadie cuestiona.

¿Y alguien verificó con el área de IT real antes de hacer clic? Casi nunca (spoiler: por eso la campaña existe). La recomendación de Expel es clara: si alguien que dice ser soporte te pide correr algo por chat, confirmá por un canal interno separado y confiable. Te puede servir nuestra comparativa completa entre Microsoft y GitHub.

¿Cuáles son las fases del ataque, desde el MSI hasta el reverse proxy?

La cadena completa tiene cinco etapas, y cada una depende de que la anterior tenga éxito. Si la víctima nunca ejecuta el MSI, todo muere ahí. Pero si lo corre, el resto es automático.

Fijate la secuencia completa: descargás el MSI desde filereserve.blob.core.windows.net, lo ejecutás porque “soporte” te lo pidió, el instalador suelta archivos en LocalAppData, un script de PowerShell ofuscado levanta un loader escrito en Python, ese loader crea una tarea programada con un nombre aleatorio de 12 caracteres usando COM, la tarea arranca al iniciar sesión y todos los días a las 10:00 de la mañana, y a partir de ahí tu máquina trabaja para otro.

• Fase 1, entrega: la víctima recibe el enlace al MSI en Teams y lo descarga desde el bucket de Azure Blob.
• Fase 2, instalación: el instalador copia componentes a LocalAppData, carpeta de usuario donde un administrador rara vez mira.
• Fase 3, persistencia: se crea una tarea programada vía COM con nombre aleatorio de 12 caracteres, configurada para correr al inicio de sesión y diariamente a las 10:00.
• Fase 4, carga: PowerShell ofuscado ejecuta el loader de Python en memoria, sin dejar archivos evidentes en disco.
• Fase 5, operación: el malware contacta varios servidores C2 con intervalos de 90 a 120 segundos de jitter y recibe módulos según convenga.

Expel mapeó la cadena a seis técnicas de MITRE ATT&CK: T1566.002 (enlace de spearphishing), T1218.007 (ejecución vía Msiexec), T1053.005 (tarea programada), T1056.002 (captura de entrada por GUI), T1090.001 (proxy interno) y T1021 (servicios remotos). Si tenés EDR, esas seis son reglas de detección de cabecera.

¿Cómo funciona PhishLocker y por qué entrega la contraseña sin resistencia?

PhishLocker es el módulo de captura de credenciales, y su truco es de una simpleza brillante: dibuja una pantalla de bloqueo de Windows falsa a pantalla completa, idéntica a la original. El usuario, que acaba de instalar una herramienta de “reparación”, ve que la máquina se bloquea y hace lo único que sabe hacer: escribir su contraseña para desbloquear (sí, en serio). Esa contraseña viaja directo al servidor C2 de los atacantes.

¿Por qué funciona tan bien? Porque nadie desconfía de la pantalla de bloqueo de Windows. Es el elemento más familiar de toda la interfaz, y al estar a pantalla completa tapa la barra de tareas, el navegador y cualquier indicio de que algo raro pasa. Ni siquiera necesita privilegios de administrador: corre desde el contexto del usuario, con archivos en LocalAppData y una tarea programada de usuario, así que los controles de elevación nunca saltan. Para que el robo cierre el círculo, la víctima tiene que ingresar una contraseña válida del sistema operativo, condición que el propio informe de Expel marca como requisito de éxito.

¿Qué es TrafficRedirector y cómo convierte tu PC en puerta de entrada a la red?

TrafficRedirector es la cereza del postre para el atacante: convierte el equipo comprometido en un reverse proxy que conecta la red interna de la empresa con los servidores externos del intruso. Desde afuera se abren shells de PowerShell y sesiones VNC interactivas, y todo el tráfico sale con la IP de la víctima, una dirección que los sistemas internos ya tienen en su lista de permitidas. En el ataque al supply chain con malware Miasma profundizamos sobre esto.

Acá se rompe un supuesto viejo del perímetro: que una IP interna conocida equivale a un dispositivo confiable. El atacante navega hacia Active Directory, bases de datos y servidores de archivos como si estuviera sentado en el escritorio de la víctima, y los controles geográficos o de anomalía de IP no ven nada extraño porque, técnicamente, no lo hay: la conexión sale del lugar correcto con credenciales válidas robadas por PhishLocker. El equipo infectado queda funcionando como punto de relevo entre la LAN interna y los servicios externos autorizados.

¿El objetivo final? Expel encontró indicios de alcance sobre Active Directory en su entorno virtualizado, lo que sugiere dos caminos probables: desplegar ransomware o vender el acceso inicial a otro grupo. Ojo, eso es hipótesis, no hecho confirmado.

¿Cómo detectar SynkLoader en tu equipo o red de empresa?

Los indicadores más claros combinan tres planos: la tarea programada rara, el origen de la descarga y el patrón de comunicaciones. Ninguno por separado es definitivo, pero juntos pintan la foto completa.

• Tareas programadas sospechosas: nombres aleatorios de 12 caracteres creadas vía COM o RPC, corriendo al logon y a las 10:00, sin binario asociado evidente.
• Descargas desde Azure Blob: archivos MSI en el historial del navegador provenientes de dominios terminados en blob.core.windows.net que no correspondan a tu organización.
• Comunicación con C2: conexiones periódicas a múltiples servidores externos con espaciado de 90 a 120 segundos, típico del jitter que usa el malware para evadir detección.
• Ejecución en memoria: PowerShell ofuscado y procesos de Python lanzados desde rutas de usuario, sin instalador visible.
• Acceso remoto anómalo: sesiones VNC o shells remotas iniciadas desde el equipo hacia servicios internos en horarios inusuales.

Un detalle clave del caso: Expel recomienda auditar los registros de Teams, no solo los de correo. Esta campaña vive en Teams, y muchos SOC siguen mirando el mail como única fuente de phishing. Si ya sospechás de un incidente, preservá la conversación, el tenant emisor y el URL del Blob antes de borrar nada.

Para graduar la respuesta, el playbook propone cinco niveles: intento observado (contacto o URL recibido), acción del usuario confirmada (descarga o ejecución del MSI), ejecución inicial confirmada (loader y tarea programada), autenticación o C2 confirmados, y compromiso posterior con VNC o movimiento lateral. Un dato honesto: el reporte analizado no publica hashes del MSI, así que trabajá con estos indicadores de comportamiento y dominios. Sobre eso hablamos en el rendimiento del Xeon 678X en ambos sistemas.

¿Cómo defenderse contra SynkLoader y mitigar el riesgo?

Las contramedidas prioritarias atacan cada eslabón de la cadena. Ninguna sola basta, pero combinadas cierran casi todos los caminos.

• Restringí Teams externo: limitá la colaboración con tenants externos desde el centro de administración o exigí aprobación explícita; si tu negocio no lo necesita, bloquealo.
• Bloqueá MSI de internet: impedí la ejecución de instaladores MSI descargados de la web y las descargas desde buckets de Azure Blob desconocidos.
• Frená scripts sin firmar: endurecé las políticas de ejecución de PowerShell y controlá intérpretes de Python que llegan de afuera.
• Vigilá el Programador de tareas: generá alertas sobre creación de tareas vía COM o RPC, especialmente con nombres aleatorios.
• Matá la confianza ciega en IPs: los allowlists que validan solo la dirección de origen quedaron obsoletos; combiná estado del dispositivo, MFA y monitoreo conductual.
• Prepará la respuesta: ante sospecha, cambiá la contraseña del usuario, revocá todas sus sesiones, aislar el equipo, frená las tareas y bloqueá los C2 conocidos.

Y si administrás servidores propios, ya sea en tu oficina o en un VPS de un proveedor como donweb.com, aplicá el mismo criterio: monitoreá conexiones salientes, limitá la ejecución de scripts y mantené el acceso remoto detrás de VPN con MFA.

Resumen para llevar a la reunión del lunes: cerrar Teams externo, bloquear MSI, vigilar tareas COM y dejar de tratar el allowlist de IP como control único.

Qué está confirmado y qué sigue siendo hipótesis

• Confirmado: detección inicial el 18 de agosto de 2026 vía tarea programada en el entorno de un cliente de Expel.
• Confirmado: cadena completa Teams, Azure Blob, MSI, PowerShell, Python y tarea COM con persistencia.
• Confirmado: PhishLocker captura contraseñas con pantalla de bloqueo falsa y TrafficRedirector opera como reverse proxy con VNC.
• Confirmado: comunicación C2 con jitter de 90 a 120 segundos y entrega selectiva de módulos.
• Pendiente: si víctimas reales ingresaron contraseñas en PhishLocker en producción.
• Pendiente: objetivo final (ransomware o venta de acceso inicial), inferido del alcance a Active Directory.
• Pendiente: identidad del grupo detrás y payloads posteriores, sin atribución pública hasta ahora.

Errores comunes frente a campañas como SynkLoader

Seguir confiando en el allowlist de IPs. El razonamiento clásico es “si la conexión sale de nuestro equipo, es segura”. SynkLoader existe justo para romper ese supuesto: el atacante navega con la IP de la víctima y credenciales válidas, así que tu lista de permitidos lo recibe con los brazos abiertos. La corrección es combinar estado del dispositivo, MFA y monitoreo de comportamiento.

Buscar phishing solo en el correo. Muchos SOC siguen tratando el mail como único vector. Esta campaña ni siquiera pasa por ahí: vive en Teams, y Expel recomienda explícitamente auditar esos registros antes que los de email. Si tu monitoreo no incluye conversaciones con tenants externos, tenés un punto ciego enorme.

Asumir que lo de Microsoft es seguro por defecto. El MSI se aloja en Azure Blob Storage, con HTTPS y dominio de Microsoft. Ningún filtro de reputación de dominio va a saltar. La defensa acá es conductual: bloquear tipos de archivo peligrosos vengan de donde vengan. Complementá con nuestra guía para evitar caídas de DNS.

Limpiar el equipo y seguir como si nada. Borrar la tarea programada y reinstalar no alcanza si la contraseña ya viajó al C2. Hay que rotar credenciales, revocar sesiones y revisar autenticaciones originadas desde esa IP, porque el atacante pudo entrar a otros servicios con la misma clave.

Preguntas Frecuentes

¿Qué es SynkLoader y cómo funciona este malware?

SynkLoader es un malware multi-etapa descubierto por Expel el 18 de agosto de 2026 que se distribuye mediante phishing en Microsoft Teams. Después de que la víctima ejecuta un MSI falso llamado PowershellCleaner, instala módulos en Python que roban la contraseña de Windows con una pantalla de bloqueo falsa y convierten el equipo en un reverse proxy para operar dentro de la red.

¿Cómo detecto si mi equipo tiene SynkLoader?

Buscá tres señales: tareas programadas con nombres aleatorios de 12 caracteres creadas vía COM, descargas de MSI desde dominios blob.core.windows.net y conexiones periódicas a servidores C2 con intervalos de 90 a 120 segundos. Fue justamente una tarea programada anómala la que disparó la detección en el EDR del cliente de Expel.

¿Qué hago si ya ejecuté el MSI de SynkLoader?

Cambiá la contraseña de Windows del usuario, revocá todas sus sesiones activas, aislar el equipo de la red, eliminá la tarea programada y bloqueá la comunicación con los C2 conocidos. Después cruzá las autenticaciones internas y externas originadas desde la IP de esa máquina para verificar si hubo movimiento lateral.

¿Quién está detrás de SynkLoader y cuál es su objetivo?

Todavía no hay atribución pública a ningún grupo. Expel confirmó las técnicas y la infraestructura, pero el objetivo final, posiblemente ransomware o venta de acceso inicial a otra banda, figura como hipótesis basada en el alcance detectado sobre Active Directory.

¿Es seguro seguir usando Microsoft Teams después de este ataque?

Sí. El problema no es Teams sino permitir que cualquier tenant externo escriba a tus usuarios: restringiendo esa colaboración, verificando pedidos de soporte por un canal interno confiable y bloqueando MSI de internet, la plataforma sigue siendo segura para trabajar.

Conclusión

SynkLoader confirma una tendencia incómoda: los atacantes dejaron el correo y se mudaron a donde ya confiamos. Teams, Azure Blob, una pantalla de bloqueo que imita a Windows: todo el señuelo está construido sobre infraestructura y elementos visuales que damos por seguros.

Para las empresas de Latinoamérica el mensaje es directo. Revisá hoy mismo quién puede contactarte desde tenants externos en Teams, bloqueá la ejecución de MSI bajados de internet y empezá a tratar los allowlists de IP como lo que son: un control insuficiente. Y para el equipo: si “soporte IT” te pide correr algo por chat, verificá por otro canal antes de tocar un clic. Cuesta diez segundos y puede ahorrarte un incidente de semanas.

Fuentes

• Expel Threat Research – investigaciones del equipo que detectó SynkLoader
• Análisis técnico de SynkLoader en dev.to – cadena de ataque, IOCs y playbook de investigación
• MITRE ATT&CK T1566.002 – técnica de phishing con enlace usada en esta campaña
• Microsoft Learn – documentación del Programador de tareas y su API COM