Casbaneiro volta a mirar a América Latina com cadeia de ataque em múltiplas etapas

Uma nova campanha do trojan bancário Casbaneiro identificada pela FortiGuard Labs em agosto de 2026 mostra como ataques direcionados ao setor financeiro continuam evoluindo para dificultar tanto a detecção quanto a análise técnica. A atividade observada tem como foco usuários da América Latina e combina phishing, arquivos PDF, páginas com controle geográfico, carregadores em múltiplas etapas e servidores separados para recebimento de informações roubadas e comunicação de comando e controle.

O Casbaneiro já é conhecido por sua atuação contra usuários e instituições financeiras da região. Entre suas funcionalidades estão manipulação da área de transferência, coleta de informações e uso de janelas falsas para apoiar fraudes bancárias. A campanha mais recente, porém, apresenta uma arquitetura que procura reduzir a visibilidade de cada etapa do ataque e fazer com que parte da infraestrutura pareça inativa durante análises automatizadas.

Esse comportamento reforça um desafio importante para as equipes de segurança: identificar uma ameaça não depende apenas de reconhecer um arquivo malicioso. Em campanhas com vários estágios, o comportamento observado no endpoint, no tráfego de rede e durante a navegação do usuário precisa ser analisado de forma correlacionada.

Phishing continua sendo o ponto de entrada

A campanha começa com mensagens de phishing e documentos PDF que simulam cobranças, faturas ou notificações relacionadas a processos legais. Os conteúdos procuram gerar urgência e, em alguns casos, incluem o endereço de e-mail da própria vítima para aumentar a aparência de legitimidade.

Os links direcionam o usuário para páginas controladas pelos atacantes, mas o conteúdo entregue depende da localização do endereço IP utilizado no acesso. Segundo a análise da FortiGuard Labs, foram observadas atividades relacionadas a países como Argentina, Peru, Colômbia e México, evidenciando uma estratégia de segmentação regional.

Quando o endereço IP não pertence a uma região considerada de interesse pelos operadores da campanha, a página pode simplesmente redirecionar o visitante para serviços legítimos, como Google ou YouTube. Para ferramentas automatizadas de análise executadas fora das regiões selecionadas, o site pode parecer completamente inofensivo.

Quando o acesso ocorre a partir da localização esperada, a página disponibiliza um arquivo ZIP codificado em Base64 dentro do próprio JavaScript. O navegador inicia o download utilizando seus mecanismos normais e, posteriormente, o usuário é direcionado para uma página em branco. Essa combinação procura reproduzir um fluxo aparentemente comum de download e, ao mesmo tempo, limitar a exposição do conteúdo malicioso.

Uma cadeia de execução construída em várias etapas

O arquivo ZIP entregue ao usuário contém um arquivo HTA responsável por iniciar a próxima fase da infecção. Esse arquivo acessa um recurso JavaScript externo, que posteriormente recupera um pacote de scripts em XML contendo código JScript.

Antes de avançar, o malware realiza verificações no computador por meio do Windows Management Instrumentation, o WMI. Entre as informações avaliadas estão características que possam indicar a execução em ambientes de análise e o idioma configurado no sistema operacional. A execução continua somente quando o ambiente atende aos critérios definidos pelo atacante.

Quando as verificações são concluídas, diferentes componentes são baixados separadamente para um diretório com nome aleatório no Windows. Entre eles estão o interpretador legítimo do AutoIt, um script AutoIt compilado e um arquivo compactado utilizado posteriormente para obtenção do payload final.

A separação desses componentes tem uma consequência importante do ponto de vista defensivo. Quando avaliados individualmente, alguns arquivos podem não apresentar características suficientes para serem classificados imediatamente como maliciosos. O interpretador AutoIt, por exemplo, é uma aplicação legítima. O comportamento ofensivo surge da combinação entre arquivos, sequência de execução e conteúdo carregado posteriormente.

Para manter persistência no equipamento, a campanha cria ainda um arquivo LNK dentro da pasta de inicialização do Windows. Esse atalho executa o script utilizando o interpretador AutoIt sempre que o ambiente é inicializado. Também é criado um diretório no caminho público do sistema que funciona como um marcador de infecção, evitando que determinadas etapas sejam executadas repetidamente.

