Operadores de malware usam serviços de nuvem para entregar payloads criptografados

Droppers distribuídos por anexos ISO baixam cargas maliciosas de serviços como Google Drive e OneDrive, descriptografam o conteúdo em memória e dificultam análise por arquivo, domínio e hash.

Componente	Droppers de malware que usam serviços de armazenamento em nuvem para hospedar payloads criptografados, com casos envolvendo famílias como Legion Loader, Nanocore, Lokibot, Remcos e Pony Stealer.
Vetor	Campanhas de spam entregam anexos ISO contendo executáveis que atuam como stubs; após execução pelo usuário, o código baixa a carga criptografada de uma URL fixa em serviço de nuvem e a executa no host.
Impacto	A carga final pode existir apenas em memória no endpoint, enquanto a infraestrutura aparenta tráfego legítimo para nuvem, reduzindo a utilidade de detecção baseada somente em hash, arquivo gravado em disco ou reputação simples de domínio.
Prioridade	Priorizar inspeção comportamental de droppers, análise em sandbox com captura completa da sessão, telemetria de execução em memória, bloqueio de anexos ISO suspeitos e revisão de tráfego incomum para armazenamento em nuvem.
Artefatos	Foram observados cerca de 8.000 URLs, 10.000 amostras e aproximadamente 800 novas amostras semanais desse tipo de dropper; em 72% das amostras analisadas, o domínio de download era drive.google.com.
Mitigação	Combinar sandboxing, EDR, registro de criação de processos, inspeção de chamadas de rede, controle de anexos e políticas de acesso a serviços de nuvem em vez de depender apenas do bloqueio do provedor de armazenamento.

Resumo técnico

Operadores de malware vêm usando serviços populares de armazenamento em nuvem como etapa de entrega de payloads, deslocando parte da infraestrutura maliciosa para ambientes que normalmente aparecem como legítimos em capturas de tráfego e políticas corporativas. O fluxo observado não depende apenas de hospedar um binário conhecido em um servidor externo. A técnica usa um dropper inicial, normalmente entregue por spam em um anexo ISO, para baixar uma carga criptografada de um serviço como Google Drive ou OneDrive, descriptografar o conteúdo localmente e executar a carga no endpoint. O resultado é uma cadeia em que o arquivo inicialmente analisado não contém a funcionalidade maliciosa completa e o domínio contatado pode parecer compatível com uso empresarial comum de nuvem.

A escala observada indica que a técnica não está restrita a um único operador ou a uma única família de malware. A investigação mencionou cerca de 8.000 URLs e 10.000 amostras associadas a esse padrão, incluindo famílias como Legion Loader, Nanocore, Lokibot, Remcos e Pony Stealer. Também foram observadas aproximadamente 800 novas amostras desse dropper por semana. Esses números apontam para adoção operacional ampla, com um modelo que tenta substituir parte do papel tradicional de packers e crypters: reduzir exposição do payload final, dificultar classificação estática e atrasar a criação de assinaturas confiáveis.

O ponto central da técnica é a separação entre o stub inicial e o payload real. O executável presente no ISO atua como carregador e não precisa conter o malware completo. A carga armazenada na nuvem fica criptografada e, em muitos casos, só é transformada em binário executável dentro da máquina da vítima. Essa escolha pressiona defensores em três frentes: o serviço de nuvem pode não conseguir identificar o conteúdo antes da descriptografia, a solução de segurança local pode ver apenas uma conexão a um provedor legítimo e a análise posterior pode encontrar apenas um dropper residual com link inativo.

Fluxo técnico

A cadeia descrita começa com mensagens de spam que carregam anexos ISO. Dentro do ISO há um executável malicioso que se apresenta como uma aplicação Visual Basic 6 ou imita essa estrutura para complicar a análise inicial. O binário contém poucas funções reconhecidas por desmontadores, mistura instruções sem utilidade com código ofuscado e usa medidas anti-desmontagem. Em vez de expor diretamente a lógica do malware final, ele recupera e executa shellcode embutido em outra região do binário, frequentemente em recursos ou na própria seção de código.

A ofuscação do primeiro estágio também usa XOR rotativo, mas com chave curta e recuperável a partir do próprio conteúdo, funcionando mais como barreira contra análise automatizada do que como proteção criptográfica forte. Depois dessa etapa, o shellcode resolve dinamicamente funções de API, reduzindo a utilidade de inspeção estática de importações. O fluxo inclui a criação de um segundo processo em estado suspenso, alteração do mapeamento da imagem, alocação de memória no processo filho, cópia do shellcode descriptografado e transferência de execução para essa área. O processo original é encerrado após cumprir seu papel de carregador.

