TASK#STOMP: backdoor no Windows usa VBScript e PowerShell para exfiltrar documentos e credenciais

Pesquisadores de segurança têm detalhado uma campanha nova, identificada como TASK#STOMP, que usa o VBScript e o PowerShell para instalar um backdoor que recolhe e exfiltra documentos empresariais, credenciais e outros dados sensíveis do Windows. De acordo com o relatório técnico partilhado pelos investigadores de Securonix e divulgado por meios especializados, a operação combina várias técnicas de persistência e execução “living-off-the-land” (uso de ferramentas nativas do Windows) para dificultar a detecção e investigação forense.

Atos confirmados: as análises de amostra documentam um arquivo VBScript executado por wscript.exe (um exemplo designado no relatório como "95c9050t66.vbs") que cria tarefas programadas com nomes desenhados para parecer processos legítimos (por exemplo, Local Credential Manager, Network Audio Service) e também coloca um segundo programa na pasta de Início ("msdiag.vbs") como método de apoio. Esse VBScript lança dois módulos PowerShell escondidos: um denominado sys_loader.ps1 que descodificar um ficheiro "diag_pack.dat" e arranca a funcionalidade de roubo de documentos, capturas de ecrã, senhas Wi-Fi e conteúdo da área de transferência; e outro, win_ conn.ps1, que descodificar "win_ conn_cfg.dat" e estabelece um canal de comando e controlo (C2) persistente. Ambos os módulos comunicam-se com a mesma infraestrutura C2 (domínios reportados: corecloudfileshare[.]xyz e attachmentsharingdrive[.]xyz) e monitoram-se mutuamente de forma que, se uma falha, o outro o reinicia. Também foi observado uso de técnicas de timestomping, execução oculta e passos para limpar testes, além de uma ação final que abre o Google Chrome para um site de concursos iranianos (irantenders[.]com) e lança um arquivo batch ("purge.bat") cujo conteúdo não foi recuperado.

Informações estimadas ou sem confirmar: o vetor inicial exato de acesso não está estabelecido publicamente; os pesquisadores apontam que poderia ter sido phishing por correio ou engenharia social, mas essa parte permanece pendente de confirmação. A intenção por trás de abrir o site de concursos iranianos não é conhecida e pode obedecer a testes de tela/obfusação, distração do usuário ou um objetivo específico não documentado. Também não se dispõe do conteúdo de "purge.bat", pelo que sua função exata (borrado de pegadas, eliminação de artefatos locais, etc.) é especulativa.

Tecnicamente, a TASK#STOMP explora a flexibilidade administrativa do Windows: wscript.exe para executar o VBScript, Task Scheduler para persistência com nomes que simulam serviços válidos, a pasta de Início como método de backup e o PowerShell para implantar capacidades avançadas de coleta e controle. O uso de arquivos DAT codificados que são descodificados e executados em memória, a possível compilação dinâmica via .NET/C#, e a separação funcional em processos distintos (um focado em coleta e outro em comunicações) outorgam redundância e resistência: matar um processo não elimina o outro ramo e o mecanismo de watchdog mútuo facilita a recuperação automática de componentes interrompidos.

Quem afeta? Principalmente equipamentos Windows que permitam a execução de scripts VBS/PowerShell sem restrições, especialmente em ambientes onde o usuário tem privilégios suficientes, ou onde não existe controle de execução de scripts ou visibilidade de tráfego saliente. Organizações com políticas fracas sobre macros e scripts, ausência de EDR ou sem técnicas de monitoramento (PowerShell logging, Sysmon, registro de tarefas programadas) estão em maior risco. Dado que a campanha emprega domínios públicos para C2 e técnicas que misturam atividade maliciosa com ações administrativas legítimas, também é provável que passe despercebida em redes com supervisão limitada.