O AutoIt como intermediário para o payload final

Depois de iniciado, o loader baseado em AutoIt exibe uma janela que procura simular um serviço do Windows. Em seguida, localiza um arquivo identificado pelo sufixo utilizado pelos operadores da campanha e realiza sua descompactação.

O payload resultante é então injetado em um processo legítimo do Windows. A FortiGuard Labs identificou duas possibilidades de destino, RegSvcs.exe e mobsync.exe, sendo o segundo utilizado quando o primeiro não está disponível.

Essa abordagem permite que o código malicioso seja executado no contexto de processos legítimos do sistema, reduzindo a exposição de um executável independente facilmente identificável e exigindo uma análise comportamental mais ampla no endpoint.

O malware também seleciona onde pretende executar

Após a execução, o Casbaneiro descriptografa informações necessárias para suas próximas atividades, incluindo endereços relacionados a criptomoedas, identificadores e URLs utilizadas na exfiltração de dados.

O malware também verifica o idioma padrão do sistema operacional. De acordo com a análise publicada pela FortiGuard Labs, a execução é interrompida quando determinados idiomas são encontrados, incluindo alemão, francês e inglês.

Esse tipo de seleção demonstra que a campanha não procura atingir qualquer máquina que execute o arquivo. Existem diferentes filtros ao longo da cadeia, desde a localização geográfica do acesso inicial até configurações do próprio sistema operacional.

Após essas verificações, o malware gera identificadores baseados em informações da máquina e do usuário. Também coleta endereços de e-mail presentes no ambiente e informações de remetentes e destinatários armazenadas no Microsoft Outlook. Parte desses dados é enviada para servidores externos sem criptografia.

Um arquivo chamado .Outlook também pode ser criado no diretório de dados do usuário para registrar que a etapa relacionada à coleta de informações de e-mail já foi executada.

Um HTTP 403 que não significa necessariamente bloqueio

Um dos comportamentos que mais chamam atenção na análise está relacionado ao uso do código HTTP 403 Forbidden.

Normalmente, ao analisar uma comunicação suspeita, uma resposta HTTP 403 pode indicar que o servidor recusou o acesso. Na campanha do Casbaneiro, entretanto, essa resposta faz parte da própria lógica de operação.

O malware envia informações da vítima codificadas em Base64 para um dos servidores utilizados pela campanha e espera receber uma resposta HTTP 403. Caso o servidor retorne outro código, a requisição pode ser repetida.

Esse comportamento cria um problema para investigações baseadas apenas em uma leitura superficial dos registros de rede. Uma sequência de conexões recebendo respostas 403 pode levar à interpretação de que a infraestrutura do atacante deixou de funcionar ou de que a tentativa de comunicação não teve sucesso, quando, na realidade, o comportamento esperado pelo malware foi concluído.

Após receber a resposta adequada, o Casbaneiro também cria marcadores no sistema de arquivos e no Registro do Windows para evitar a repetição de determinadas atividades.

A comunicação principal depende do comportamento da vítima

Outro elemento relevante é que o Casbaneiro não estabelece necessariamente sua principal comunicação de comando e controle imediatamente após a infecção.

Segundo a pesquisa, essa etapa é acionada quando a vítima acessa, através do navegador, sites bancários previamente definidos pelos operadores da campanha. Quando essa condição é atendida, informações relacionadas ao computador infectado são enviadas para outro servidor e o canal de comando e controle passa a ser utilizado.

Entre as funcionalidades disponíveis para os operadores estão controle de teclado, inserção de dados pela área de transferência, execução de arquivos, execução de comandos e manipulação de janelas falsas relacionadas às instituições financeiras monitoradas pelo malware.

Na prática, um equipamento pode permanecer infectado sem produzir o comportamento de rede mais evidente durante uma análise curta. Caso o ambiente automatizado utilizado para estudar a amostra não acesse um dos bancos monitorados, parte da infraestrutura pode permanecer silenciosa.

Esse modelo de ativação aumenta a importância da observação por períodos maiores e da correlação entre eventos do endpoint, DNS, proxy, firewall, navegação e processos executados na estação.

