Perseguindo Redemoinhos: Novo InfoStealer baseado em Rust usado em campanhas de CAPTCHA

Preâmbulo

O Elastic Security Labs descobriu um novo infostealer baseado em Rust distribuído por meio de campanhas de CAPTCHA falso. Este malware está hospedado em várias propriedades da web controladas pelo adversário. Esta campanha utiliza páginas enganosas de verificação de CAPTCHA que induzem os usuários a executar um script malicioso do PowerShell, que, por fim, implanta o infostealer, coletando dados confidenciais, como credenciais, informações do navegador e detalhes da carteira de criptomoedas. Estamos chamando esse malware de EDDIESTEALER.

Essa adoção do Rust no desenvolvimento de malware reflete uma tendência crescente entre agentes de ameaças que buscam aproveitar recursos de linguagem modernos para maior furtividade, estabilidade e resiliência contra fluxos de trabalho de análise tradicionais e mecanismos de detecção de ameaças. Um infostealer aparentemente simples escrito em Rust geralmente requer esforços de análise mais dedicados em comparação ao seu equivalente em C/C++, devido a fatores como abstrações de custo zero, sistema de tipos do Rust, otimizações do compilador e dificuldades inerentes na análise de binários seguros para memória.

Principais conclusões

• Campanha CAPTCHA falsa carrega EDDIESTEALER
• EDDIESTEALER é um infostealer Rust recentemente descoberto que tem como alvo hosts Windows
• EDDIESTEALER recebe uma lista de tarefas do servidor C2 identificando dados para o alvo

Acesso inicial

Visão geral

CAPTCHAs falsos são construções maliciosas que replicam a aparência e a funcionalidade de sistemas CAPTCHA legítimos, usados para distinguir entre usuários humanos e bots automatizados. Diferentemente de seus equivalentes legítimos, os CAPTCHAs falsos servem como portas de entrada para malware, aproveitando a engenharia social para enganar os usuários. Eles geralmente aparecem como avisos como "Verifique se você é um humano" ou "Não sou um robô", combinando perfeitamente com sites comprometidos ou campanhas de phishing. Também encontramos uma campanha semelhante distribuindo GHOSTPULSE no final de 2024.

Da nossa análise de telemetria até a entrega do EDDIESTEALER, o vetor inicial foi um site comprometido implantando um payload JavaScript ofuscado baseado em React que exibe uma tela de verificação falsa "Não sou um robô".

Imitando a interface de verificação reCAPTCHA do Google, o malware usa o método document.execCommand("copy") para copiar um comando do PowerShell para a área de transferência do usuário. Em seguida, ele instrui o usuário a pressionar Windows + R (para abrir a caixa de diálogo Executar do Windows), depois Ctrl + V para colar o conteúdo da área de transferência e, finalmente, Enter para executar o comando malicioso do PowerShell.

Este comando baixa silenciosamente uma carga útil de segundo estágio (gverify.js) do domínio controlado pelo invasor hxxps://llll.fit/version/ e a salva na pasta Downloads do usuário.

Por fim, o malware executa gverify.js usando cscript em uma janela oculta.

gverify.js é outra carga útil JavaScript ofuscada que pode ser desofuscada usando ferramentas de código aberto. Sua funcionalidade é bastante simples: buscar um executável (EDDIESTEALER) de hxxps://llll.fit/io e salvar o arquivo na pasta Downloads do usuário com um nome de arquivo pseudoaleatório de 12 caracteres.

EDDIESTEALER

Visão geral

EDDIESTEALER é um novo infostealer de commodities baseado em Rust. A maioria das sequências de caracteres que revelam sua intenção maliciosa são criptografadas. O malware não possui proteções robustas anti-sandbox/VM contra impressão digital comportamental. No entanto, variantes mais recentes sugerem que as verificações anti-sandbox/VM podem estar ocorrendo no lado do servidor. Com recursos relativamente simples, ele recebe uma lista de tarefas do servidor C2 como parte de sua configuração para direcionar dados específicos e pode se autoexcluir após a execução, se especificado.

Símbolos Despojados

