Golpistas enviam trojan Efimer em massa para roubar criptomoedas

Introdução

Em junho, detectamos uma campanha de disparo de e-mail em massa, e as mensagens alegavam ser de advogados de uma grande empresa. Esses e-mails afirmavam falsamente que o nome de domínio do destinatário violava os direitos do remetente. As mensagens continham o script malicioso Efimer, desenvolvido para roubar criptomoedas. Esse script também inclui uma funcionalidade adicional que ajuda os atacantes a disseminá-lo ainda mais com o comprometimento de sites WordPress e com a hospedagem de arquivos maliciosos ali, entre outras técnicas.
Resumo do relatório:

• O Efimer está se espalhando por meio de sites WordPress comprometidos, torrents maliciosos e e-mail.
• Ele se comunica com o servidor de comando e controle por meio da rede Tor.
• O Efimer expande seus recursos por meio de scripts adicionais. Esses scripts permitem que os atacantes usem senhas de força bruta para sites WordPress e coletem endereços de e-mail para futuras campanhas de e-mail maliciosas.

Os produtos da Kaspersky classificam essa ameaça com os seguintes veredictos de detecção:

• HEUR:Trojan-Dropper.Script.Efimer
• HEUR:Trojan-Banker.Script.Efimer
• HEUR:Trojan.Script.Efimer
• HEUR:Trojan-Spy.Script.Efimer.gen

Detalhes técnicos

Histórico

Em junho, detectamos uma campanha de disparo de e-mail em massa que estava distribuindo mensagens idênticas com um arquivo malicioso anexado. O arquivo continha o stealer Efimer, desenvolvido para roubar criptomoedas. Esse malware foi apelidado de “Efimer” porque a palavra apareceu em um comentário no início do script descriptografado. As primeiras versões desse trojan provavelmente surgiram por volta de outubro de 2024, espalhando-se inicialmente por meio de sites WordPress comprometidos. Embora os atacantes continuem usando esse método, eles expandiram sua distribuição em junho para incluir campanhas por e-mail.

Distribuição de e-mail

Os e-mails que os usuários receberam alegavam que advogados de uma grande empresa analisaram o domínio do destinatário e encontraram palavras ou frases em seu nome que infringiam suas marcas registradas. Os e-mails ameaçavam impor uma ação legal, mas ofereciam o cancelamento da ação se o proprietário do domínio alterasse o nome do domínio. Além disso, eles até expressaram vontade de comprar o domínio. O domínio específico nunca foi mencionado no e-mail. Em vez disso, o anexo supostamente continha “detalhes” sobre a suposta violação e o valor da compra proposta.

Em uma tentativa recente de ataque por phishing, os alvos receberam um e-mail com um anexo ZIP chamado “Demand_984175” (MD5: e337c507a4866169a7394d718bc19df9). Dentro dele, os destinatários encontraram um arquivo comprimido protegido por senha e um arquivo vazio chamado “PASSWORD – 47692”. Vale a pena notar a camuflagem ardilosa usada para o arquivo de senha: em vez de um “S” maiúsculo padrão, os atacantes usaram o caractere Unicode U+1D5E6. Essa alteração sutil provavelmente foi implementada para impedir que as ferramentas automatizadas extraíssem facilmente a senha do nome do arquivo.

Caso o usuário descompacte o arquivo comprimido protegido por senha, ele encontrará um arquivo malicioso denominado “Requirement.wsf”. A execução desse arquivo infecta o computador com o trojan Efimer, e provavelmente, surgirá uma mensagem de erro.

Acompanhe como essa cadeia de infecção normalmente se desenrola. Quando o script Requirement.wsf é executado pela primeira vez, ele verifica os privilégios de administrador. Ele faz isso ao tentar criar e gravar dados em um arquivo temporário em C:\\Windows\\System32\\wsf_admin_test.tmp. Caso a gravação seja bem-sucedida, o arquivo será excluído. O que acontece a seguir depende do nível de acesso da dependência do usuário:

• Caso o script seja executado em nome de um usuário privilegiado, ele adicionará a pasta C:\\Users\\Public\\controller nas exclusões de antivírus do Windows Defender. Então, essa pasta será usada para armazenar vários arquivos. Ele também adiciona nas exclusões o caminho completo para o script do WSF, atualmente em execução, e o sistema processa C:\\Windows\\System32\\exe e C:\\Windows\\System32\\cmd.exe. Em seguida, o script salva dois arquivos no caminho mencionado: “controller.js” (que contém o trojan Efimer) e “controller.xml”. Por fim, ele cria uma tarefa do agendador no Windows ao usar a configuração de controller.xml.
• Caso o script seja executado com privilégios de usuário limitados, ele salvará somente o arquivo controller.js no mesmo caminho. Ele adiciona um parâmetro para a inicialização automática do controlador na chave de registro HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\controller. Então, o controlador é iniciado por meio do utilitário WScript.

Posteriormente, o script usa métodos WScript para exibir uma caixa de diálogo de mensagem de erro e, em seguida, ser encerrado. Todas essas etapas foram concebidas para enganar o usuário, que fica esperando que um aplicativo ou documento seja aberto, quando, na verdade, nada de útil acontece.

Trojan Efimer

O script controller.js é um trojan do tipo ClipBanker. Ele foi desenvolvido para substituir os endereços de carteira de criptomoedas, que o usuário copia para a área de transferência, pelos endereços dos próprios atacantes. Além disso, ele também pode executar código externo recebido diretamente do servidor de comando e controle.

O trojan é iniciado com o uso de WMI para verificar se o gerenciador de tarefas está em execução.

Se estiver, o script será encerrado imediatamente para evitar a detecção. No entanto, se o gerenciador de tarefas não estiver em execução, o script prossegue com a instalação de um cliente proxy Tor no computador da vítima. O cliente é usado para estabelecer comunicação com o servidor C2.

O script tem várias URLs hardcoded para baixar o Tor. Isso garante que, mesmo se uma URL estiver bloqueada, o malware ainda poderá recuperar o software Tor de outras. A amostra que analisamos continha as seguintes URLs:

https://inpama[.]com/wp-content/plugins/XZorder/ntdlg.dat

https://www.eskisehirdenakliyat[.]com/wp-content/plugins/XZorder/ntdlg.dat

https://ivarchasv[.]com/wp-content/plugins/XZorder/ntdlg.dat

https://echat365[.]com/wp-content/plugins/XZorder/ntdlg.dat

https://navrangjewels[.]com/wp-content/plugins/XZorder/ntdlg.dat

O arquivo baixado de uma das URLs (A46913AB31875CF8152C96BD25027B4D) é o serviço de proxy Tor. O trojan salva o arquivo em C:\\Users\\Public\\controller\\ntdlg.exe. Se o download falhar, o script será encerrado.

Assumindo que o download tenha sido bem-sucedido, o script inicia o arquivo com a ajuda do WScript e, em seguida, fica inativo por 10 segundos. Essa pausa provavelmente permite que o serviço Tor estabeleça uma conexão com a rede Onion para se inicializar. Em seguida, o script tenta ler um GUID de C:\\Users\\Public\\controller\\GUID. Caso o arquivo não possa ser encontrado, ele gerará um novo GUID via createGUID() para salvá-lo no caminho especificado.

O formato do GUID é sempre vs1a-<4 caracteres hexadecimais aleatórios>, por exemplo, vs1a-1a2b.

Então, o script tenta carregar um arquivo denominado “SEED” de C:\\Users\\Public\\controller\\SEED. Esse arquivo contém frases mnemônicas para carteiras de criptomoedas que o script coletou. Veremos mais detalhes sobre como ele encontra e salva essas frases mais adiante neste post. Caso o arquivo SEED seja encontrado, o script o envia ao servidor e depois o exclui. Essas ações pressupõem que o script pode ter sido encerrado anteriormente de forma incorreta, o que teria impedido que as frases mnemônicas fossem enviadas ao servidor. Em caso de erro, para evitar a perda de dados coletados, o malware salva tudo em um arquivo antes de tentar transmiti-los.

Neste ponto, o controlador conclui o processo de inicialização e entra no ciclo de operação principal.

O loop principal