Consequências práticas: a presença deste backdoor permite exfiltrar documentos corporativos e metadados, capturar credenciais locais e senhas Wi-Fi armazenadas, roubar o conteúdo da área de transferência (risco para senhas copiadas), tirar capturas de tela e receber/executar comandos arbitrários do ator remoto. Isso abre a porta para comprometimento contínuo, espionagem corporativa, movimento lateral e uso do endpoint para pivotar dentro da rede. Além disso, as técnicas de evasão (timestomping, limpeza, nomes enganosos) aumentam a complexidade da resposta e recuperação forense.

O que o leitor deve fazer agora (medidas concretas e imediatas): 1) Detectar indicadores e artefatos: rever tarefas programadas suspeitas com Get‐ScheduledTask ou o Visualizador de Tarefas, verifique itens na pasta inicial do utilizador, procure ficheiros e programas indicados (nomes informados como 95c9050t66.vbs, msdiag.vbs, sys_loader.ps1, win_ conn.ps1, diag_pack.dat, win_ conn_cfg.dat, purge.bat) e registos de execução do wscript.exe ou processos PowerShell escondidos. Verifique as ligações enviadas para os domínios relatados e qualquer resolução DNS ou tráfego HTTP/S para esses nomes. 2) Parar e recolher evidências: se detectar compromisso, isole a equipe da rede, preserve memória e voltado de disco para análise (não formatee), e recabeça logs de PowerShell, Sysmon e eventos de Segurança/Aplicação. 3) Remediar: remova tarefas maliciosas e arquivos de persistência, mude credenciais locais e de serviço potencialmente comprometidas (incluindo senhas Wi-Fi), foirce restabelecimento de sessões autenticadas e aplique MFA onde for caso disso. 4) Fortalecer a prevenção: deshabilite Windows Script Host se não for necessário (ver guia da Microsoft), limite a execução de PowerShell através de políticas de restrição de execução, active o Script Block Logging e Module Logging de PowerShell, e adopte bloqueio de aplicativos (AppLocker/Windows Defender Application Control). Bloqueie ou monitorize com prioridade os domínios e endereços IP associados em corta-fogos e sistemas proxy.

Para defensores e admins: implemente regras de detecção orientadas para as TTP observadas (execução de wscript desde rotas de usuário, criação de tarefas programadas com nomes que imitam serviços, processos PowerShell que executam descodificação em memória, comunicações com domínios não habituais). Use telemetria avançada (Sysmon, EDR) para correlacionar a criação de processos, criação de arquivos .dat descodificados e sessões de rede persistentes. Consulte referências técnicas sobre técnicas de persistência e living‐off‐the‐land no âmbito MITRE ATT&CK para ajustar detecção: https://attack.mitre.org/techniques/T1218/ e https://attack.mitre.org/techniques/T1053/.

Recursos e leituras recomendadas: para compreender e mitigar riscos relacionados com PowerShell e scripts no Windows, a documentação oficial da Microsoft sobre PowerShell e medidas de segurança é um bom ponto de partida: https://learn.microsoft.com/powershell/. A análise de Securonix e a cobertura jornalística ampliam detalhes do caso e podem ser consultados para IOCs e observáveis específicos; meios especializados como The Hacker News publicaram resumos: https://thehackernews.com/.

Limitações e próximos passos: enquanto os artefatos analisados e os domínios de C2 são feitos reportados, persistem incógnitas sobre o vetor inicial, o alcance real (se houver campanhas relacionadas) e a motivação por trás de elementos como a abertura do sítio de concursos iranianos. Organizações que identifiquem atividade similar deveriam compartilhar indicadores com seus CSIRT e provedores de inteligência para colaborar na identificação de mais amostras e na contenção a nível sectorial.

Em resumo, a TASK#STOMP não introduz uma técnica radicalmente nova, mas é um lembrete operacional: os atacantes continuam aproveitando componentes nativos do Windows e combinando redundância e vigilância mútua entre módulos para manter acesso persistente. A defesa efetiva requer visibilidade nos endpoints, controle de execução de scripts, rotação de credenciais e uma resposta preparada para preservar evidências e cortar canais de exfiltração.