Azorult 3.3 amplia roubo de carteiras e muda comunicação com C&C

A nova variante do ladrão de informações foi observada em distribuição pelo RIG exploit kit, com alterações em ofuscação, geração de diretórios por vítima, carregador e coleta de credenciais de carteiras de criptomoedas.

Componente	Azorult 3.3, malware ladrão de informações e downloader com módulo de carregamento e coleta de credenciais de carteiras de criptomoedas.
Vetor	Distribuição observada pelo RIG exploit kit e por outras origens não detalhadas, com promoção da versão 3.3 em fórum clandestino desde 4 de outubro de 2018.
Impacto	Coleta ampliada de credenciais de carteiras BitcoinGold, electrumG, btcprivate, bitcore e Exodus Eden, além de capacidade corrigida para carregar e executar arquivos .bat.
Prioridade	Revisar telemetria de endpoints para execução associada ao RIG exploit kit, criação anômala de diretórios sob %TEMP%, tráfego de configuração com padrões alterados de C&C e presença de artefatos ligados ao Azorult.
Artefatos	A versão 3.3 passa a gerar o nome do diretório temporário a partir de hash derivado de GUID, nome do produto, usuário e nome do computador, em vez de usar nomes fixos por versão.
Comunicação	A cadeia do domínio de C&C usa novo método de ofuscação e a mensagem de conexão emprega a chave 0x03,0x55,0xae, fazendo o início da requisição conter três bytes nulos após a operação de codificação descrita.

Resumo técnico

Azorult 3.3 representa uma atualização funcional de uma família já conhecida de roubo de informações, com foco em manter valor operacional depois da exposição pública de versões anteriores. A amostra descrita no contexto foi vista em circulação durante a semana anterior à publicação original e chegou a vítimas por meio do RIG exploit kit, além de outras origens que não foram detalhadas. O malware continua combinando duas funções centrais: coleta de dados sensíveis no host comprometido e uso como downloader para introduzir componentes adicionais. A mudança mais relevante não está em uma única técnica isolada, mas no conjunto de ajustes que dificulta a reutilização direta de conhecimento obtido nas versões 3.1 e 3.2.

A versão 3.3 foi anunciada em 4 de outubro de 2018 no fórum clandestino exploit.in pelo usuário CrydBrox, com a numeração atribuída pelos próprios autores. O anúncio indicava suporte adicional para roubo de credenciais de carteiras BitcoinGold, electrumG, btcprivate, bitcore e Exodus Eden. Também havia correção no componente de carregamento, que antes tratava extensões de forma incorreta e falhava ao executar determinados arquivos em lote. Para defesa, o ponto central é que a nova versão altera indicadores internos, reduz a utilidade de assinaturas baseadas apenas em diretórios fixos e muda o formato da comunicação com o servidor de comando e controle.

Fluxo técnico

A cadeia observada começa com a entrega do Azorult 3.3 pelo RIG exploit kit. O contexto não específica a vulnerabilidade explorada pelo kit, a página intermediária, o domínio de redirecionamento ou o payload final em formato reproduzível, portanto esses elementos não devem ser presumidos. O que está confirmado é a presença do Azorult como carga entregue e sua finalidade de roubo de informações e download de componentes. Em ambientes de resposta a incidente, essa distinção é importante: a investigação deve separar a exploração inicial pelo kit da atividade posterior do ladrão, preservando evidências de navegador, processo, arquivo temporário, rede e persistência apenas quando aparecerem na telemetria real.

Depois da execução, o malware cria um novo diretório sob %TEMP% e copia DLLs para esse caminho. Nas versões anteriores citadas, o nome do diretório era estático por versão, como 1M0 na 3.1 e 2fda na 3.2. Na 3.3, esse padrão muda: o nome passa a ser calculado a partir de um identificador derivado do computador da vítima. O cálculo usa elementos como GUID, nome do produto, nome de usuário, nome do computador e uma composição desses valores. Como consequência defensiva, uma regra que procure somente nomes fixos perde cobertura contra a nova amostra; a detecção precisa considerar comportamento de criação, localização, relação com processo pai e sequência de carregamento de bibliotecas.

