Trojan bancário Karius usa webinjects e ainda mostra sinais de desenvolvimento

A amostra distribuída pelo kit de exploração RIG combina injeção em navegadores, canal local por named pipe, comunicação C&C cifrada com RC4 e trechos semelhantes a Ramnit, Vawtrak e TrickBot.

Componente	Trojan bancário Karius, composto por injector32.exe ou injector64.exe, módulos proxy32.dll e proxy64.dll, e payloads finais mod32.dll ou mod64.dll injetados em navegadores.
Vetor	Distribuição observada por meio do kit de exploração RIG, com execução inicial do componente injector e posterior injeção de módulos conforme a arquitetura do sistema.
Impacto	Intercepção e alteração de sessões web em navegadores para inserir campos adicionais em páginas bancárias legítimas e encaminhar credenciais capturadas ao operador por C&C.
Prioridade	Priorizar detecção de injeção em explorer.exe e navegadores, criação da named pipe \\.\pipe\form, persistência no diretório de inicialização e alterações de chaves do Internet Explorer.
Artefatos	Uso de temp.bin para configuração de webinjects, compactação aPLib para módulos de 32 e 64 bits, tráfego C&C cifrado com RC4 e duplicação local como %USERPROFILE%/music/temp.exe.
Limite	A amostra analisada ainda não estava em modo completo de infecção e os webinjects não apontavam para instituições financeiras específicas no material recebido.

Resumo técnico

Karius é um trojan bancário em desenvolvimento observado em distribuição pelo kit de exploração RIG. A amostra segue um modelo clássico de malware financeiro para Windows: um componente inicial prepara o ambiente, baixa ou obtém configuração de webinjects, injeta módulos auxiliares em processos do sistema e, por fim, coloca código dentro de navegadores usados pela vítima. O objetivo técnico é modificar a experiência de navegação em páginas bancárias legítimas, adicionando campos ou elementos capazes de induzir o usuário a fornecer dados financeiros ou credenciais, que são então enviados ao operador da ameaça.

O ponto relevante para defesa é que o malware ainda apresentava sinais claros de construção e teste. O material descreve duas versões principais, uma mais instável e aparentemente usada para validação, e outra mais funcional, mas ainda incompleta. A presença de strings de placeholder, mecanismos de depuração e webinjects que não miravam bancos específicos indica uma família em evolução, não uma operação plenamente madura. Ainda assim, os blocos técnicos já são suficientes para representar risco, porque cobrem persistência, injeção em processos, manipulação de navegador, comunicação C&C e coleta de credenciais.

Fluxo técnico

A execução começa pelo módulo injector32.exe ou por seu equivalente de 64 bits, injector64.exe. Esse componente centraliza várias funções: registra o bot junto ao servidor C&C, recebe comandos, armazena a configuração de webinjects no arquivo temp.bin, cria um canal local para receber dados roubados e prepara os módulos que serão injetados em outros processos. A comunicação com o C&C usa mensagens estruturadas e, após o contato inicial, o tráfego passa a ser cifrado com RC4 usando uma chave fixa presente em uma estrutura de configuração dentro da seção .cfg do binário.

Um dos comandos previstos no fluxo é o envio de configuração, que fornece ao malware o conteúdo de webinjects a ser salvo em temp.bin. Esse arquivo passa a orientar a modificação de páginas acessadas pela vítima. O uso de um arquivo local para armazenar a configuração facilita atualização operacional sem exigir alteração completa do binário, e também cria um artefato útil para resposta a incidente: a presença desse arquivo, especialmente em conjunto com módulos injetados e comunicação C&C, deve elevar a severidade da triagem.

Depois da etapa inicial, o injector descompacta componentes adicionais, incluindo proxy32.dll e proxy64.dll, usando a biblioteca de compressão aPLib. O módulo compatível com a arquitetura do sistema é injetado em explorer.exe. Dentro desse processo, o malware instala um hook em CreateProcessInternalW, função acionada na criação de processos sob o Explorer. O objetivo desse hook é observar a abertura de navegadores e inserir outro módulo, mod32.dll ou mod64.dll, no contexto do navegador correspondente.

