TASK#STOMP: backdoor en Windows usa VBScript y PowerShell para exfiltrar documentos y credenciales

Investigadores de seguridad han detallado una campaña nueva, identificada como TASK#STOMP, que usa VBScript y PowerShell para instalar un backdoor que recopila y exfiltra documentos empresariales, credenciales y otros datos sensibles desde equipos Windows. Según el informe técnico compartido por los investigadores de Securonix y difundido por medios especializados, la operación combina varias técnicas de persistencia y ejecución “living‑off‑the‑land” (uso de herramientas nativas de Windows) para dificultar la detección y la investigación forense.

Hechos confirmados: los análisis de muestra documentan un archivo VBScript ejecutado por wscript.exe (un ejemplo nombrado en el reporte como "95c9050t66.vbs") que crea tareas programadas con nombres diseñados para parecer procesos legítimos (por ejemplo, Local Credential Manager, Network Audio Service) y además coloca un segundo script en la carpeta de Inicio ("msdiag.vbs") como método de respaldo. Ese VBScript lanza dos módulos PowerShell ocultos: uno denominado sys_loader.ps1 que decodifica un archivo "diag_pack.dat" y arranca la funcionalidad de robo de documentos, capturas de pantalla, contraseñas Wi‑Fi y contenido del portapapeles; y otro, win_conn.ps1, que decodifica "win_conn_cfg.dat" y establece un canal de comando y control (C2) persistente. Ambos módulos se comunican con la misma infraestructura C2 (dominios reportados: corecloudfileshare[.]xyz y attachmentsharingdrive[.]xyz) y se vigilan mutuamente de forma que, si uno falla, el otro lo reinicia. También se observó uso de técnicas de timestomping, ejecución oculta y pasos para limpiar pruebas, además de una acción final que abre Google Chrome hacia un sitio de licitaciones iraní (irantenders[.]com) y lanza un archivo batch ("purge.bat") cuyo contenido no se recuperó.

Información estimada o sin confirmar: el vector inicial exacto de acceso no está establecido públicamente; los investigadores señalan que podría haber sido phishing por correo o ingeniería social, pero esa parte permanece pendiente de confirmación. La intención detrás de abrir el sitio de licitaciones iraní no se conoce y podría obedecer a pruebas de pantalla/obfusación, distracción del usuario o un objetivo específico no documentado. Tampoco se dispone del contenido de "purge.bat", por lo que su función exacta (borrado de huellas, eliminación de artefactos locales, etc.) es especulativa.

Técnicamente, TASK#STOMP explota la flexibilidad administrativa de Windows: wscript.exe para ejecutar VBScript, Task Scheduler para persistencia con nombres que simulan servicios válidos, la carpeta de Inicio como método de respaldo y PowerShell para desplegar capacidades avanzadas de recolección y control. El uso de archivos DAT codificados que se decodifican y ejecutan en memoria, la posible compilación dinámica vía .NET/C#, y la separación funcional en procesos distintos (uno enfocado en recolección y el otro en comunicaciones) otorgan redundancia y resistencia: matar un proceso no elimina la otra rama y el mecanismo de watchdog mutuo facilita la recuperación automática de componentes interrumpidos.

¿A quién afecta? Principalmente equipos Windows que permitan la ejecución de scripts VBS/PowerShell sin restricciones, especialmente en entornos donde el usuario tiene privilegios suficientes, o donde no existe un control de ejecución de scripts ni visibilidad de tráfico saliente. Organizaciones con políticas débiles sobre macros y scripts, ausencia de EDR o sin técnicas de monitorización (PowerShell logging, Sysmon, registro de tareas programadas) están en mayor riesgo. Dado que la campaña emplea dominios públicos para C2 y técnicas que mezclan actividad maliciosa con acciones administrativas legítimas, también es probable que pase desapercibida en redes con supervisión limitada.

