GuLoader amplia entrega de malware com shellcode hospedado em serviços de nuvem

A cadeia usa VBScript, PowerShell ofuscado e payloads criptografados em servidores remotos para reduzir detecção, carregar código em memória e dificultar análise estática e depuração.

Componente	GuLoader, loader baseado em shellcode usado para baixar, descriptografar e executar payloads maliciosos em memória.
Vetor	Amostras em VBScript ou instaladores NSIS acionam PowerShell ofuscado, recuperam shellcode ou payload criptografado de serviço remoto, frequentemente Google Drive, e transferem execução para código em memória.
Impacto	Execução de payload malicioso sem gravar o conteúdo descriptografado no disco, com evasão de antivírus, anti-debugging, evasão de sandbox e obstáculos relevantes para análise estática e dinâmica.
Prioridade	Correlacionar execução anômala de VBScript, PowerShell de 32 bits, download de dados de nuvem, alocação de memória executável e carregamento em memória; bloquear a cadeia por política de script, controle de acesso a serviços de nuvem e resposta em endpoint.
Artefatos	A variante VBS descrita contém código inútil e comentários pseudoaleatórios; uma cadeia observada salvou dados em %APPDATA%\Umig.For antes da decodificação em BASE64.
Técnicas	A shellcode usa VEH, exceções deliberadas por int3, violação de acesso 0xC0000005, single-step 0x80000004 por Trap Flag em EFLAGS e breakpoint 0x80000003 para quebrar o fluxo normal de execução.

Resumo técnico

GuLoader é um loader de malware orientado à evasão que evoluiu de aplicações VB6 com shellcode embutido para cadeias baseadas em VBScript e instaladores NSIS. O objetivo operacional continua sendo carregar um payload protegido, descriptografá-lo e executá-lo em memória, evitando que o conteúdo final descriptografado seja gravado no disco. Essa escolha reduz a exposição de artefatos estáticos para mecanismos tradicionais de varredura e desloca a detecção para comportamento, telemetria de script, uso de memória, chamadas de API e sequência de processos.

A mudança mais importante descrita é a separação entre o script inicial e a shellcode criptografada. Na variante VBS mais recente, o arquivo inicial carrega apenas um pequeno PowerShell ofuscado junto de grande volume de código inútil, comentários pseudoaleatórios e instruções sem função operacional. A shellcode criptografada passa a ficar hospedada em serviço remoto, geralmente Google Drive. Mesmo com esforços de bloqueio contra payloads maliciosos criptografados, a cadeia observada ainda usava esse tipo de armazenamento em nuvem como ponto de entrega.

O modelo cria um problema prático para defesa e análise: a amostra inicial pode ter baixa taxa de detecção no envio inicial a mecanismos de reputação, enquanto o conteúdo realmente relevante só aparece depois que a cadeia recupera dados externos. Em uma amostra citada, o arquivo não teve detecções no momento do envio ao VirusTotal em 3 de março de 2023 e, dois dias depois, 17 de 59 mecanismos o classificavam como malicioso. Na mesma análise, os endereços de download da shellcode de GuLoader e do payload Remcos permaneciam ativos semanas após o envio, indicando que a infraestrutura de entrega podia se manter disponível por tempo suficiente para infectar sistemas sem bloqueio imediato.

Fluxo técnico

Na cadeia VBS, o script inicial chama o interpretador PowerShell e passa como parâmetro um conteúdo montado em uma variável ofuscada. Uma rotina interna reconstrói comandos a partir de caracteres selecionados em intervalos fixos, técnica simples que esconde strings e operadores de execução de uma leitura superficial. O resultado é outro script PowerShell, ainda ofuscado, que contém a URL para o serviço de nuvem e rotinas de decodificação. Em sistemas de 64 bits, a execução é direcionada para PowerShell a partir de SysWOW64, porque a shellcode de GuLoader precisa rodar dentro de um processo de 32 bits.

Depois de recuperar dados do link remoto, a cadeia salva temporariamente o conteúdo em %APPDATA%\Umig.For e aplica decodificação BASE64. Os primeiros 654 bytes do bloco decodificado são colocados em uma região de memória separada e contêm uma shellcode ofuscada usada como descriptografador. O restante do conteúdo vai para outra região de memória e corresponde ao corpo principal da shellcode ainda criptografado. A transferência de controle ocorre por meio de callback com CallWindowsProc, recebendo também referências relacionadas ao endereço da shellcode criptografada e à função NtProtectVirtualMemory. Esse fluxo mostra que a cadeia não depende apenas de arquivo no disco: ela organiza regiões de memória, altera permissões e executa código carregado dinamicamente.

