WezRat usa phishing com falso alerta de atualização do Chrome contra organizações israelenses

Backdoor em C++ registra máquinas infectadas em servidor de comando e controle, carrega módulos sob demanda e coleta tela, teclado, área de transferência e arquivos.

Componente	Família de malware WezRat, incluindo o backdoor Updater.exe e módulos DLL auxiliares para captura de tela, keylogging, área de transferência, upload de arquivos e persistência.
Vetor	E-mails de phishing enviados em 21 de outubro de 2024, com remetente fraudulento alert at il-cert[.]net, link para domínio semelhante il-cert[.]net e download automático de Google Chrome Installer.msi.
Impacto	Execução de backdoor em Windows com registro da máquina no C2, recebimento de comandos, coleta de informações do usuário e uso de módulos para captura de tela, teclas, conteúdo da área de transferência e envio de arquivos.
Prioridade	Bloquear e investigar artefatos associados ao instalador MSI, ao processo Updater.exe, à chave Run Chrome Updater, ao mutex {FA531CC1-0497-11D3-A180-00105A276C3E} e às conexões para connect[.]il-cert[.]net na porta 8765.
Artefatos	Payload citado como Updater.exe; amostra não ofuscada analisada com MD5 6b0d7b2e422a93e81ceed3645d36dd40, também chamada internamente de bd.exe.
Infraestrutura	Campanha usa il-cert[.]net como domínio semelhante ao site legítimo e executa o backdoor com os argumentos connect[.]il-cert[.]net 8765.

Resumo técnico

A campanha distribuiu o WezRat por meio de mensagens que simulavam um alerta do órgão nacional de segurança cibernética de Israel e induziam a instalação de uma suposta atualização do Chrome. O fluxo observado começa no e-mail, passa por um domínio visualmente semelhante ao domínio legítimo, baixa um arquivo MSI chamado Google Chrome Installer.msi e redireciona a vítima para o site real para reduzir suspeitas. O instalador contém arquivos legítimos associados ao Chrome, mas também grava e executa o backdoor Updater.exe, o que transforma uma interação aparentemente administrativa em execução de código controlado pelo operador da campanha.

O WezRat é um backdoor escrito em C++ e usado por mais de um ano, com mudanças relevantes na arquitetura do cliente e do servidor. A versão mais recente descrita no contexto deixou de depender apenas de endereços C2 embutidos e passou a receber parâmetros de execução, incluindo o servidor connect[.]il-cert[.]net e o número 8765, usado como valor esperado para alcançar a rotina correta de conexão e processamento de comandos. Essa lógica cria uma dependência operacional: se o número incorreto for fornecido, o cálculo de deslocamento aponta para uma função errada ou leva a falha de execução, o que pode dificultar análises superficiais e execuções fora da cadeia pretendida.

A atividade é associada ao grupo iraniano Emennet Pasargad, que também operou sob o nome Aria Sepehr Ayandehsazan, ou ASA, e é descrito no contexto como afiliado ao IRGC. As operações relacionadas impactaram países como Estados Unidos, França, Israel e Suécia. Nesta campanha específica, o foco operacional mencionado são organizações israelenses, com uma isca que aproveita a confiança em comunicações de segurança e em atualizações de navegador. O valor defensivo principal está em reconstruir a cadeia de execução completa, desde a mensagem recebida até a persistência em registro, porque cada etapa deixa sinais diferentes em e-mail, proxy, endpoint e telemetria de Windows.

Fluxo técnico

Após a execução do MSI, o instalador inicia C:\Program Files (x86)\Google\Update\Updater.exe com os argumentos connect[.]il-cert[.]net 8765. O mesmo comando é gravado para persistência em uma chave Run chamada Chrome Updater, permitindo nova execução no logon do usuário. O backdoor interpreta os argumentos, calcula um deslocamento para a função responsável pela conexão com o C2 e subtrai o valor esperado 8765 antes de somar o valor recebido como senha. Na prática, o parâmetro numérico funciona como condição para que a rotina de comunicação seja alcançada de forma correta, pois um valor divergente muda o destino da execução.