O componente loader também recebeu alteração específica. Na versão 3.2, a comparação da extensão do arquivo carregado levava a uma escolha errada da API de execução, fazendo com que arquivos .bat fossem tratados como executáveis comuns. Na 3.3, essa comparação foi corrigida para permitir que arquivos em lote sejam iniciados com o mecanismo adequado. O impacto confirmado é uma capacidade de execução mais confiável para conteúdo carregado pelo malware, não uma nova técnica de exploração remota por si só. Para operadores de segurança, isso amplia a atenção sobre eventos em que um processo associado ao Azorult aciona interpretadores ou mecanismos de shell a partir de caminhos temporários.

A comunicação com C&C também foi modificada. A versão 3.2 protegia o domínio por uma combinação de XOR com chave fixa e codificação em base64; a 3.3 passa a usar outro método de ofuscação para a cadeia do domínio. Além disso, cada versão mantém uma chave própria para a mensagem enviada ao C&C. Na 3.3, a chave indicada é 0x03,0x55,0xae, e o prefixo usado na mensagem corresponde à própria chave, o que produz três bytes nulos no início da comunicação após o processamento descrito. A resposta do servidor é estruturada em três partes separadas por marcadores, informação útil para análise de tráfego capturado e engenharia reversa defensiva sem depender de um domínio ativo.

Superfície afetada

A superfície exposta envolve estáções Windows alcançadas pela cadeia de entrega do RIG exploit kit ou por outros mecanismos de distribuição não nomeados. O contexto não informa versões específicas de Windows, navegadores ou plugins explorados pelo kit, então a avaliação deve se concentrar em hosts que apresentem evidências de execução do Azorult ou de artefatos compatíveis com a família. A presença de diretórios criados sob %TEMP%, DLLs copiadas para localizações temporárias e atividade de rede para obter configuração são sinais mais sólidos do que tentar inferir a vulnerabilidade inicial sem dados.

O alvo de coleta citado com maior detalhe são credenciais e dados relacionados a carteiras de criptomoedas. A versão 3.3 adiciona suporte a BitcoinGold, electrumG, btcprivate, bitcore e Exodus Eden. Essa ampliação sugere que endpoints usados para operações financeiras pessoais, mineração, exchanges ou custódia local de chaves merecem revisão cuidadosa quando houver suspeita de infecção. O contexto também afirma que o Azorult é um ladrão de informações e downloader, mas não enumera todos os aplicativos de onde os dados são coletados nesta versão; por isso, a apuração não deve acrescentar navegadores, clientes FTP, mensageiros ou outros alvos que não estejam presentes na evidência recebida.

A motivação provável para as mudanças é a exposição de componentes de versões anteriores. O material menciona vazamentos das versões 3.1 e 3.2, incluindo código-fonte de painel e construtores binários disponibilizados publicamente, além de um projeto relacionado chamado Gazorp que permitia gerar binários do Azorult sem custo. Esse cenário cria pressão para que o autor diferencie a nova edição no mercado clandestino e evite que defesas baseadas nos artefatos vazados permaneçam totalmente eficazes. Ainda assim, essa leitura deve ser tratada como inferência técnica a partir das mudanças observadas, não como atribuição formal de intenção a um operador específico.

• Hosts que receberam carga pelo RIG exploit kit e apresentaram execução compatível com Azorult 3.3.
• Diretórios sob %TEMP% com nomes derivados de atributos da máquina, em vez de nomes fixos conhecidos das versões 3.1 e 3.2.
• Ambientes onde existam carteiras BitcoinGold, electrumG, btcprivate, bitcore ou Exodus Eden com credenciais armazenadas localmente.
• Tráfego de saída para C&C com formato de conexão alterado e requisição inicial marcada por três bytes nulos no fluxo processado.

Hunting e telemetria

A investigação deve começar pela correlação entre exploração inicial, criação de arquivos temporários e comunicação de configuração. Em endpoint, procure processos iniciados a partir de locais temporários, cópia de DLLs para subdiretórios recém-criados em %TEMP% e execução subsequente de conteúdo carregado. Como o nome do diretório é calculado a partir de atributos da vítima, a caça por uma string fixa perde precisão. Uma abordagem mais resiliente é observar diretórios de baixa idade, criados por processos sem reputação conhecida, contendo DLLs ou componentes associados a execução imediatamente posterior.