A variante NSIS difere no empacotamento. Em vez de depender da recuperação externa da shellcode para todo o comportamento, amostras NSIS carregam a shellcode GuLoader criptografada dentro do próprio instalador. Isso permite observar comportamento em sandbox mesmo sem conectividade com a Internet e facilita parte da análise estática do script NSIS e do bloco criptografado. A consequência defensiva é que as duas famílias de empacotamento deixam sinais diferentes: VBS tende a destacar abuso de script e nuvem, enquanto NSIS expõe artefatos do instalador e shellcode embutido.

A shellcode compartilhada pelas variantes contém múltiplas barreiras de análise. O mecanismo mais relevante é a interrupção proposital do fluxo normal de execução usando exceções tratadas por um manipulador vetorial, ou VEH. Em vez de seguir saltos diretos fáceis de reconstruir, o código provoca exceções e deixa o VEH calcular dinamicamente o próximo endereço válido. A técnica foi ampliada com padrões diferentes: instruções int3, acessos inválidos de memória que geram 0xC0000005 e manipulação do Trap Flag em EFLAGS, que gera exceção single-step 0x80000004 quando não há depurador anexado. Com depurador presente, o fluxo observado muda e pode levar o analista para caminho incorreto.

Superfície afetada

A superfície de exposição concentra-se em estáções Windows capazes de executar VBScript, PowerShell e instaladores NSIS recebidos por canais externos. O contexto não descreve o vetor inicial de entrega, como e-mail, link ou download, portanto a análise defensiva deve se limitar ao que é confirmado: execução de scripts, uso de PowerShell, acesso a armazenamento em nuvem, criação de arquivo temporário em perfil de usuário e execução de shellcode em processo de 32 bits. O risco é maior em ambientes onde scripts de usuário são permitidos sem restrição, onde PowerShell legado ou de 32 bits não é monitorado e onde tráfego para serviços de armazenamento é tratado como confiável por padrão.

O uso de Google Drive e outros serviços de hospedagem cria uma zona cinzenta para controles de rede. Bloqueios amplos podem ser inviáveis em empresas que dependem desses serviços, mas permitir qualquer download sem inspeção também dá ao loader um canal de distribuição com reputação aparente. A defesa precisa diferenciar uso legítimo de padrões incomuns: scripts recém-criados chamando PowerShell, processos de usuário acessando URLs de compartilhamento, sequência de download seguida de decodificação e alocação de memória executável, e ausência de documento ou aplicação corporativa justificando o fluxo.

O payload final observado no exemplo citado foi Remcos, mas o papel principal de GuLoader é entregar cargas maliciosas, não limitar a campanha a uma única família. Assim, a superfície afetada deve ser tratada como genérica para carregamento de malware em memória. O impacto confirmado é execução furtiva de payload, evasão de análise e dificuldade de detecção estática; qualquer conclusão adicional sobre roubo de dados, persistência ou movimentação lateral depende da carga final recuperada e não deve ser presumida apenas pela presença do loader.

• Estáções Windows com execução de VBScript e PowerShell permitida para usuários comuns.
• Ambientes que permitem tráfego de usuários para serviços de armazenamento em nuvem sem inspeção contextual.
• Endpoints onde PowerShell de 32 bits em SysWOW64 não é monitorado ou é tratado como equivalente a atividade administrativa comum.
• Sandboxes e pipelines de análise que dependem apenas de comportamento com conectividade limitada podem observar diferenças entre variantes VBS e NSIS.

Hunting e telemetria

A detecção deve combinar processo, script, rede e memória. No endpoint, procure execuções em que wscript.exe ou cscript.exe iniciem PowerShell com argumentos ofuscados, strings longas montadas dinamicamente ou padrões de execução indireta. Em sistemas de 64 bits, a chamada a PowerShell a partir de SysWOW64 por um script de usuário merece atenção especial, porque o fluxo descrito depende de processo de 32 bits para executar a shellcode. O arquivo temporário %APPDATA%\Umig.For é um artefato concreto da cadeia analisada, mas não deve ser usado como único indicador, pois nomes e caminhos podem variar.