Dados roubados não precisam seguir para um único servidor

A campanha analisada utiliza diferentes servidores para diferentes funções. Informações relacionadas ao Outlook podem ser enviadas para uma infraestrutura, dados sobre a vítima para outra e a comunicação de comando e controle ocorrer por meio de um terceiro destino.

A distribuição dificulta a interpretação de registros isolados porque não existe necessariamente uma única conexão que represente todo o ataque. Uma URL pode estar relacionada à coleta de informações, enquanto outro endereço permanece sem atividade até que uma condição específica seja atendida.

A FortiGuard Labs também observou pacotes HTTP fora do padrão, incluindo requisições sem o cabeçalho Host e valores incomuns no campo Content-Length. O corpo das requisições podia ser transmitido gradualmente por meio de diversos pacotes pequenos.

Embora esse comportamento possa ter diferentes explicações técnicas, no contexto da campanha ele amplia a dificuldade de inspeção e identificação por mecanismos de rede que dependem de estruturas HTTP convencionais.

O que essa campanha representa para empresas da América Latina

O Casbaneiro demonstra como campanhas de malware podem utilizar controles aparentemente simples para reduzir sua exposição. Localização geográfica, idioma do sistema, arquivos separados, processos legítimos do Windows, respostas HTTP incomuns e ativação condicionada à navegação formam, em conjunto, uma cadeia que pode passar despercebida quando os controles de segurança são analisados isoladamente.

Para uma empresa, o risco também não está limitado ao roubo direto de credenciais bancárias. Um endpoint comprometido pode se tornar uma fonte de coleta de informações, execução remota e acesso a dados disponíveis no contexto do usuário.

Por isso, a análise desse tipo de ameaça precisa combinar diferentes fontes de telemetria. Soluções de proteção de endpoint podem identificar comportamentos relacionados à execução e injeção de processos. Firewalls, proxies e ferramentas de análise de tráfego podem contribuir para identificar destinos incomuns e padrões anormais de comunicação. Controles de e-mail ajudam a reduzir a chegada das mensagens utilizadas como ponto de entrada, enquanto mecanismos de SIEM e serviços de SOC permitem correlacionar eventos que, separadamente, podem parecer pouco relevantes.

Também é importante revisar a capacidade de investigação depois da detecção. Em uma cadeia como essa, bloquear apenas um endereço IP ou remover um arquivo identificado no endpoint pode não ser suficiente para compreender a extensão da ocorrência. A resposta precisa considerar persistência, processos envolvidos, arquivos criados, alterações no Registro, comunicações realizadas e possíveis informações acessadas pelo malware.

Detecção precisa considerar comportamento e contexto

Campanhas como a do Casbaneiro ajudam a explicar por que a defesa contra malware financeiro não pode depender exclusivamente da identificação de assinaturas conhecidas.

O ataque foi estruturado para apresentar comportamentos diferentes conforme localização, idioma, ambiente e ações realizadas pela própria vítima. Além disso, seus componentes são distribuídos entre diferentes etapas e sua infraestrutura de rede foi organizada de maneira que algumas conexões podem parecer malsucedidas ou não relacionadas entre si.

Para organizações que operam na América Latina, esse cenário reforça a necessidade de acompanhar não apenas ameaças globais, mas também campanhas desenvolvidas especificamente para usuários, empresas e instituições financeiras da região.

Na ARX CYBER, a operação de segurança considera a correlação entre diferentes camadas do ambiente para identificar comportamentos que não seriam conclusivos quando observados de forma isolada. E-mail, endpoint, firewall, identidade e eventos de rede precisam compor uma visão comum do incidente para permitir uma resposta mais rápida e reduzir o tempo entre o primeiro comportamento suspeito e a contenção.

A capacidade de detectar uma ameaça em múltiplas etapas depende menos de um único alerta e mais da visibilidade disponível sobre o ambiente. Avaliar quais fontes estão sendo monitoradas, como os eventos são correlacionados e quais ações podem ser tomadas quando uma ameaça é confirmada é um passo importante para aumentar a maturidade da operação de segurança.