Os exemplos do EDDIESTEALER continham símbolos de função simplificados, provavelmente usando a opção de compilação padrão do Rust, exigindo restauração de símbolos antes da análise estática. Usamos rustbinsign, que gera assinaturas para bibliotecas padrão do Rust e cria com base em versões específicas do Rust/compilador/dependência. Embora rustbinsign tenha detectado apenas hashbrown e rustc-demangle, sugerindo que poucas caixas externas foram usadas, ele não conseguiu identificar caixas como tinyjson e tungstenite em variantes mais recentes. Isso ocorreu devido à falta de artefatos de cordas claros. Ainda é possível identificar manualmente as caixas encontrando sequências de caracteres exclusivas e pesquisando o repositório no GitHub, depois baixar, compilar e criar assinaturas para elas usando o modo download_sign . É um pouco complicado se não sabemos a versão exata da caixa que está sendo usada. No entanto, restaurar a biblioteca padrão e os símbolos de tempo de execução é suficiente para avançar o processo de análise estática.

Ofuscação de Strings

EDDIESTEALER criptografa a maioria das strings por meio de uma cifra XOR simples. A descriptografia envolve duas etapas: primeiro, a chave XOR é derivada chamando uma das diversas funções de derivação de chaves; depois, a descriptografia é executada em linha dentro da função que usa a string.

O exemplo a seguir ilustra isso, onde sub_140020fd0 é a função de derivação da chave e data_14005ada8 é o endereço do blob criptografado.

Cada rotina de descriptografia utiliza sua própria função distinta de derivação de chave. Essas funções aceitam consistentemente dois argumentos: um endereço dentro do binário e um valor constante de 4 bytes. Algumas operações básicas são então executadas nesses argumentos para calcular o endereço onde a chave XOR reside.

O Binary Ninja tem um recurso útil chamado User-Informed Data Flow (UIDF), que podemos usar para definir as variáveis com valores conhecidos para acionar uma análise de propagação constante e simplificar as expressões. Caso contrário, um emulador de CPU como o Unicorn emparelhado com uma ferramenta de análise binária programável também pode ser útil para análise em lote.

Há um padrão geral para inicialização lenta e segura de recursos compartilhados, como strings criptografadas para nomes de módulos, domínio e porta C2, o identificador exclusivo da amostra — que são descriptografados apenas uma vez, mas referenciados muitas vezes durante o tempo de execução. Cada função getter específica verifica um sinalizador de status para seu recurso; se não inicializada, ela chama uma função de sincronização compartilhada de baixo nível. Esta rotina de sincronização usa operações atômicas e primitivas de espera do sistema operacional (WaitOnAddress/WakeByAddressAll) para garantir que apenas um thread execute a lógica de inicialização real, que é invocada indiretamente por meio de um ponteiro de função na vtable de um objeto dyn Trait .

Ofuscação de API

O EDDIESTEALER utiliza um mecanismo de pesquisa WinAPI personalizado para a maioria das chamadas de API. Ele começa descriptografando os nomes do módulo e da função de destino. Antes de tentar a resolução, ele verifica uma tabela de hash mantida localmente para ver se o nome e o endereço da função já foram resolvidos. Se não for encontrado, ele carrega dinamicamente o módulo necessário usando um wrapper LoadLibrary personalizado no espaço de endereço do processo e invoca uma implementação bem conhecida de GetProcAddress para recuperar o endereço da função exportada. O nome e o endereço da API são então inseridos na tabela de hash, otimizando pesquisas futuras.

Criação de Mutex

O EDDIESTEALER começa criando um mutex para garantir que apenas uma instância do malware seja executada a qualquer momento. O nome do mutex é uma string UUID descriptografada 431e2e0e-c87b-45ac-9fdb-26b7e24f0d39 (única por amostra), que é posteriormente referenciada mais uma vez durante seu contato inicial com o servidor C2.

Detecção de Sandbox

EDDIESTEALER realiza uma verificação rápida para avaliar se a quantidade total de memória física está acima de ~4,0 GB como um mecanismo fraco de detecção de sandbox. Se a verificação falhar, ele será excluído do disco.

Autoexclusão

Com base em uma técnica de autoexclusão semelhante observada no LATRODECTUS, o EDDIESTEALER é capaz de se autoexcluir por meio da renomeação de NTFS Alternate Data Streams, para ignorar bloqueios de arquivos.