Em cada ciclo de operação, o controlador verifica a cada 500 milissegundos se o gerenciador de tarefas está em execução. Assim como aconteceu anteriormente, se estiver, o processo será encerrado.

Caso o script não seja encerrado, ele começará a executar ping no servidor C2 por meio da rede Tor. Para fazer isso, o script envia uma solicitação contendo um GUID (identificador global exclusivo) ao servidor. A resposta do servidor será um comando. Para evitar levantar suspeitas com requisições excessivamente frequentes, e manter a comunicação constante, o script usa um cronômetro (a variável p_timer).

Como podemos perceber, a cada 500 milissegundos (meio segundo), imediatamente após verificar se o gerenciador de tarefas está em execução, p_timer diminui em 1. Quando a variável atinge 0 (também é zero na execução inicial), o cronômetro é redefinido com o uso da seguinte fórmula: a variável PING_INT, definida como 1800, é multiplicada por dois e o resultado é armazenado em p_timer. Isso deixa 1800 segundos, ou 30 minutos, até a próxima atualização. Após as atualizações do temporizador, a função PingToOnion é chamada. Ela será discutida a seguir. Muitas cepas de malware semelhantes enviam spam constantemente à rede para atingir o servidor C2 em busca de comandos. O comportamento revela tudo rapidamente. Um cronômetro permite que o script permaneça sob o radar enquanto mantém a conexão com o servidor. Fazer requisições apenas uma vez a cada meia hora torna muito mais difícil identificá-las no fluxo de tráfego geral.

A função PingToOnion funciona juntamente com CheckOnionCMD. Na primeira, o script envia uma requisição POST para o C2 com o uso do utilitário curl que roteia a solicitação por meio de um proxy Tor localizado em localhost:9050 no endereço:

A resposta do servidor é salva no diretório %TEMP% do usuário em %TEMP%\cfile.

Depois que uma solicitação é enviada ao servidor, o CheckOnionCMD é ativado imediatamente. Sua tarefa é procurar uma resposta do servidor em um arquivo denominado “cfile” localizado no diretório %TEMP%. Caso a resposta contenha um comando GUID, o malware não fará nada. Provavelmente, essa é uma resposta PONG do servidor, que confirma que a conexão com o servidor C2 ainda está ativa e funcionando. No entanto, caso a primeira linha da resposta contenha um comando EVAL, isso significa que todas as linhas subsequentes são código JavaScript. Então, esse código será executado usando a função eval.

Independentemente da resposta do servidor, o trojan tem como alvo os dados da área de transferência da vítima. Seu objetivo principal é detectar frases mnemônicas e trocar os endereços de carteira de criptomoeda copiados pelos endereços de carteira dos próprios atacantes.

Primeiramente, ele verifica a área de transferência em busca de strings que se parecem com frases mnemônicas (sementes).

Caso encontre alguma, essas frases serão salvas em um arquivo denominado “SEED” (semelhante ao que o trojan lê na inicialização). Então, esse arquivo é exfiltrado para o servidor com o uso da função PingToOnion descrita acima com o parâmetro de ação SEED. Uma vez enviado, o arquivo SEED é excluído. Em seguida, o script faz cinco capturas de tela (provavelmente para capturar o uso de frases mnemônicas) para enviá-las ao servidor também.
Elas são capturadas com a ajuda do seguinte comando do PowerShell:

A função FileToOnion manipula o envio de arquivos para o servidor. São necessários dois argumentos: o arquivo em si (neste caso, uma captura de tela) e o caminho onde ele precisa ser carregado.

As capturas de tela são enviadas para o seguinte caminho no servidor:

Os arquivos também são enviados por meio de um comando curl:

Depois de enviar o arquivo, o script fica ocioso por 50 segundos. Em seguida, ele começa a substituir os endereços da carteira de criptomoedas. Caso o conteúdo da área de transferência seja apenas números, letras maiúsculas e minúsculas e inclua pelo menos uma letra e um número, o script executa verificações adicionais para determinar se é uma carteira Bitcoin, Ethereum ou Monero. Caso uma carteira correspondente seja encontrada na área de transferência, o script a substituirá de acordo com a seguinte lógica:

• Os endereços curtos da carteira Bitcoin (começando com “1” ou “3” e com 32 a 36 caracteres) são substituídos por uma carteira cujos dois primeiros caracteres correspondem aos do endereço original.
• Para endereços de carteira longos que começam com “bc1q” ou “bc1p” e têm entre 40 e 64 caracteres, o malware encontra um endereço substituto onde o último caractere corresponde ao original.
• Caso um endereço de carteira comece com “0x” e tenha entre 40 e 44 caracteres, o script o substituirá por uma das várias carteiras Ethereum hardcoded no malware. O objetivo, aqui, é garantir que os três primeiros caracteres correspondam ao endereço original.
• Para endereços Monero que começam com “4” ou “8” e têm 95 caracteres, os atacantes usam um endereço único e predefinido. Semelhante a outros tipos de carteira, o script verifica se há caracteres correspondentes entre o endereço original e o trocado. No caso da Monero, apenas o primeiro caractere precisa corresponder. Isso significa que o malware substituirá apenas as carteiras Monero que começam com “4”.

Essa troca na área de transferência normalmente é executada com a ajuda do seguinte comando:

Após cada troca, o script envia os dados ao servidor relativos à carteira original e à substituição.

Distribuição por meio de sites WordPress comprometidos

Como foi mencionado acima, além do e-mail, o trojan se espalha por meio de sites WordPress comprometidos. Os atacantes procuram sites mal protegidos, forçam suas senhas por força bruta e publicam mensagens que oferecem download de filmes lançados recentemente. Essas postagens incluem um link para um arquivo comprimido protegido por senha que contém um arquivo torrent.

O arquivo torrent faz o download de uma pasta para o dispositivo. Essa pasta contém algo que se parece com um filme no formato XMPEG, um arquivo de texto “readme !!!.txt” e um executável que se disfarça como um reprodutor de mídia.

Para assistir a um filme no formato XMPEG, aparentemente, o usuário precisaria iniciar o arquivo xmpeg_player.exe. Porém, o executável é, na verdade, outra versão do instalador do trojan Efimer. Semelhante à variante WSF, esse instalador EXE extrai o componente principal do trojan para a pasta C:\\Users\\Public\\Controller, mas ele é nomeado “ntdlg.js”. Juntamente com o trojan, o instalador também extrai o cliente proxy Tor, nomeado “ntdlg.exe”. O instalador usa o PowerShell para adicionar o script aos programas de inicialização e a pasta “Controlador” nas exclusões do Windows Defender.

O trojan extraído é quase idêntico ao trojan disseminado por e-mail. No entanto, o código desta versão inclui carteiras de spoofing para Tron e Solana, além das carteiras Bitcoin, Ethereum e Monero. Além disso, o GUID para esta versão começa com “vt05”.

Scripts adicionais

Em algumas máquinas comprometidas, descobrimos vários outros scripts intrigantes que se comunicavam com o mesmo domínio .onion, assim como os scripts mencionados anteriormente. Acreditamos que eles foram instalados pelos atacantes por meio de um comando eval para executar payloads de seu servidor C2.

Comprometimento do site WordPress

Entre esses scripts adicionais, encontramos um arquivo denominado “btdlg.js” (MD5: 0f5404aa252f28c61b08390d52b7a054). Esse script foi desenvolvido para forçar senhas por força bruta em sites WordPress.

Depois de executado, ele gera um ID de usuário exclusivo, como fb01-<4 caracteres hexadecimais aleatórios> para salvá-la em C:\\Users\\Public\\Controller\\.

Então, o script inicia vários processos para disparar ataques de força bruta contra páginas da Web. O código responsável por esses ataques é integrado no mesmo script, antes do loop principal. Para acionar essa funcionalidade, o script deve ser executado com o parâmetro “B”. Dentro do loop principal, o script é iniciado ao chamar a função _runBruteProc com o parâmetro “B”.

Após a conclusão de um ataque de força bruta, o script retorna ao loop principal. Aqui, ele continuará a gerar novos processos até atingir um máximo de 20, hardcoded.

Assim, o script é compatível com dois modos: força bruta e o principal, responsável pelo disparo inicial. Caso o script seja iniciado sem nenhum parâmetro, ele entrará imediatamente no loop principal. Depois disso, ele inicia uma nova instância de si mesmo com o parâmetro “B”, dando início a um ataque de força bruta.