Quando a rotina de C2 é alcançada, o malware importa DLLs necessárias, resolve APIs para enumeração do sistema e rede, e cria o mutex {FA531CC1-0497-11D3-A180-00105A276C3E} para limitar instâncias simultâneas. Em seguida, combina IP, nome do computador e nome do usuário para gerar o identificador do bot. A versão atual usa FNV-1a de 64 bits, mas aproveita somente os 32 bits inferiores, junta o resultado a oito zeros e armazena o valor no campo chamado md5. Esse nome não corresponde ao algoritmo usado nessa versão, embora versões anteriores tenham usado MD5 real para o mesmo objetivo.

A primeira comunicação envia um JSON com informações da vítima para /wez/Agent/InsMch, endpoint usado para registrar a máquina. O servidor responde com true;, mas o cliente não depende desse retorno para continuar. Depois, o backdoor consulta /sleep/[MD5], multiplica o valor recebido por 1000 e usa o resultado como intervalo entre requisições; nos casos descritos, o ciclo observado foi de 60 segundos. Para buscar tarefas, a amostra envia POST para /Read/[MD5] com o corpo q=[MD5]. As respostas contêm comandos cifrados por uma rotina simples: cada caractere é convertido para valor decimal ASCII, reduzido por 10 e formatado como número de três dígitos. Algumas strings de comandos preservam artefatos de versões anteriores e usam redução por 14, mas a comparação ocorre na forma cifrada e não impede o fluxo.

O backdoor principal não concentra todas as funções no binário. Para executar comandos específicos, baixa DLLs adicionais do servidor, grava esses módulos em AppData\Local\Temp, carrega-os no processo e chama exports específicos. A versão associada à campanha contém cinco classes funcionais de módulo: captura de tela, keylogging, upload de arquivos, leitura da área de transferência e persistência. Um módulo de captura recebe um diretório de destino, resolve APIs usadas para screenshot e grava uma imagem BMP no caminho resultante. O keylogger inicia pela exportação threadKL, usa APIs como SetWindowsHookExA, CallNextHookEx, GetKeyState e GetAsyncKeyState, e escreve resultados em AppData\Local\Temp\10105060.txt.

Superficie afetada

A superfície exposta é formada por estáções Windows cujos usuários receberam a isca e executaram o MSI. O risco não depende apenas da presença do instalador, porque o pacote também usa arquivos legítimos do Chrome para compor uma aparência plausível. A execução maliciosa fica concentrada no Updater.exe, na chave Run criada pelo instalador e nas conexões HTTP para a infraestrutura informada por argumento. Ambientes que permitem execução de MSI baixado da internet, gravação em caminhos de atualização e criação de chaves Run por usuários comuns têm maior probabilidade de completar a cadeia de infecção.

As versões anteriores do WezRat tinham C2 embutido e não exigiam o argumento numérico de execução. A amostra mais antiga citada foi compilada em 30 de agosto de 2023 e enviada ao VirusTotal em 1 de setembro de 2023 com o nome first.exe. Essa linhagem registrava máquinas pelo endpoint /wez/insert, usava /api/ e /api2/ para comandos e dados, e calculava o identificador do bot com MD5 real. A evolução para FNV-1a, endpoints diferentes e módulos com nomes e exports variáveis mostra uma família em manutenção contínua, o que exige detecção por comportamento e cadeia, não apenas por nomes de arquivo.

• Hosts Windows com execução de Google Chrome Installer.msi recebido por link de e-mail e criação subsequente de Updater.exe.
• Chave Software\Microsoft\Windows\CurrentVersion\Run com entradas Chrome Updater ou Updater, dependendo do estágio de persistência usado.
• Arquivos temporários em AppData\Local\Temp, incluindo DLLs carregadas sob demanda e o arquivo de keylogging 10105060.txt.
• Tráfego de processo com User-Agent firefox para comunicações do backdoor e User-Agent edge no módulo de upload de arquivos.

Hunting e telemetria

A investigação deve começar pela correlação entre e-mail, navegação e endpoint. Em gateways de e-mail, procure mensagens de 21 de outubro de 2024 ou período adjacente com remetente alert at il-cert[.]net, assunto ou corpo relacionados a atualização urgente do Chrome e links que aparentam apontar para il-cert[.]org.il, mas resolvem ou redirecionam para il-cert[.]net. Em proxy, DNS e logs de navegador, priorize acessos ao domínio semelhante, downloads de MSI e redirecionamentos imediatos para o site legítimo, porque esse padrão reduz o tempo em que a vítima permanece na infraestrutura fraudulenta.