Na rede, a mudança de ofuscação do domínio e do método de conexão exige cuidado com assinaturas antigas. A presença da chave 0x03,0x55,0xae é útil para análise de amostras, mas a detecção operacional deve combinar metadados de processo, destino, temporização e formato de requisição. O fato de a mensagem começar com três bytes nulos após o processamento descrito pode orientar inspeção em tráfego capturado, desde que isso seja usado como pivô analítico e não como único critério de bloqueio. Respostas de C&C divididas em três partes por marcadores também podem ajudar em sandbox, proxy com inspeção autorizada ou análise de PCAP.

Para carteiras de criptomoedas, a defesa deve procurar acessos anômalos aos caminhos de aplicações citadas, leitura de arquivos de credenciais por processos que não pertençam aos respectivos softwares e eventos próximos à execução do Azorult. O contexto não fornece nomes de arquivos específicos para cada carteira, portanto a implementação da consulta precisa usar inventário local e trilhas reais de cada produto instalado. Em ambientes corporativos, a simples presença dessas carteiras em estáções de trabalho pode justificar tratamento diferenciado, pois o malware explicitamente adicionou suporte para capturar esse tipo de credencial.

• Criação recente de subdiretórios em %TEMP% seguida de cópia de DLLs e execução a partir do mesmo caminho.
• Processos associados ao fluxo de infecção iniciando arquivos .bat ou mecanismos de shell sem relação com administração legítima.
• Conexões externas de binários recém-criados para obter configuração de C&C, especialmente quando o tráfego não corresponde ao perfil normal do host.
• Acesso incomum a dados de carteiras BitcoinGold, electrumG, btcprivate, bitcore e Exodus Eden por processos temporários ou desconhecidos.
• Evidências de entrega por RIG exploit kit em histórico de navegador, proxy, endpoint ou sandbox, quando disponíveis.

Mitigação

A resposta deve tratar o Azorult 3.3 como ladrão de informações com capacidade adicional de download. A primeira ação é isolar hosts com execução confirmada ou altamente provável, preservar artefatos temporários e coletar memória, eventos de processo, conexões e arquivos antes de limpeza agressiva. Como o malware pode ter carregado conteúdo adicional, a erradicação não deve terminar na remoção do binário inicial. É necessário identificar processos descendentes, arquivos criados depois da infecção, tarefas ou mecanismos de execução que apareçam na linha do tempo e qualquer comunicação de C&C associada.

Para credenciais, a contenção precisa priorizar carteiras e contas acessadas no host comprometido. O suporte ampliado a carteiras de criptomoedas indica risco direto para segredos locais desses aplicativos, então a rotação ou migração segura de chaves deve ser avaliada conforme a política da organização e a evidência de acesso. Senhas salvas, tokens e outras credenciais que tenham estado disponíveis no endpoint também devem entrar na análise, mesmo que o contexto não liste todos os alvos de coleta. A decisão deve ser guiada por telemetria local, não por suposições sobre módulos não observados.

A prevenção passa por reduzir a superfície que permite a cadeia de entrega, endurecer navegadores e componentes exploráveis, aplicar bloqueios de execução em diretórios temporários quando compatível com o ambiente e monitorar abuso de arquivos em lote. Controles de aplicação podem impedir que binários desconhecidos e scripts sejam iniciados a partir de %TEMP%. No perímetro, bloqueios de reputação e inspeção de comportamento ajudam, mas a alteração do método de ofuscação de domínio mostra que dependência exclusiva de indicadores estáticos envelhece rapidamente. A validação deve incluir testes de detecção com amostras controladas em laboratório ou artefatos sintéticos que representem criação temporária, conexão de configuração e execução de loader, sem reproduzir cadeia ofensiva em produção.

• Isolar máquinas suspeitas e coletar artefatos de processo, arquivo, rede e memória antes da remoção.
• Bloquear ou restringir execução de binários, DLLs e arquivos .bat em diretórios temporários quando a operação permitir.
• Revisar credenciais e carteiras presentes em hosts afetados, com rotação ou migração segura quando houver evidência de acesso.
• Atualizar detecções para comportamento de Azorult 3.3, incluindo diretórios por vítima e novo padrão de comunicação com C&C.
• Investigar cargas adicionais baixadas pelo loader e não limitar a resposta ao primeiro executável identificado.