O processo de força bruta é iniciado por meio da função GetWikiWords: o script recupera uma lista de palavras da Wikipedia. Então, essa lista é usada para identificar novos sites que receberão o ataque de força bruta. Caso o script não consiga obter a lista de palavras, ele aguardará 30 minutos antes de tentar novamente.

Em seguida, o script entra em seu loop principal de operação. A cada 30 minutos, ele inicia uma solicitação ao servidor C2. Isso é feito com a ajuda do método PingToOnion, que é consistente com os métodos com nomes semelhantes encontrados em outros scripts. Ele envia um comando BUID para transmitir um ID de usuário exclusivo juntamente com as estatísticas de força bruta. Isso inclui o número total de domínios atacados, a contagem de ataques bem-sucedidos e malsucedidos.

Depois disso, o script usa a função GetRandWords para gerar uma lista de palavras aleatórias provenientes da Wikipedia.

Por fim, com o uso dessas palavras aleatórias derivadas da Wikipédia como parâmetros de pesquisa, o script emprega a função getSeDomains para buscar no Google e no Bing domínios a serem alvo de ataques de força bruta.

A função ObjID calcula um hash hexadecimal de oito dígitos que atua como um identificador exclusivo para um objeto especial (obj_id). Nesse caso, o objeto especial é um arquivo que contém informações de força bruta. Isso inclui uma lista de usuários para adivinhação de senha, flags de êxito/falha para tentativas de força bruta e outros dados importantes para o script. Para cada domínio distinto, esses dados são salvos em um arquivo separado. Então, o script verifica se o identificador foi encontrado anteriormente. Todos os identificadores exclusivos são armazenados em um arquivo denominado “UDBXX.dat”. O script procura no arquivo por um novo identificador e, caso não o encontre, ele é adicionado. Esse rastreamento de identificadores ajuda a economizar tempo para evitar o reprocessamento de domínios já conhecidos.

Para cada novo domínio, o script faz uma solicitação com o uso da função WPTryPost. Essa é uma função XML-RPC que tenta criar uma postagem de teste usando um possível nome de usuário e senha. O comando para criar a postagem é o seguinte:

Quando a requisição XML-RPC for respondida, com êxito ou não, a função WPGetUsers é disparada para capturar os usuários do domínio. Essa função atinge o domínio em /wp-json/wp/v2/users para esperar em troca uma lista de usuários do site WordPress.

Essa lista de usuários, juntamente com o domínio e os contadores que rastreiam o número de usuários e senhas com força bruta, são gravados no arquivo de objeto especial descrito acima. O ID desse arquivo é calculado com a ajuda de ObjID. Depois de processar uma página, o script fica inativo por cinco segundos antes de passar para a próxima.

Enquanto isso, vários processos estão sendo executados simultaneamente no computador da vítima, e todos executam operações de força bruta. Conforme mencionado anteriormente, quando o script é iniciado com o argumento “B”, ele entra em um loop infinito de força bruta, com cada processo manipulando seus destinos de forma independente. No início de cada iteração, há uma pausa de 1 a 2 segundos escolhida aleatoriamente. Esse atraso ajuda a escalonar os horários de início das requisições para tornar a detecção da atividade mais difícil. Depois disso, o processo recupera um ID de arquivo de objeto aleatório para o processamento de C:\\Users\\Public\\Controller\\objects ao chamar ObjGetW.

A função ObjGetW captura um objeto de domínio aleatório que não está atualmente vinculado por um processo de força bruta. Os arquivos bloqueados são marcados com a extensão LOCK. Uma vez que um domínio livre e aleatório é selecionado para um ataque de força bruta, a função lockObj é chamada. Isso altera a extensão do arquivo para LOCK para que outros processos não tentem interagir com ele. Caso todos os objetos estejam bloqueados ou caso o objeto escolhido não possa ser bloqueado, o script passará para a próxima iteração do loop e tentará novamente até encontrar um arquivo disponível. Caso um arquivo seja adquirido com êxito para processamento, o script extrairá dados dele, inclusive o domínio, contadores de força bruta de senha e uma lista de usuários.