Na camada de rede, o sinal útil não é apenas a presença de Google Drive, e sim a combinação temporal entre processo de script, requisição a serviço de nuvem e atividade posterior de decodificação ou execução em memória. Proxies, EDR e logs de DNS devem ser correlacionados com criação de processo e escrita em diretórios de perfil de usuário. Como a cadeia busca conteúdo criptografado, a inspeção de conteúdo pode ter baixa utilidade isolada; padrões de origem, destino, volume, sequência e relação com processo chamador tornam-se mais importantes.

Para análise de malware, as exceções deliberadas são sinais valiosos quando a plataforma captura eventos de depuração, falhas tratadas ou comportamento anômalo de fluxo. O uso de int3, violação de acesso controlada e manipulação de Trap Flag é projetado para confundir depuradores e desmontadores. Em ambiente de laboratório, a reconstrução de fluxo exige observar o VEH e os endereços calculados dinamicamente, evitando concluir que os bytes após a exceção representam execução linear real. Em produção, esse nível de detalhe raramente aparece em logs convencionais, mas EDRs podem expor alocação de memória com mudança de permissão, execução de shellcode e chamadas compatíveis com injeção ou execução indireta.

• Processo de script iniciando PowerShell com parâmetros extensos, ofuscados ou montados por concatenação.
• PowerShell de 32 bits chamado em Windows de 64 bits, especialmente a partir de wscript.exe, cscript.exe ou instaladores incomuns.
• Download de dados de serviços de nuvem imediatamente antes de escrita em %APPDATA% e decodificação em memória.
• Alocação de regiões de memória, alteração de proteção por API e transferência de controle por callback como CallWindowsProc.
• Exceções repetidas e tratadas internamente, incluindo padrões compatíveis com 0xC0000005, 0x80000004 e 0x80000003.

Mitigação

A mitigação deve priorizar redução da execução inicial e visibilidade. Restringir VBScript para usuários que não dependem dele, aplicar política de execução e registro detalhado de PowerShell, registrar linha de comando de processo e habilitar telemetria de script são medidas diretamente alinhadas ao fluxo observado. Em estáções corporativas, PowerShell de 32 bits deve receber o mesmo nível de controle aplicado ao PowerShell principal, porque a cadeia usa essa arquitetura como requisito para a shellcode. Bloqueios por hash isolado têm utilidade limitada, já que o loader usa ofuscação, conteúdo remoto e variantes de empacotamento.

No controle de nuvem, a resposta mais eficiente é contextual. Serviços como Google Drive não devem ser classificados automaticamente como seguros quando acessados por interpretadores de script ou processos sem relação com navegador corporativo. Políticas de CASB, proxy ou firewall podem aplicar inspeção por categoria de processo, identidade, origem e destino. Quando o bloqueio não for possível, registre requisições de scripts para URLs de compartilhamento, preserve metadados e correlacione com eventos de endpoint para confirmar se houve download seguido de execução em memória.

Em incidentes confirmados, a contenção deve isolar o endpoint, coletar árvore de processos, scripts originais, artefatos temporários, histórico de downloads, eventos de PowerShell, conexões de rede e telemetria de memória disponível no EDR. A erradicação não deve parar no arquivo VBS ou NSIS: é necessário identificar a carga final, porque GuLoader é o mecanismo de entrega. Se Remcos ou outro payload tiver sido executado, a investigação deve seguir as capacidades específicas dessa carga, sem presumir impacto antes da confirmação. Após a limpeza, valide políticas de script, regras de detecção, cobertura de PowerShell de 32 bits e bloqueio contextual de downloads por processos de automação.

• Aplicar restrição de VBScript e revisar exceções existentes para execução de scripts por usuários comuns.
• Habilitar logs de PowerShell, linha de comando de processo e correlação entre script, rede e criação de arquivo em perfil de usuário.
• Tratar PowerShell em SysWOW64 como superfície monitorada e sujeita às mesmas políticas de controle.
• Configurar alerta para interpretadores de script acessando armazenamento em nuvem e gravando dados em diretórios de usuário.
• Em resposta a incidente, identificar o payload final antes de declarar impacto como roubo de dados, persistência ou movimentação lateral.