Os navegadores citados no material são Internet Explorer, Chrome, Firefox e Edge. O payload final executado no contexto desses navegadores implementa o mecanismo de webinjects por meio de hooks em funções usadas durante a comunicação e renderização de conteúdo web. Quando a vítima acessa uma página compatível com a configuração, o malware pode alterar o conteúdo exibido, solicitar informações adicionais e encaminhar os dados capturados ao componente injector por meio da named pipe \\.\pipe\form. O injector, por sua vez, envia periodicamente os dados ao C&C conforme intervalo definido na configuração interna.

A amostra também executa ações voltadas a reduzir proteções do Internet Explorer. Entre os artefatos estão alterações em chaves sob HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3\2500, HKCU\Software\Microsoft\Internet Explorer\Main\TabProcGrowth e HKCU\Software\Microsoft\Internet Explorer\Main\NoProtectedModeBanner. Essas mudanças indicam tentativa de facilitar o controle do ambiente de navegação e reduzir barreiras de isolamento ou aviso ao usuário. O malware ainda busca persistência ao copiar a si mesmo para o diretório de inicialização com o nome TEMP APPLICATION.lnk e ao criar uma duplicata em %USERPROFILE%/music/temp.exe.

Superfície afetada

A superfície de exposição é composta por estáções Windows que executem a cadeia entregue pelo kit de exploração RIG e que tenham navegadores compatíveis com os alvos do malware. Como a execução inicial depende do sucesso da etapa de exploração e do disparo do componente injector, a exposição prática está associada a ambientes nos quais navegação web, plugins, componentes do navegador ou controles de segurança permitam a execução da carga inicial. O material analisado não traz vulnerabilidade específica, versão afetada ou CVE, portanto a análise defensiva deve se concentrar nos artefatos do malware e não em uma falha única.

O impacto operacional se concentra em usuários que acessam serviços financeiros por navegadores comprometidos. O malware não precisa comprometer diretamente o banco para capturar dados: ele atua no endpoint, interceptando a sessão e modificando a página legítima vista pela vítima. Essa característica reduz a visibilidade do lado do serviço financeiro e desloca a detecção para telemetria de endpoint, criação de processos, injeção em navegador, alterações no registro, arquivos de configuração e padrões de comunicação do host para infraestrutura de C&C.

A análise também aponta reaproveitamento ou forte semelhança com técnicas vistas em outros bankers. O uso de compressão aPLib para armazenar módulos de 32 e 64 bits em sequência foi associado ao padrão observado em Vawtrak. Webinjects hardcoded encontrados em uma amostra já haviam sido usados por Ramnit. A maior semelhança técnica aparece em trechos de código relacionados a injeção e hooking próximos aos de TrickBot, incluindo uso de reflective loading e uma string de depuração em função semelhante. Esses elementos não provam, isoladamente, autoria compartilhada, mas mostram que o desenvolvimento de Karius incorpora blocos técnicos conhecidos no ecossistema de trojans bancários.

• Estáções Windows com execução do componente injector32.exe ou injector64.exe após entrega pelo RIG.
• Processo explorer.exe usado como ponto intermediário para hook de criação de processos e injeção em navegadores.
• Navegadores Internet Explorer, Chrome, Firefox e Edge como alvos de módulos mod32.dll ou mod64.dll.
• Usuários que acessam páginas bancárias por um navegador comprometido, mesmo quando o site legítimo não foi invadido.

Hunting e telemetria

A busca deve combinar telemetria de endpoint, registro, processos e rede. Em endpoint, a correlação mais forte envolve execução de um injector desconhecido, descompressão ou carregamento de DLLs com nomes compatíveis, injeção em explorer.exe e, em seguida, injeção em processos de navegador. A sequência temporal é importante: um evento isolado de navegador pode ser ruidoso, mas explorer.exe criando ou manipulando processos de navegador logo após a execução de um binário suspeito deve ser tratado como sinal de alta prioridade.

A named pipe \\.\pipe\form é um artefato defensivo relevante porque representa o canal local usado pelos módulos de navegador para encaminhar credenciais ao injector. Sensores EDR capazes de registrar criação e uso de named pipes podem correlacionar esse objeto com processos que normalmente não deveriam participar de coleta de formulários. A presença do arquivo temp.bin também merece análise, especialmente se criado próximo à comunicação com um host remoto e ao carregamento de DLLs em navegadores.