O malware usa GetModuleFileName para obter o caminho completo do seu executável e CreateFileW (envolvido em jy::ds::OpenHandle) para abrir um identificador para seu arquivo executável com os direitos de acesso apropriados. Em seguida, uma estrutura FILE_RENAME_INFO com um novo nome de fluxo é passada para SetFileInformationByHandle para renomear o fluxo padrão $DATA para :metadata. O identificador do arquivo é fechado e reaberto, desta vez usando SetFileInformationByHandle no identificador com o sinalizador FILE_DISPOSITION_INFO.DeleteFile definido como TRUE para habilitar um sinalizador "excluir ao fechar o identificador".

Solicitação de configuração adicional

Os dados de configuração inicial são armazenados como strings criptografadas dentro do binário. Uma vez descriptografados, esses dados são usados para construir uma solicitação seguindo o padrão URI: <C2_ip_or_domain>/<resource_path>/<UUID>. O resource_path é especificado como api/handler. O UUID, utilizado anteriormente para criar um mutex, é usado como um identificador exclusivo para rastreamento de compilação.

O EDDIESTEALER então se comunica com seu servidor C2 enviando uma solicitação HTTP GET com o URI construído para recuperar uma configuração de segundo estágio contendo uma lista de tarefas para o malware executar.

Os dados de configuração do segundo estágio são criptografados em AES CBC e codificados em Base64. O IV codificado em Base64 é adicionado na mensagem antes dos dois pontos (:).

Base64(IV):Base64(AESEncrypt(data))

A chave AES para descriptografar a mensagem do servidor para o cliente é armazenada sem criptografia na codificação UTF-8, na seção .rdata . Ele é recuperado por meio de uma função getter.

A configuração descriptografada para este exemplo contém o seguinte no formato JSON:

• ID da sessão
• Lista de tarefas (dados a serem segmentados)
• Chave AES para criptografia de mensagens cliente-servidor
• Sinalizador de autoexclusão

{
    "session": "<unique_session_id>",
    "tasks": [
        {
            "id": "<unique_task_id>",
            "prepare": [],
            "pattern": {
                "path": "<file_system_path>",
                "recursive": <true/false>,
                "filters": [
                    {
                        "path_filter": <null/string>,
                        "name": "<file_or_directory_name_pattern>",
                        "entry_type": "<FILE/DIR>"
                    },
                    ...
                ]
            },
            "additional": [
                {
                    "command": "<optional_command>",
                    "payload": {
                        "<command_specific_config>": <value>
                    }
                },
                ...
            ]
        },
        ...
    ],
    "network": {
        "encryption_key": "<AES_encryption_key>"
    },
    "self_delete": <true/false>
}

Para este exemplo específico e com base nas tarefas recebidas do servidor durante nossa análise, aqui está a lista de alvos de exfiltração baseados em sistema de arquivos:

• Carteiras de criptomoedas
• Navegadores
• Gerenciadores de senhas
• Clientes FTP
• Aplicativos de mensagens

Uma lista de extensões de navegador direcionadas pode ser encontrada aqui.

Essas metas estão sujeitas a alterações, pois são configuráveis pelo operador C2.

O EDDIESTEALER então lê os arquivos de destino usando funções kernel32.dll padrão como CreateFileW, GetFileSizeEx, ReadFile e CloseHandle.

Tráfego C2 subsequente

Após recuperar as tarefas com sucesso, o EDDIESTEALER executa a criação de perfil do sistema para coletar algumas informações sobre o sistema infectado:

• Localização do executável (GetModuleFileNameW)
• ID de localidade (GetUserDefaultLangID)
• Nome de usuário (GetUserNameW)
• Quantidade total de memória física (GlobalMemoryStatusEx)
• Versão do sistema operacional (RtlGetVersion)