Consecuencias prácticas: la presencia de este backdoor permite exfiltrar documentos corporativos y metadatos, capturar credenciales locales y contraseñas Wi‑Fi almacenadas, robar el contenido del portapapeles (riesgo para contraseñas copiadas), tomar capturas de pantalla y recibir/ejecutar comandos arbitrarios desde el actor remoto. Esto abre la puerta a compromiso continuo, espionaje corporativo, movimiento lateral y uso del endpoint para pivotar dentro de la red. Además, las técnicas de evasión (timestomping, limpieza, nombres engañosos) aumentan la complejidad de la respuesta y la recuperación forense.

Qué debe hacer el lector ahora (medidas concretas e inmediatas): 1) Detectar indicadores y artefactos: revise tareas programadas sospechosas con Get‑ScheduledTask o el Visor de tareas, compruebe entradas en la carpeta de Inicio del usuario, busque archivos y scripts indicados (nombres informados como 95c9050t66.vbs, msdiag.vbs, sys_loader.ps1, win_conn.ps1, diag_pack.dat, win_conn_cfg.dat, purge.bat) y registos de ejecución de wscript.exe o procesos PowerShell ocultos. Verifique conexiones salientes hacia los dominios reportados y cualquier resolución DNS o tráfico HTTP/S hacia esos nombres. 2) Contener y recopilar evidencias: si detecta compromiso, aísle el equipo de la red, preserve memoria y volcado de disco para análisis (no formatee), y recabe logs de PowerShell, Sysmon y eventos de Seguridad/Aplicación. 3) Remediar: elimine las tareas maliciosas y los archivos de persistencia, cambie credenciales locales y de servicio potencialmente comprometidas (incluyendo contraseñas Wi‑Fi), fuerce restablecimiento de sesiones autenticadas y aplique MFA donde proceda. 4) Fortalecer prevención: deshabilite Windows Script Host si no es necesario (ver guía de Microsoft), limite la ejecución de PowerShell mediante políticas de restricción de ejecución, active el Script Block Logging y Module Logging de PowerShell, y adopte bloqueo de aplicaciones (AppLocker/Windows Defender Application Control). Bloquee o monitorice con prioridad los dominios y direcciones IP asociados en cortafuegos y sistemas proxy.

Para defensores y admins: implemente reglas de detección orientadas a las TTP observadas (ejecución de wscript desde rutas de usuario, creación de tareas programadas con nombres que imitan servicios, procesos PowerShell que ejecutan decodificación en memoria, comunicaciones con dominios no habituales). Use telemetría avanzada (Sysmon, EDR) para correlacionar creación de procesos, creación de ficheros .dat decodificados y sesiones de red persistentes. Consulte referencias técnicas sobre técnicas de persistencia y living‑off‑the‑land en el marco MITRE ATT&CK para ajustar detección: https://attack.mitre.org/techniques/T1218/ y https://attack.mitre.org/techniques/T1053/.

Recursos y lecturas recomendadas: para comprender y mitigar riesgos relacionados con PowerShell y scripts en Windows, la documentación oficial de Microsoft sobre PowerShell y medidas de seguridad es un buen punto de partida: https://learn.microsoft.com/powershell/. El análisis de Securonix y la cobertura periodística amplían detalles del caso y pueden consultarse para IOCs y observables específicos; medios especializados como The Hacker News han publicado resúmenes: https://thehackernews.com/.

Limitaciones y próximos pasos: mientras los artefactos analizados y los dominios de C2 son hechos reportados, persisten incógnitas sobre el vector inicial, el alcance real (si hay campañas relacionadas) y la motivación detrás de elementos como la apertura del sitio de licitaciones iraní. Organizaciones que identifiquen actividad similar deberían compartir indicadores con sus CSIRT y proveedores de inteligencia para colaborar en la identificación de más muestras y en la contención a nivel sectorial.

En resumen, TASK#STOMP no introduce una técnica radicalmente nueva, pero es un recordatorio operativo: los atacantes siguen aprovechando componentes nativos de Windows y combinando redundancia y vigilancia mutua entre módulos para mantener acceso persistente. La defensa efectiva requiere visibilidad en los endpoints, control de ejecución de scripts, rotación de credenciales y una respuesta preparada para preservar evidencia y cortar canales de exfiltración.