Na rede, a investigação deve procurar padrões de beaconing ou mensagens de registro para C&C, levando em conta que o tráfego posterior é cifrado com RC4. Como não há domínio, IP ou URL no contexto, a detecção não deve depender de indicadores de infraestrutura. O caminho mais robusto é observar comportamento: processo recém-persistido gerando tráfego periódico, sequência de registro seguida de comandos de configuração, criação local de temp.bin e envio posterior de dados depois de interação do usuário com páginas sensíveis.

A telemetria de registro deve incluir alterações nas chaves do Internet Explorer citadas. Mesmo em ambientes onde o Internet Explorer não é o navegador principal, alterações que desativam mecanismos de proteção, ajustam isolamento de abas ou escondem banners de modo protegido podem indicar preparação do ambiente por malware. Esses eventos, quando vistos ao lado de persistência por atalho no diretório de inicialização e duplicação em %USERPROFILE%/music/temp.exe, formam uma cadeia de evidência consistente para contenção.

• Criação da named pipe \\.\pipe\form por processo suspeito ou por cadeia relacionada a navegador.
• Arquivo temp.bin criado após contato de rede e antes de alterações de conteúdo em navegação.
• Injeção de DLL em explorer.exe seguida de injeção em Chrome, Firefox, Edge ou Internet Explorer.
• Persistência por TEMP APPLICATION.lnk no diretório de inicialização e cópia em %USERPROFILE%/music/temp.exe.
• Alterações nas chaves Zones\3\2500, TabProcGrowth e NoProtectedModeBanner no hive do usuário.

Mitigação

A resposta deve começar pela contenção do endpoint afetado, preservando memória e artefatos em disco antes de remover arquivos. Como Karius depende de injeção em processos e canais locais, a coleta de memória pode revelar módulos carregados em explorer.exe e navegadores, além de strings de configuração, referências a temp.bin, named pipes e estruturas de comunicação. A simples exclusão do binário inicial pode perder evidências úteis para entender escopo, credenciais expostas e possível comunicação com C&C.

Na erradicação, remova a persistência no diretório de inicialização, valide a ausência da cópia em %USERPROFILE%/music/temp.exe, reverta as chaves de registro alteradas e reinicie sessões de navegador após confirmar que não há DLLs suspeitas injetadas. Contas usadas para acesso bancário ou administrativo a partir do host devem passar por troca de credenciais e revisão de eventos, porque o mecanismo de webinjects visa coletar entradas de formulário. A rotação deve priorizar credenciais digitadas durante a janela de infecção, não contas sem evidência de uso no endpoint comprometido.

A prevenção deve combinar endurecimento de navegação, redução de exposição a kits de exploração, inspeção de comportamento de endpoint e controle de execução. Bloqueio de conteúdo explorável, atualização de navegadores e componentes associados, restrição de escrita em diretórios de inicialização e detecção de injeção em processos de navegador reduzem a chance de execução bem-sucedida. Para equipes de engenharia de detecção, a prioridade é criar correlações comportamentais, porque o material não fornece indicadores de rede suficientes e o malware aparenta estar em evolução, com possibilidade de novas versões.

A validação pós-incidente deve confirmar que não há novos webinjects em disco, que o tráfego periódico cessou, que os navegadores não carregam módulos não autorizados e que o registro do usuário não contém alterações remanescentes ligadas às proteções do Internet Explorer. Também é importante revisar logs de autenticação e transações associadas aos usuários afetados, mantendo a análise dentro do impacto confirmado: captura de credenciais e manipulação de páginas no endpoint. O contexto não sustenta afirmar vazamento amplo, movimentação lateral ou comprometimento direto de instituições financeiras.

• Isolar o host e coletar memória, processos, módulos carregados, arquivos temp.bin, atalhos de inicialização e chaves de registro afetadas.
• Remover persistência, encerrar processos injetados e reinstanciar navegadores somente após validação de integridade.
• Reverter alterações no Internet Explorer e revisar políticas que permitam modificação não autorizada de configurações do usuário.
• Rotacionar credenciais digitadas no endpoint durante a janela provável de infecção e revisar autenticações financeiras relacionadas.
• Criar regras comportamentais para injeção em explorer.exe, named pipe \\.\pipe\form, carregamento de DLLs em navegadores e criação de temp.bin.