Seguindo o mesmo formato de dados (Base64(IV):Base64(AESEncrypt(data))) para mensagens de cliente para servidor, as informações iniciais do host são criptografadas em AES usando a chave recuperada da configuração adicional e enviada por meio de uma solicitação HTTP POST para <C2_ip_or_domain>/<resource_path>/info/<session_id>. Posteriormente, para cada tarefa concluída, os dados coletados também são criptografados e transmitidos em solicitações POST separadas para <C2_ip_or_domain>/<resource_path><session_id>/<task_id>, logo após a conclusão de cada tarefa. Essa metodologia gera um padrão distinto de tráfego C2 caracterizado por múltiplas solicitações POST específicas de tarefas. Esse padrão é particularmente fácil de identificar porque essa família de malware depende principalmente de HTTP em vez de HTTPS para sua comunicação C2.

Nossa análise revelou strings criptografadas que descriptografam para strings de metadados de pânico, revelando caminhos de arquivos de origem internos do Rust, como:

• apps\bin\src\services\chromium_hound.rs
• apps\bin\src\services\system.rs
• apps\bin\src\structs\search_pattern.rs
• apps\bin\src\structs\search_entry.rs

Descobrimos que as mensagens de erro enviadas ao servidor C2 contêm essas sequências de caracteres, incluindo o arquivo de origem exato, o número da linha e o número da coluna onde o erro se originou, permitindo que o desenvolvedor do malware tenha feedback de depuração integrado.

Capacidades específicas do Chromium

Desde a introdução da criptografia vinculada a aplicativos, os desenvolvedores de malware se adaptaram a métodos alternativos para contornar essa proteção e obter acesso a dados confidenciais não criptografados, como cookies. O ChromeKatz é uma das soluções de código aberto mais bem recebidas que vimos malware implementar. EDDIESTEALER não é exceção — os desenvolvedores de malware o reimplementaram em Rust.

Abaixo está um trecho da lógica de verificação da versão do navegador semelhante ao COOKIEKATZ, após recuperar informações de versão de %localappdata%\<browser_specific_path>\\User Data\\Last Version.

Padrão de assinatura COOKIEKATZ para detectar instâncias de COOKIEMONSTER:

Padrão de assinatura CredentialKatz para detectar instâncias do CookieMonster:

Aqui está um exemplo da lógica exata de copiar e colar do FindPattern do COOKIEKATZ, onde PatchBaseAddress é embutido.

Os desenvolvedores introduziram uma modificação para lidar com casos em que o navegador Chromium alvo não está em execução. Se inativo, EDDIESTEALER gera uma nova instância do navegador usando os argumentos de linha de comando --window-position=-3000,-3000 https://google.com. Isso efetivamente posiciona a nova janela bem longe da tela, tornando-a invisível para o usuário. O objetivo é garantir que o malware ainda possa ler a memória (ReadProcessMemory) do processo filho necessário - o processo de serviço de rede identificado pelo sinalizador --utility-sub-type=network.mojom.NetworkService . Para uma explicação mais detalhada dessa interação do processo do navegador, consulte nossa pesquisa anterior sobre infostealers MaaS.

Diferenças com variantes

Após a análise, amostras mais recentes foram identificadas com capacidades adicionais.

As informações coletadas nas máquinas das vítimas agora incluem:

• Running processes
• Informações da GPU
• Número de núcleos de CPU
• Nome da CPU
• Fornecedor de CPU

O padrão de comunicação C2 foi ligeiramente alterado. O malware agora envia preventivamente informações do sistema host para o servidor antes de solicitar sua configuração descriptografada. Em alguns casos em que a máquina vítima conseguiu acessar o servidor C2, mas recebeu uma lista de tarefas vazia, o ajuste sugere uma tática de evasão: os desenvolvedores provavelmente introduziram verificações no lado do servidor para criar o perfil do ambiente do cliente e reter a configuração principal se um sandbox ou sistema de análise for detectado.

A chave de criptografia para comunicação cliente-servidor não é mais recebida dinamicamente do servidor C2; em vez disso, ela agora é codificada no binário. A chave usada pelo cliente para descriptografar mensagens do servidor para o cliente também permanece codificada.

Amostras compiladas mais recentes exibem uso extensivo de expansão de função em linha, onde muitas funções — tanto definidas pelo usuário quanto de bibliotecas e caixas padrão — foram incorporadas diretamente em seus chamadores com mais frequência, resultando em funções maiores e dificultando o isolamento do código do usuário. Esse comportamento provavelmente é resultado do uso do inliner do LLVM. Embora algumas funções permaneçam não incorporadas, a incorporação generalizada complica ainda mais a análise.