De acordo com esses valores do contador, o script verificará se todas as combinações foram esgotadas ou se o número máximo de tentativas com falha foi excedido. Caso as tentativas sejam esgotadas, o objeto será excluído e o processo passará para uma nova iteração. Caso as tentativas persistam, o script tentará autenticar com a ajuda de senhas hardcoded.

Ao tentar adivinhar uma senha para cada usuário, uma requisição de postagem da página da Web é enviada por meio da função WPTryPost. Dependendo do resultado da tentativa de invasão por força bruta, ObjUpd é chamado para atualizar o status da dependência atual e a combinação específica de nome de usuário e senha.

Depois que o status é atualizado, o objeto é desbloqueado e o processo é pausado aleatoriamente antes de continuar o ciclo com um novo alvo. Isso garante a força bruta de credencial multiencadeada e contínua, também regulada pelo script e registrada em um arquivo especial. Esse registro evita que o script seja reiniciado do zero se ele travar.

As senhas adivinhadas com êxito são enviadas para o C2 com o comando GOOD.

Versão alternativa do Efimer

Também descobrimos outro script chamado “assembly.js” (MD5: 100620a913f0e0a538b115dbace78589). Embora semelhante em funcionalidade ao controller.js e ao ntdlg.js, este script tem várias diferenças significativas.

Da mesma forma que o primeiro script, este pertence ao tipo ClipBanker. Assim como seus antecessores, essa variante de malware lê um ID de usuário exclusivo. Desta vez, ele procura o ID em C:\\Users\\Public\\assembly\\GUID. Caso não consiga encontrar ou ler esse ID, uma nova será gerada. Esse novo ID segue o formato M11-XXXX-YYYY, onde XXXX e YYYY são números hexadecimais aleatórios de quatro dígitos. Em seguida, o script verifica se está sendo executado dentro de um ambiente de máquina virtual.

Caso detecte uma VM, ele prefixará a string GUID com um “V”; caso contrário, ele usará um “R”. Depois disso, o diretório onde o GUID está armazenado (que parece ser o diretório de trabalho principal do script) é ocultado.

Depois disso, um arquivo chamado “lptime” é salvo no mesmo diretório. Esse arquivo armazena a hora atual, menos 21.000 segundos. Após a conclusão dessas etapas de configuração inicial, o malware entra no loop principal de operação. A primeira coisa a ser feita é verificar o tempo armazenado no arquivo “lptime”. Caso a diferença entre a hora atual e a hora no arquivo seja maior que 21.600 segundos, ele começará a preparar os dados para enviar ao servidor.

Depois disso, o script tenta ler dados de um arquivo denominado “geip”, que deve estar localizado em C:\\Users\\Public\\assembly\\geip. Esse arquivo contém informações sobre o país e o endereço IP do dispositivo infectado. Caso esteja ausente, o script recupera informações de https://ipinfo.io/json e as salva. Em seguida, ele ativa o serviço Tor, localizado em C:\\Users\\Public\\assembly\\upsvc.exe.

Depois, o script usa a função GetWalletsList para localizar carteiras de criptomoedas e compilar uma lista de suas descobertas.

Ele prioriza a verificação dos diretórios de extensões dos navegadores Google Chrome e Brave, assim como de pastas de aplicativos específicos de carteiras de criptomoedas, cujos caminhos estão hardcoded no script.

Então, o script lê um arquivo denominado “data” de C:\\Users\\Public\\assembly. Normalmente, esse arquivo contém os resultados de pesquisas anteriores de frases mnemônicas na área de transferência. Por fim, o script envia os dados desse arquivo, juntamente com as carteiras de criptomoedas descobertas nas pastas do aplicativo, para um servidor C2 em:

Depois que o script envia os dados, ele verifica a resposta do servidor com a ajuda da função CheckOnionCMD, semelhante às funções encontradas nos outros scripts. A resposta do servidor pode conter um dos seguintes comandos:

• RPLY retorna “OK”. Essa resposta só é recebida depois que as carteiras de criptomoedas são enviadas e indica que o servidor recebeu os dados com êxito. Caso o servidor retorne “OK”, o arquivo de dados antigo será excluído. No entanto, caso a transmissão falhe (nenhuma resposta foi recebida), o arquivo não será excluído. Isso garante que, caso o servidor C2 esteja temporariamente indisponível, as carteiras acumuladas ainda poderão ser enviadas assim que a comunicação for restabelecida.
• EVAL executa um script JavaScript fornecido na resposta.
• KILL remove completamente todos os componentes do malware e encerra sua operação.

Em seguida, o script verifica a área de transferência em busca de strings que se assemelhem a frases mnemônicas e endereços de carteira de criptomoedas.

Todos os dados descobertos são criptografados por XOR com o uso da chave $@#LcWQX3$ e salvos em um arquivo denominado “dados”. Após essas etapas, todo o ciclo se repete.

Script de coleta de endereços de e-mail “Liame”

Este script atua como outro spyware, assim como os outros que discutimos, e compartilha muitas semelhanças. No entanto, seu objetivo é totalmente diferente. O objetivo principal é coletar endereços de e-mail de sites especificados e enviá-los ao servidor C2. O script recebe a lista de sites de destino como um comando do C2. Vamos detalhar sua funcionalidade com mais detalhes.

Ao iniciar, o script primeiro verifica a presença do LUID (identificador único do sistema atual) no diretório de trabalho principal, localizado em C:\\Users\\Public\\Controller\\LUID. Caso o LUID não possa ser encontrado, ele criará um por meio de uma função semelhante àquelas vistas em outros scripts. Neste caso, o identificador exclusivo assume o formato fl01-<4 caracteres hexadecimais aleatórios>.

Em seguida, a função checkUpdate() é executada. Essa função verifica se há um arquivo em C:\\Users\\Public\\Controller\\update_l.flag. Caso o arquivo exista, o script aguardará 30 segundos, excluirá update_l.flag e encerrará sua operação.

Depois, o script enviará periodicamente (a cada 10 minutos) uma solicitação ao servidor para receber comandos. Ele usa uma função denominada PingToOnion, semelhante às funções com nomes idênticos em outros scripts.

A requisição inclui os seguintes parâmetros:

• LIAM: identificador exclusivo
• action: tipo de requisição
• data: dados correspondentes ao tipo de requisição

Nesta seção do código, a string LIAM é usada como a action e o parâmetro data contém o número de endereços de e-mail coletados juntamente com as estatísticas de operação do script.

Caso o script seja encerrado inesperadamente devido a um erro, ele poderá enviar um log, além das estatísticas, em que o parâmetro action conterá a string LOGS e o parâmetro data conterá a mensagem de erro.

A requisição é enviada para o seguinte endereço C2:

O servidor retorna uma estrutura tipo JSON, que será posteriormente processada pela função seguinte.

A estrutura determina os comandos que o script deve executar.

Esse script é compatível com duas funções principais:

• Obter uma lista de endereços de e-mail de domínios fornecidos pelo servidor
  

  O script recebe domínios e itera por meio de cada um para encontrar hiperlinks e endereços de e-mail nas páginas do site.

  A função GetPageLinks analisa o conteúdo HTML de uma página da Web e extrai todos os links que residem no mesmo domínio da página original. Essa função filtra esses links para reter apenas aqueles que apontam para arquivos HTML/PHP ou arquivos sem extensões.

  

  A função PageGetLiame extrai endereços de e-mail do conteúdo HTML da página. Ela pode processar endereços exibidos abertamente e aqueles encapsulados em links mailto.

  

  Após essa coleta inicial, o script analisa todos os links coletados anteriormente nos domínios fornecidos por C2 para continuar a busca por endereços de e-mail adicionais. Por fim, o script remove duplicatas de toda a lista de endereços de e-mail coletados e os salva para uso futuro.

• Exfiltração de dados coletados para o servidor
  Neste cenário, o script antecipa dois parâmetros da resposta do servidor C2: pstack e buffer, onde:
  • pstack é uma matriz de domínios para os quais as requisições POST subsequentes serão enviadas;
  • buffer é uma matriz de strings, cada uma contendo dados no formato de endereço, assunto, mensagem.

