Hack Alerta

DesckVB RAT: novo RAT modular executa payloads em memória

DesckVB RAT v2.9 combina um stager WSH ofuscado, um estágio PowerShell com checagens anti‑análise e um loader .NET que executa em memória. Sua arquitetura plugin‑based permite entrega dinâmica de keylogger, webcam e módulos AV‑enumerator. Recomendações: restringir wscript.exe, habilitar logging do PowerShell e usar EDR com telemetria de execução em memória.

Pesquisadores descrevem uma nova variante do DesckVB RAT (v2.9) que combina um stager em WSH com um carregador .NET fileless e um ecossistema de plugins — tornando a detecção e a resposta mais complexas.

Resumo técnico

O DesckVB RAT 2.9 é um backdoor modular observado em campanhas ativas no início de 2026. O ataque se inicia com um arquivo JavaScript altamente ofuscado executado via Windows Script Host (wscript.exe). Esse stager copia artefatos para diretórios públicos e invoca um estágio PowerShell que realiza checagens anti‑análise antes de buscar o componente principal.

Arquitetura e vetores de persistência

O RAT usa um loader .NET que carrega o código diretamente em memória (reflective loading), evitando deixar um executável persistente no disco. A arquitetura plugin‑based permite que operadores entreguem módulos sob demanda: os analistas validaram plugins para keylogging, streaming de webcam (DirectShow) e enumeração de soluções AV instaladas.

Mecanismo de entrega

O vetor inicial reportado é um arquivo WSH ofuscado que chama o engine wscript para executar código em contexto de usuário. Em seguida, o PowerShell de segundo estágio executa validações (conectividade, presença de ferramentas de debugging/sandbox) antes de baixar os módulos finais por um protocolo TCP customizado com delimitadores proprietários.

Implicações para detecção e resposta

  • Fileless reflective loading reduz artefatos em disco; as capturas tradicionais por hash têm utilidade limitada.
  • Uso do wscript.exe e de PowerShell com construções específicas (arrays decimais de bytes) são indicadores comportamentais críticos.
  • O modelo de plugins permite reaproveitamento operacional sem necessidade de nova infecção completa — aumento do risco de movimentos laterais e espionagem prolongada.

Mitigações recomendadas

Equipes de segurança devem priorizar:

  • Aplicar políticas de restrição para wscript.exe e bloquear execução de scripts de locais não confiáveis.
  • Habilitar registro detalhado de PowerShell (Module Logging e Script Block Logging) e monitorar padrões de construção de arrays/decodificação inusitada.
  • EDR com telemetria de execução em memória e detecção de reflective loading; detecção de conexões anômalas no protocolo TCP customizado.
  • Segmentação de rede e princípio do menor privilégio para reduzir impacto de agentes remotos.

O que falta nas análises públicas

Os relatórios descrevem a cadeia de infecção e plugins validados, mas não quantificam o alcance (número de hosts comprometidos) nem os vetores de distribuição primários (e‑mail, malvertising, drive‑by). Essas métricas são necessárias para priorizar bloqueios em larga escala.

Observação operacional

Para times de SOC: priorizar regras de detecção comportamental em vez de IOC estáticos; focar em execução anômala via wscript/PowerShell e no comportamento de reflective loading.

Baseado em publicação original de Cyber Security News
Publicado pela Redação Hack Alerta com base em fontes externas citadas e monitoramento editorial do Hack Alerta. Para decisões técnicas, operacionais ou jurídicas, confirme sempre os detalhes na fonte original.