O estágio responsável pelo download acessa uma URL fixa para buscar a carga criptografada. Foram observadas chamadas compatíveis com APIs como InternetOpenUrlA e InternetReadFile, além de uma verificação simples de consistência baseada no tamanho esperado do arquivo. Se o tamanho recebido não corresponder ao valor codificado no dropper, o carregador tenta novamente em loop. Esse detalhe é relevante para detecção porque repetições de download do mesmo recurso de nuvem, em sequência e a partir de um processo recém-criado por anexo, podem revelar falha ou persistência da tentativa de entrega.

A carga baixada da nuvem é criptografada com uma chave única, geralmente com centenas de bytes e variação observada entre aproximadamente 200 e 1.000 bytes. A descriptografia acontece no endpoint por XOR rotativo, mas o payload resultante não precisa ser gravado em disco. O carregador extrai informações do cabeçalho PE, carrega manualmente o binário no endereço de imagem apropriado e cria uma thread para executar a carga. Em seguida, esconde a thread usada para execução e finaliza a thread que realizou a descriptografia. Em algumas amostras, há uma segunda URL para baixar uma imagem de distração, gravada no perfil do usuário e aberta com ShellExecuteW, dando ao usuário a impressão de que o anexo exibiu o conteúdo prometido.

A cadeia também inclui recursos anti-debugging. Foram observadas manipulações relacionadas a DbgUiRemoteBreakin e DbgBreakPoint, com o objetivo de prejudicar a anexação de depuradores e interromper pontos de parada em threads ocultas. Essas técnicas não tornam a análise impossível, mas aumentam o custo operacional para pesquisadores e automatismos. Quando combinadas com payload efêmero em memória e links que podem desaparecer após a campanha, elas reduzem a chance de recuperação posterior da carga final.

Superfície afetada

A superfície exposta envolve endpoints capazes de receber e montar anexos ISO, usuários suscetíveis a mensagens de spam com iscas documentais e ambientes que permitem acesso direto a serviços de armazenamento em nuvem sem inspeção contextual. O uso de Google Drive, OneDrive e outros provedores não significa que esses serviços sejam maliciosos; a técnica explora a confiança operacional já concedida a domínios amplamente usados. Em 72% das amostras analisadas, o download da carga ocorreu a partir de drive.google.com, o que reforça a necessidade de distinguir acesso corporativo legítimo de uso anômalo por processos recém-executados.

O risco aumenta em ambientes nos quais o controle de e-mail bloqueia executáveis tradicionais, mas não trata ISO como formato de alto risco, ou onde o endpoint não correlaciona montagem de imagem de disco, criação de processo, conexão de rede e execução em memória. Também há exposição para times que dependem de coleta posterior de artefatos em disco, pois a carga descriptografada pode nunca ser persistida como arquivo. Quando a campanha termina e o objeto criptografado é removido da nuvem, o analista pode ficar apenas com o stub, a chave embutida e uma URL sem conteúdo disponível.

A técnica foi observada principalmente com payloads mantidos em serviços de nuvem, mas também houve pequena quantidade de casos em sites legítimos comprometidos. Nesses cenários, a criptografia da carga adiciona uma camada de opacidade mesmo quando a hospedagem ocorre fora de provedores de nuvem. Para defesa, o fator comum é o comportamento do dropper: execução inicial por anexo, download de blob criptografado, transformação local e execução sem gravação clara do payload final.

• Estáções de trabalho que permitem montagem e execução de anexos ISO recebidos por e-mail.
• Ambientes com acesso irrestrito a serviços de armazenamento em nuvem a partir de processos de usuário.
• Soluções de segurança que dependem prioritariamente de hash, assinatura de arquivo estático ou reputação simples de domínio.
• Fluxos de resposta que não capturam memória, árvore de processos e sessão de rede durante a execução.

Hunting e telemetria

A detecção deve partir da correlação entre e-mail, endpoint e rede. Um anexo ISO recebido por spam, seguido de execução de binário extraído, conexão para armazenamento em nuvem e criação de thread com carga alocada dinamicamente forma um encadeamento de alto valor para investigação. A presença isolada de tráfego para nuvem não deve ser tratada como maliciosa, mas o processo de origem, o tempo entre abertura do anexo e download, o padrão de repetição da requisição e a ausência de interação legítima do usuário com cliente de nuvem ajudam a separar uso corporativo de abuso.