Para obter todas as entradas do Gerenciador de Senhas do Chrome, o EDDIESTEALER inicia sua rotina de roubo de credenciais gerando um novo processo do Chrome com o sinalizador --remote-debugging-port=<port_num> , habilitando o Protocolo DevTools do Chrome em uma interface WebSocket local. Isso permite que o malware interaja com o navegador de forma autônoma, sem exigir nenhuma interação visível do usuário.

Após iniciar o Chrome, o malware consulta http://localhost:<port>/json/version para recuperar o webSocketDebuggerUrl, que fornece o ponto de extremidade para interagir com a instância do navegador via WebSocket.

Usando essa conexão, ele emite um comando Target.createTarget com o parâmetro chrome://password-manager/passwords, instruindo o Chrome a abrir seu gerenciador de senhas interno em uma nova guia. Embora esta página interna não exponha seu conteúdo diretamente ao DOM ou ao DevTools, abri-la faz com que o Chrome descriptografe e carregue as credenciais armazenadas na memória. Esse comportamento é explorado pelo EDDIESTEALER em etapas subsequentes por meio do código semelhante ao CredentialKatz, onde ele verifica a memória do processo do Chrome para extrair credenciais de texto simples depois que elas são carregadas pelo navegador.

Com base nas strings descriptografadas os_crypt, encrypted_key, CryptUnprotectData, local_state_pattern e login_data_pattern, as variantes do EDDIESTEALER parecem ser compatíveis com versões anteriores, suportando versões do Chrome que ainda utilizam criptografia DPAPI.

Identificamos 15 amostras adicionais de EDDIESTEALER por meio de similaridades de código e infraestrutura no VirusTotal. A tabela de observações incluirá as amostras descobertas, endereços IP/domínios C2 associados e uma lista de infraestrutura que hospeda o EDDIESTEALER.

Algumas dicas de análise

Rastreio

Para entender melhor o fluxo de controle e identificar os destinos exatos de saltos indiretos ou chamadas em grandes blocos de código, podemos aproveitar técnicas de rastreamento binário. Ferramentas como TinyTracer podem capturar um rastreamento de API e gerar um arquivo .tag , que mapeia quaisquer chamadas de API selecionadas a serem gravadas na linha de execução no assembly. As funções da biblioteca padrão do Rust chamam WinAPIs internamente, e isso também captura qualquer código que chama funções WinAPI diretamente, ignorando a abstração da biblioteca padrão. O arquivo de tags pode então ser importado para ferramentas de descompilação para marcar automaticamente os blocos de código usando plugins como IFL.

Metadados de pânico para segmentação de código

Metadados de pânico - os caminhos de arquivo de origem incorporados (arquivos .rs), números de linha e números de coluna associados aos locais de pânico - oferecem pistas valiosas para segmentar e entender diferentes partes do binário. No entanto, isso só acontece se esses metadados não tiverem sido removidos do binário. Caminhos como apps\bin\src\services\chromium.rs, apps\bin\src\structs\additional_task.rs ou qualquer caminho que pareça parte de um projeto personalizado normalmente apontam para a lógica exclusiva do aplicativo. Caminhos que começam com library<core/alloc/std>\src\ indicam código da biblioteca padrão Rust. Caminhos contendo nome e versão da caixa, como hashbrown-0.15.2\src\raw\mod.rs , apontam para bibliotecas externas.

Se o projeto de malware tiver uma base de código um tanto organizada, os caminhos de arquivo nas strings de pânico podem ser mapeados diretamente para módulos lógicos. Por exemplo, a string descriptografada apps\bin\src\utils\json.rs:48:39 é referenciada em sub_140011b4c.

Ao examinar a árvore de chamadas para chamadas recebidas para a função, muitas delas retornam para sub_14002699d. Esta função (sub_14002699d) é chamada dentro de uma rotina de comunicação C2 conhecida (jy::C2::RetrieveAndDecryptConfig), logo após descriptografar dados de configuração adicionais conhecidos por serem formatados em JSON.