O script seleciona aleatoriamente um domínio do pstack e, em seguida, carrega uma das strings do parâmetro buffer para ele. Essa parte do script provavelmente funciona como um módulo de spam, desenvolvido para preencher formulários nos sites visados. Para cada envio de dados bem-sucedido por meio de uma requisição POST para um domínio específico, o script atualiza as estatísticas (que mencionamos anteriormente) com o número de transmissões bem-sucedidas para aquele domínio.

Caso ocorra um erro dentro desse loop, o script detectará e relatará o possível erro para o servidor C2 com o comando LOGS.

Em todo o código, é possível encontrar frequentemente o termo “Liame”, que nada mais é o termo “E-mail” escrito ao contrário. Da mesma forma, variações como “Liama”, “Liam” e “Liams” também estão presentes, provavelmente derivadas de “Liame”. Esse tipo de “jogo de palavras” no código é quase que uma tentativa de ofuscar a intenção maliciosa de suas funções. Por exemplo, em vez de uma função claramente denominada “PageGetEmail”, é possível encontrar “PageGetLiame”.

Vítimas

De outubro de 2024 a julho de 2025, as soluções da Kaspersky detectaram o trojan Efimer afetando 5.015 usuários da Kaspersky. O malware exibiu o nível mais alto de atividade no Brasil, onde os ataques afetaram 1.476 usuários. Outros países significativamente afetados incluem Índia, Espanha, Rússia, Itália e Alemanha.

Os 10 principais países pelo número de usuários que encontraram o Efimer (download)

Conclusões

O trojan Efimer combina várias ameaças graves. Embora seu objetivo principal seja roubar e trocar carteiras de criptomoedas, ele também pode usar scripts adicionais para comprometer sites WordPress e distribuir spam. Isso permite que ele estabeleça uma infraestrutura maliciosa completa e se espalhe para novos dispositivos.

Outra característica interessante desse trojan é sua tentativa de se propagar entre usuários individuais e ambientes corporativos. No primeiro caso, os atacantes usavam arquivos torrent como isca, supostamente para baixar filmes populares; no outro, eles enviavam reclamações sobre o suposto uso não autorizado de palavras ou frases registradas por outra empresa.

É importante notar que, em ambos os cenários, a infecção só foi possível com o download feito pelo usuário, seguido da iniciação do arquivo malicioso por conta própria. Para se proteger contra esses tipos de ameaças, recomendamos que os usuários evitem baixar arquivos torrent de fontes desconhecidas ou questionáveis, sempre verifiquem os remetentes de e-mail e atualizem consistentemente os bancos de dados de antivírus.

Para desenvolvedores e administradores de sites, é fundamental implementar medidas para proteger os recursos contra comprometimento e distribuição de malware. Isso inclui atualizar regularmente o software, usar senhas fortes (não padrão) e autenticação em dois fatores e monitorar continuamente os sites quanto a sinais de violação.

Indicadores de comprometimento

Hashes de arquivos maliciosos
39fa36b9bfcf6fd4388eb586e2798d1a – Requirement.wsf
5ba59f9e6431017277db39ed5994d363 – controller.js
442ab067bf78067f5db5d515897db15c – xmpeg_player.exe
16057e720be5f29e5b02061520068101 – xmpeg_player.exe
627dc31da795b9ab4b8de8ee58fbf952 – ntdlg.js
0f5404aa252f28c61b08390d52b7a054 – btdlg.js
eb54c2ff2f62da5d2295ab96eb8d8843 – liame.js
100620a913f0e0a538b115dbace78589 – assembly.js
b405a61195aa82a37dc1cca0b0e7d6c1 – btdlg.js
Hashes de arquivos limpos envolvidos no ataque
5d132fb6ec6fac12f01687f2c0375353 – ntdlg.exe (Tor)

Sites
hxxps://lovetahq[.]com/sinners-2025-torent-file/hxxps://lovetahq[.]com/wp-content/uploads/2025/04/movie_39055_xmpg.zip

URLs C2
hxxp://cgky6bn6ux5wvlybtmm3z255igt52ljml2ngnc5qp3cnw5jlglamisad[.]onionhxxp://he5vnov645txpcv57el2theky2elesn24ebvgwfoewlpftksxp4fnxad[.]onion