A análise mostra que o protetor comercial CloudEyE gera binários quase idênticos a amostras GuLoader observadas em ataques, com criptografia de carga, uso de serviços em nuvem e randomização para dificultar detecção.
| Componente | CloudEyE, antigo DarkEyE Protector e amostras detectadas como GuLoader em binários Windows compilados em Visual Basic. |
| Vetor | Geração de dropper com carga criptografada e URL de download apontando para serviços de armazenamento em nuvem, incluindo Google Drive e OneDrive. |
| Impacto | Entrega de diferentes famílias de malware, incluindo FormBook em uma amostra comparada, além de suporte histórico a stealers, keyloggers e RATs em materiais associados ao DarkEyE. |
| Prioridade | Tratar detecções de GuLoader como cadeia de entrega de malware, bloquear abuso de armazenamento em nuvem, revisar endpoints Windows e correlacionar telemetria de download, execução e descriptografia em memória. |
| Artefatos | Shellcode criptografado com chave XOR de 4 bytes, URLs criptografadas, estrutura de variáveis globais com offsets equivalentes e randomização de trechos de código. |
| Infraestrutura | Site público securitycode[.]eu associado à oferta do CloudEyE e tutoriais que demonstravam uso de drives em nuvem para hospedagem de cargas. |
CloudEyE foi associado a uma cadeia de geração de malware que produz amostras classificadas como GuLoader, um dropper amplamente distribuído em 2020. O ponto técnico central é que binários produzidos pelo CloudEyE apresentaram a mesma arquitetura de amostras GuLoader vistas em campanhas reais: código em Visual Basic, shellcode criptografado com uma chave XOR de 4 bytes, rotina equivalente de descriptografia da carga e mecanismos de randomização destinados a dificultar análise automatizada. A semelhança não ficou restrita ao formato externo do arquivo. A comparação manual indicou que trechos úteis do código eram essencialmente os mesmos, com diferenças explicadas principalmente por randomização aplicada durante a geração do binário.
A cadeia observada usa armazenamento em nuvem como parte do fluxo de entrega. GuLoader já vinha sendo usado para baixar malware por meio de serviços como Google Drive, e o CloudEyE continha materiais demonstrando o uso de Google Drive e OneDrive para hospedar cargas protegidas. Essa característica é relevante para defesas porque o tráfego para provedores legítimos de nuvem pode passar por controles menos restritivos, enquanto a criptografia da carga reduz a chance de bloqueio durante upload, armazenamento e inspeção inicial. O resultado é um dropper que combina reputação de infraestrutura legítima, proteção de payload, evasão de sandbox e variação de código para aumentar a persistência operacional de campanhas distintas.
O fluxo começa com a preparação de um executável Windows protegido pelo CloudEyE. O construtor permite selecionar um arquivo a ser protegido, gerar uma versão criptografada e indicar uma URL de onde a carga será baixada. Em testes descritos no contexto, a ferramenta foi usada para proteger um executável benigno e configurar um endereço de download em servidor HTTP local. A amostra resultante recebeu veredicto compatível com GuLoader e, quando comparada a uma amostra real usada para entregar FormBook, revelou estrutura praticamente equivalente. Esse detalhe indica que a classificação GuLoader não decorre apenas de heurística superficial; a lógica interna, a criptografia, a preparação da pilha e o tratamento das URLs seguem o mesmo padrão.
A implementação contém shellcode precedido por um stub aleatório e por um salto que contorna esse trecho inicial. Essa técnica cria variações entre amostras sem mudar a lógica funcional que interessa ao operador. Em seguida, o código reserva espaço para uma estrutura de variáveis globais, com offsets equivalentes entre a amostra produzida pelo CloudEyE e a amostra GuLoader observada em campanha. As URLs usadas para baixar a carga e arquivos associados ficam criptografadas e são recuperadas com a mesma chave usada na descriptografia do payload. Para a defesa, isso significa que a ausência de uma URL clara no binário estático não reduz a severidade do alerta; os endereços podem surgir apenas após emulação, depuração controlada ou coleta de memória durante execução.
O histórico do DarkEyE Protector reforça a continuidade operacional. Materiais antigos apresentavam o produto como crypter voltado a tornar malware menos detectável por antivírus e citavam uso com stealers, keyloggers e RATs. CloudEyE aparece como evolução pública dessa linha, embalado como software de proteção de aplicações Windows contra cracking, debug, desmontagem e dumping. A fronteira defensiva importante é separar o argumento comercial da capacidade técnica observada: as amostras relacionadas não apenas protegem propriedade intelectual, mas também protegem cargas maliciosas, facilitam entrega por nuvem e incorporam recursos típicos de evasão e empacotamento usados em campanhas de malware.
A superfície exposta inclui endpoints Windows que recebem anexos, links ou downloads capazes de iniciar um dropper GuLoader, além de ambientes corporativos que permitem acesso irrestrito a serviços de armazenamento em nuvem. Como a cadeia pode usar provedores legítimos, controles baseados apenas em reputação de domínio tendem a ter menor eficiência. A inspeção precisa considerar o comportamento do processo local, a criação de memória executável, a descriptografia de conteúdo, a resolução dinâmica de URLs e a execução posterior de uma carga adicional. O risco aumenta quando usuários conseguem baixar executáveis de origem externa e quando proxies, EDRs e gateways não correlacionam tráfego de nuvem com eventos de execução no endpoint.
O volume relatado também altera a prioridade operacional. A atividade envolvia centenas de ataques diários e chegou a representar até um quarto das amostras empacotadas observadas no período analisado. Isso sugere uso por múltiplas campanhas, não por um único operador isolado. A presença de temas ligados à pandemia, como nomes relacionados a coronavírus, mostra o uso de engenharia social para induzir execução pelo usuário. Mesmo quando a carga final muda, o dropper, a proteção e o padrão de entrega fornecem pontos comuns para detecção e resposta.
- Estáções Windows com execução de anexos ou downloads externos são a superfície primária de risco.
- Ambientes que permitem Google Drive, OneDrive e serviços similares sem inspeção contextual ficam mais expostos ao abuso de hospedagem de carga.
- Amostras GuLoader devem ser tratadas como estágio de entrega, não como evento isolado, porque a carga final pode variar por campanha.
- Materiais associados ao DarkEyE indicam uso histórico para proteger stealers, keyloggers e RATs contra detecção.
A caça deve começar pela correlação entre execução local e tráfego para armazenamento em nuvem. Um processo recém-criado que inicia conexão com provedores de arquivos, baixa conteúdo criptografado ou binário e em seguida gera atividade em memória deve receber prioridade. Como URLs podem estar criptografadas no arquivo inicial, a análise estática simples pode não revelar todos os indicadores. Equipes de DFIR devem privilegiar telemetria de processo, árvore de execução, módulos carregados, alocação de memória com permissão executável, criação de novos arquivos e conexões de rede feitas logo após a abertura do binário suspeito.
No endpoint, amostras compatíveis com GuLoader podem exibir características de empacotamento e evasão, incluindo variação de código entre arquivos que mantêm a mesma lógica funcional. A presença de Visual Basic, shellcode criptografado por XOR de 4 bytes e rotinas de descriptografia de URL e payload são sinais técnicos fortes para análise reversa. Em sandbox, divergências de comportamento podem aparecer por causa de técnicas de evasão, então a ausência de execução completa em um ambiente automatizado não deve encerrar a triagem. A resposta deve combinar análise dinâmica, extração controlada de strings em memória e revisão de downloads subsequentes.
- Processos Windows iniciando conexões para serviços de nuvem logo após execução de arquivo recebido por e-mail, web ou mensageria.
- Binários Visual Basic com shellcode criptografado, stub aleatório inicial e rotina de descriptografia por XOR curta.
- URLs ou marcadores de URL recuperados apenas em tempo de execução, especialmente quando relacionados a download de payload ou arquivo isca.
- Detecções de GuLoader acompanhadas por tentativa posterior de executar FormBook ou outras famílias de malware.
- Uso de nomes temáticos de campanhas, incluindo referências a coronavírus, para induzir abertura de arquivos.
A mitigação deve tratar o evento como uma cadeia de entrega completa. O primeiro passo é isolar endpoints com detecção GuLoader ou comportamento equivalente, preservar artefatos de memória quando possível e identificar a carga final baixada. Em seguida, é necessário revisar tráfego para serviços de armazenamento em nuvem no intervalo da execução, bloquear URLs e objetos associados quando identificados e verificar se houve criação de persistência pela carga entregue. Como o dropper pode servir diferentes famílias, a contenção não deve terminar na remoção do primeiro executável; a investigação precisa confirmar se houve payload secundário, coleta de credenciais, keylogging, comunicação de comando e controle ou instalação de RAT.
No nível preventivo, organizações devem aplicar controles de execução para arquivos baixados da internet, restringir macros e anexos executáveis, reforçar inspeção de downloads de nuvem e correlacionar eventos de proxy com EDR. Bloqueios genéricos de Google Drive ou OneDrive podem ser inviáveis em muitos ambientes, portanto a abordagem mais eficaz é combinar política de acesso, análise de conteúdo, detecção comportamental e resposta rápida a execuções anômalas. Equipes de segurança também devem manter regras de detecção voltadas ao padrão do dropper, não apenas a hashes, porque a randomização de código reduz a durabilidade de indicadores estáticos.
- Isolar hosts com alerta GuLoader e coletar árvore de processos, conexões, artefatos baixados e memória quando viável.
- Revisar tráfego para Google Drive, OneDrive e outros serviços de nuvem no período imediatamente anterior e posterior à execução suspeita.
- Bloquear amostras e objetos associados por hash interno quando disponíveis, mas priorizar detecções comportamentais resistentes à randomização.
- Validar se a carga final foi executada e investigar sinais de stealer, keylogger, RAT ou FormBook conforme a telemetria indicar.
- Reforçar políticas de execução para arquivos baixados, anexos suspeitos e binários sem procedência confiável.
0 Comentários