Com base no caminho json.rs e seu contexto de chamada, um palpite bem fundamentado seria que sub_14002699d é responsável por analisar dados JSON. Podemos verificar isso passando por cima da chamada de função. Com certeza, ao inspecionar a estrutura de pilha que é passada como referência para a chamada de função, ela agora aponta para um endereço de heap preenchido com campos de configuração analisados.

Para caixas de biblioteca padrão e de terceiros de código aberto, o caminho do arquivo, o número da linha e (se disponível) o hash de confirmação do rustc ou a versão da caixa permitem que você pesquise o código-fonte exato online.

Reutilização de Slot de Pilha

Um dos recursos de otimização envolve a reutilização de slots de pilha para variáveis/estruturas de pilha que não têm linhas de tempo sobrepostas. Variáveis que não estão “ativas” ao mesmo tempo podem compartilhar o mesmo local de memória da pilha, reduzindo o tamanho geral do quadro da pilha. Essencialmente, uma variável está ativa desde o momento em que lhe é atribuído um valor até o último ponto em que esse valor pode ser acessado. Isso torna a saída descompilada confusa, pois o mesmo deslocamento de memória pode conter tipos ou valores diferentes em pontos diferentes.

Para lidar com isso, podemos definir uniões abrangendo todos os tipos possíveis que compartilham o mesmo deslocamento de memória dentro da função.

Tratamento de erros de ferrugem e enumerações

As enumerações Rust são uniões marcadas que definem tipos com diversas variantes, cada uma contendo dados opcionalmente, ideais para modelar estados como sucesso ou falha. As variantes são identificadas por um discriminante (tag).

O código de tratamento de erros pode ser visto em todo o binário, constituindo uma parte significativa do código descompilado. O mecanismo principal do Rust para tratamento de erros é a enumeração genérica Result<T, E> . Ele tem duas variantes: Ok(T), indicando sucesso e contendo um valor do tipo T, e Err(E), indicando falha e contendo um valor de erro do tipo E.

No snippet de exemplo abaixo, um valor discriminante de 0x8000000000000000 é usado para diferenciar os resultados da resolução da API CreateFileW . Se CreateFileW for resolvido com sucesso, o tipo de variável reuse conterá o ponteiro de função da API e a ramificação else será executada. Caso contrário, a ramificação if é executada, atribuindo uma sequência de informações de erro de reuse a arg1.

Para mais informações sobre como outros tipos comuns de Rust podem aparecer na memória, confira esta folha de dicas e esta palestra incrível de Cindy Xiao!

Malware e MITRE ATT&CK

A Elastic usa a estrutura MITRE ATT&CK para documentar táticas, técnicas e procedimentos comuns que as ameaças usam contra redes corporativas.

Táticas

• Acesso inicial
• Execução
• Defense Evasion
• Exfiltração
• Acesso a credenciais
• Descoberta
• Coleta

Técnicas

Técnicas representam como um adversário atinge um objetivo tático executando uma ação.

• Phishing
• Injeção de conteúdo
• Interpretador de comandos e scripts
• Credenciais de armazenamentos de senhas
• User Execution
• Arquivos ou informações ofuscadas
• Exfiltração sobre o canal C2
• Evasão de Virtualização/Sandbox

Detecções

YARA

A Elastic Security criou as seguintes regras YARA relacionadas a esta pesquisa:

• Windows.Infostealer.EddieStealer

Regras de prevenção comportamental

• Suspicious PowerShell Execution
• Transferência de ferramenta Ingress via PowerShell
• Descoberta potencial de informações do navegador
• Potential Self Deletion of a Running Executable

Observações

Os seguintes observáveis foram discutidos nesta pesquisa.

Referências

Os seguintes itens foram referenciados ao longo da pesquisa acima:

• https://github.com/N0fix/rustbinsign
• https://github.com/Meckazin/ChromeKatz
• https://github.com/hasherezade/tiny_tracer
• https://docs.binary.ninja/dev/uidf.html
• https://www.unicorn-engine.org/
• https://github.com/LloydLabs/delete-self-poc/tree/main
• https://cheats.rs/#layout-de-memória
• https://www.youtube.com/watch?v=SGLX7g2a-gw&t=749s
• https://cxiao.net/posts/2023-12-08-ferrugem-reversing-panic-metadata/