No endpoint, o encadeamento de processo é o ponto mais importante. O instalador MSI deve ser relacionado à criação de Updater.exe, à execução com connect[.]il-cert[.]net 8765 e à escrita de chave Run. Também vale caçar a criação do mutex {FA531CC1-0497-11D3-A180-00105A276C3E}, a presença de DLLs não esperadas em AppData\Local\Temp, a criação de arquivos BMP temporários por um processo de atualização e a escrita de 10105060.txt. A sequência de rede do backdoor usa os endpoints /wez/Agent/InsMch, /sleep/[MD5] e /Read/[MD5]; mesmo quando o domínio muda, esse padrão de rotas pode ser usado como indicador comportamental.

A telemetria de rede deve observar requisições periódicas com intervalo controlado pelo C2 e uso de User-Agent firefox em todas as chamadas do backdoor principal. A consulta de comando usa POST com q=[MD5], enquanto o módulo de upload envia arquivos ao servidor em POST com User-Agent edge. O campo chamado md5 no protocolo não deve ser tratado automaticamente como hash MD5, pois na versão atual ele pode conter oito zeros concatenados a um valor derivado de FNV-1a. Essa diferença é relevante para parsers de detecção, enriquecimento e agrupamento de eventos.

• Execução de Updater.exe com os argumentos connect[.]il-cert[.]net 8765.
• Criação de mutex {FA531CC1-0497-11D3-A180-00105A276C3E} em processo associado a atualização do Chrome.
• Requisições para /wez/Agent/InsMch, /sleep/ e /Read/ a partir de endpoint recém-executado.
• Arquivo AppData\Local\Temp\10105060.txt criado por processo não associado a ferramenta legítima de captura de teclado.
• DLLs carregadas de AppData\Local\Temp com exports como scsh, threadKL, up, GetClipboardText, FreeClipboardText ou MainFunc.

Mitigação

A resposta deve isolar máquinas que executaram o MSI ou apresentem o Updater.exe com os argumentos descritos, preservar artefatos de disco e memória quando possível e coletar logs de e-mail, proxy, DNS, EDR e registro antes de limpeza. A remoção manual sem coleta pode eliminar a chave Run e os módulos temporários, mas perder evidência de comandos recebidos, arquivos enviados e atividades de captura. Como o backdoor carrega módulos sob demanda, a ausência de uma DLL específica não prova ausência de funcionalidade; a validação precisa combinar execução observada, tráfego e artefatos temporários.

A contenção deve bloquear il-cert[.]net, connect[.]il-cert[.]net e qualquer infraestrutura identificada internamente durante a investigação, além de impedir execução de instaladores MSI baixados de domínios não confiáveis quando a política do ambiente permitir. Em estáções afetadas, remova as entradas Run Chrome Updater ou Updater somente após coleta, verifique AppData\Local\Temp para módulos e arquivos de saída, e procure sinais de captura de área de transferência, teclas e tela. Senhas digitadas durante a janela de infecção e segredos copiados para a área de transferência devem ser considerados expostos de forma condicionada à execução dos módulos correspondentes.

Para reduzir recorrência, controles de e-mail devem marcar domínios semelhantes a entidades governamentais e validar discrepâncias entre texto visível do link e destino real. Em endpoint, políticas de controle de aplicação devem tratar instaladores assinados ou legítimos como insuficientes quando o pacote também cria binários e persistência fora do fluxo esperado. Detecções devem acompanhar comportamento de atualização falsa de Chrome, criação de Run key, execução com domínio e porta em argumento, criação de mutex específico, módulos carregados de diretórios temporários e beaconing para rotas do protocolo WezRat.

• Bloquear a execução e investigar Google Chrome Installer.msi, Updater.exe e o hash MD5 6b0d7b2e422a93e81ceed3645d36dd40 quando presentes.
• Remover persistência em Software\Microsoft\Windows\CurrentVersion\Run após preservação de evidências.
• Caçar e apagar DLLs e arquivos de saída em AppData\Local\Temp relacionados ao backdoor, incluindo 10105060.txt.
• Revisar credenciais e segredos usados no host durante o período de infecção, com rotação quando houver indício de keylogging, upload ou captura de área de transferência.
• Adicionar regras de detecção para User-Agents firefox e edge quando usados por processos anômalos em chamadas para endpoints do protocolo do malware.