Em endpoint, o hunting deve observar processos que se passam por aplicações antigas ou incomuns, especialmente executáveis com características de Visual Basic 6, baixa quantidade de funções reconhecidas, resolução dinâmica de APIs e comportamento de criação de processo suspenso. A sequência de alocação de memória em processo filho, cópia de conteúdo descriptografado e transferência de execução também é relevante para EDR. Quando houver captura de memória, a análise deve procurar imagens PE carregadas manualmente, threads ocultas e divergência entre módulos mapeados e arquivos existentes no disco.

Na rede, o foco deve estar em downloads de objetos de armazenamento em nuvem iniciados por executáveis recém-extraídos de anexos, por processos temporários ou por binários localizados no perfil do usuário. A verificação repetida do mesmo objeto até atingir um tamanho esperado pode aparecer como múltiplas tentativas de download próximas. Como as cargas podem ser removidas após a campanha, a captura do conteúdo em sandbox ou proxy durante a execução é decisiva para preservar evidência e permitir classificação posterior.

Para análise de malware, é importante registrar a sessão inteira da sandbox, incluindo arquivo inicial, URLs contatadas, conteúdo recebido, memória do processo e comportamento após a descriptografia. Uma análise que execute apenas o stub depois que o objeto de nuvem foi removido pode não recuperar a carga final. A ausência do payload no disco não deve encerrar a investigação; nesse padrão, a memória volátil e a telemetria de processo são os principais locais de evidência.

• Montagem de ISO originado de e-mail seguida de execução de binário interno.
• Processo de usuário acessando drive.google.com, OneDrive ou outro serviço de nuvem logo após abertura de anexo.
• Criação de processo em estado suspenso e execução de código em memória alocada dinamicamente.
• Chamadas relacionadas a download por WinINet e repetição de requisições até atingir tamanho específico.
• Manipulação de funções associadas à anexação de depurador, como DbgUiRemoteBreakin e DbgBreakPoint.
• Arquivo de imagem salvo no perfil do usuário e aberto como distração após execução do dropper.

Mitigação

A resposta defensiva deve começar pelo bloqueio ou quarentena de anexos ISO não esperados, especialmente em caixas de correio expostas a spam. Quando o uso legítimo de ISO for necessário, a política deve exigir inspeção em sandbox antes da entrega ao usuário e registrar a origem da mensagem, remetente, assunto, hash do anexo e árvore de processos gerada no endpoint. A mitigação não deve depender exclusivamente do provedor de nuvem remover o arquivo, porque a carga pode estar criptografada e o abuso pode ser identificado somente após investigação manual.

No endpoint, EDR e antimalware devem ser configurados para alertar sobre execução de binários extraídos de imagens montadas, criação de processos suspensos, carregamento manual de PE, alocação de memória executável e execução de threads não associadas a módulos esperados. A análise comportamental em sandbox deve capturar tráfego, arquivos temporários e memória durante a execução completa, incluindo o momento de download e descriptografia da carga. Quando uma amostra for identificada, a contenção deve preservar memória antes de reinicializações sempre que viável, porque o payload final pode desaparecer com o encerramento do processo.

Na rede e em nuvem, a defesa deve aplicar controle contextual ao acesso a armazenamento público. Não se trata de bloquear genericamente serviços como Google Drive ou OneDrive, mas de exigir visibilidade sobre processo de origem, usuário, destino, volume, método de download e reputação do objeto quando disponível. Gateways seguros, proxies corporativos e CASB podem contribuir com política de acesso, mas precisam ser alimentados por telemetria de endpoint para diferenciar navegador corporativo, cliente sincronizador autorizado e executável recém-baixado por e-mail.

Após confirmação de atividade, a organização deve isolar o host, coletar memória e logs, identificar contas afetadas, revisar mensagens semelhantes no ambiente e procurar a mesma cadeia em outros endpoints. Como famílias citadas nesse padrão incluem ladrões de credenciais e ferramentas de acesso remoto, a resposta deve incluir revisão de credenciais expostas no host, sessões ativas e autenticações anômalas posteriores. A rotação de credenciais deve ser baseada em evidência de execução e perfil do usuário afetado, com prioridade para contas usadas no endpoint comprometido.

• Bloquear ou submeter a sandbox anexos ISO recebidos por e-mail antes da entrega ao usuário.
• Alertar sobre execução de binários a partir de imagens montadas e diretórios de perfil do usuário.
• Correlacionar tráfego para serviços de nuvem com processo de origem, linha de comando resumida, usuário e horário de abertura de anexo.
• Preservar memória e árvore de processos quando houver suspeita de payload executado sem gravação em disco.
• Revisar caixas de correio, endpoints e autenticações associadas ao usuário afetado após confirmação de execução.
• Ajustar regras de proxy, EDR e sandbox para capturar objetos criptografados e comportamento pós-descriptografia, não apenas hashes conhecidos.