Campanha ativa do trojan bancário gera arquivos únicos por vítima, usa geofencing, LNK, ISO, ZIP, SMB e MSBuild, e mira credenciais bancárias e códigos de autenticação.
| Componente | Trojan bancário BBTok, loaders Trammy, Gammy, Brammy e Kammy, servidor XAMPP com descarga.php, ps_gen.ps1 e banco links.sqlite. |
| Vetor | Links de phishing levam ao download de arquivos ZIP ou ISO com LNK; o servidor adapta o payload ao país, à versão do Windows e ao nome de isca recebido na requisição. |
| Impacto | Execução do BBTok em máquinas de vítimas no Brasil e no México, com interfaces falsas para mais de 40 bancos, coleta induzida de código de autenticação e possível captura de número de cartão. |
| Prioridade | Bloquear a cadeia de entrega por LNK, ISO e ZIP, monitorar LOLBins usados no fluxo, revisar acessos SMB incomuns e reforçar detecção de janelas bancárias falsas e loaders Delphi. |
| Artefatos | descarga.php, ps_gen.ps1, links.sqlite, rpp.dll, TFRMBG, arquivos LNK, imagens ISO, arquivos ZIP, DOCX, JS e XLL citados como tipos mantidos no ambiente do operador. |
| Alvos | Usuários no Brasil e no México, com referências a bancos como Citibank, Scotibank, Banco Itaú, HSBC e BBVA; o BBVA aparece como alvo padrão da interface falsa. |
O BBTok permanece ativo como trojan bancário voltado à América Latina, com foco confirmado em vítimas no Brasil e no México. A campanha recente observada não se limita ao envio direto de anexos: a cadeia passa por links de phishing que acionam um servidor de payloads capaz de gerar arquivos sob demanda. A lógica do servidor usa parâmetros da requisição para selecionar formato, conteúdo e caminho de execução, criando um artefato específico para cada clique. Esse desenho reduz a repetição de amostras, dificulta correlação simples por hash e permite que o operador varie a entrega conforme sistema operacional, país e nome do arquivo de isca.
A operação combina engenharia social, geofencing e uso de binários legítimos do Windows para chegar ao BBTok. O malware final mantém capacidades clássicas de trojan bancário, incluindo simulação de telas de instituições financeiras, controle de teclado e mouse, manipulação de área de transferência, enumeração e encerramento de processos. O objetivo bancário descrito é induzir a vítima a inserir dados sensíveis em interfaces falsas, especialmente códigos de autenticação de duas etapas usados em contas bancárias e, em alguns casos, número de cartão de pagamento. A execução de funções bancárias não ocorre de forma automática em toda máquina infectada; ela depende de comandos diretos vindos do servidor de comando e controle.
A cadeia começa quando a vítima acessa um link malicioso provavelmente distribuído por phishing. O servidor identifica informações da requisição, incluindo indicação de país e user agent, e usa esses dados para determinar a versão do Windows e o tipo de arquivo a entregar. Em máquinas que passam pelos filtros, o download pode ser um ZIP ou uma imagem ISO. Dentro desses arquivos há um LNK que inicia o encadeamento, enquanto um documento de isca é aberto para reduzir a percepção de anomalia pelo usuário. O servidor responsável por essa entrega é descrito como baseado em XAMPP e contém componentes como descarga.php, que concentra a lógica principal, e ps_gen.ps1, que gera os arquivos de payload.
Há diferenças relevantes entre os caminhos para Windows 7 e Windows 10. No fluxo associado ao Windows 7, o arquivo ZIP contém um LNK que aciona um loader DLL com nome seguindo o padrão *ammy.dll, levando ao download, extração e execução do BBTok. No fluxo associado ao Windows 10, a imagem ISO contém LNK, arquivo de isca e uma cópia renomeada de comando operacional omitido; a cadeia usa esse executável renomeado, MSBuild e obtenção de arquivos por SMB. Essa combinação de LOLBins, alteração de nomes e busca de conteúdo remoto por compartilhamento de rede é parte do motivo técnico para baixa taxa de detecção citada no contexto.
O script ps_gen.ps1 seleciona parâmetros do arquivo gerado com base na versão do sistema operacional e no código de país. O material indica uso de ofuscação por uma função chamada Add-PoshObfuscation, com origem associada a código compartilhado em fórum público defangado como hackforums[.]net. Versões antigas do mesmo script e do PHP mostram que a operação passou por iterações desde pelo menos julho de 2022, com seções comentadas e fluxos não ativos que sugerem experimentação contínua com novas iscas, extensões e métodos de execução.
A superfície exposta é composta por usuários finais que recebem links de phishing e utilizam Windows em ambientes onde arquivos ISO, ZIP e LNK podem ser abertos. A campanha usa geofencing em camadas para manter foco em Brasil e México, o que reduz ruído operacional e pode atrasar análise em ambientes fora desses países. A presença de lógica para Windows 7 e Windows 10 mostra que o operador mantém cadeias diferentes para compatibilidade e evasão, em vez de depender de um único artefato. Ambientes corporativos que permitem montagem de ISO, execução de atalhos vindos da internet e acesso SMB sem restrição ficam mais expostos à cadeia descrita.
No endpoint, o BBTok procura indícios de relacionamento da vítima com bancos brasileiros e mexicanos examinando janelas abertas e títulos de abas do navegador em busca de nomes de instituições. O código referencia mais de 40 bancos e inclui formas visuais criadas em Delphi com Visual Component Library. A forma TFRMBG aparece associada à interface padrão que imita o BBVA. O malware também busca referências relacionadas a Bitcoin, incluindo cadeias como bitcoin, Electrum e binance, o que amplia o interesse do operador para além de portais bancários tradicionais. Componentes como extensão maliciosa de navegador e DLL rpp.dll aparecem como capacidades previstas ou associadas, embora não estivessem disponíveis durante a análise descrita.
O banco links.sqlite encontrado no lado do servidor registrava mais de 150 entradas únicas de acesso à aplicação maliciosa. A coluna chave continha endereços IP de vítimas, enquanto assunto estava vazia. Os nomes de campos e comentários em português no código interno, combinados com a seleção de alvos no Brasil e México, sustentam uma inferência de alta probabilidade de participação de operadores brasileiros, embora a atribuição permaneça limitada aos artefatos técnicos observados.
- Usuários no Brasil e no México que acessam links de phishing e abrem ZIP, ISO ou LNK entregues pelo servidor.
- Endpoints Windows onde LOLBins como
comando operacional omitido,comando operacional omitidoeMSBuildpodem ser usados por arquivos vindos da internet. - Ambientes bancários e usuários com sessões ou abas relacionadas a bancos brasileiros, mexicanos e serviços de criptoativos.
A defesa deve correlacionar eventos de navegação, download e execução local. Um ponto forte de hunting é o encadeamento entre clique em link externo, criação de arquivo ZIP ou ISO, abertura de LNK e início de processo filho usando binários do Windows. A presença de uma cópia renomeada de comando operacional omitido dentro de uma imagem ISO é um sinal anômalo forte, principalmente quando seguida por execução indireta via LNK. Outro pivô é a combinação de MSBuild com obtenção de conteúdo por SMB fora de fluxos administrativos conhecidos. Mesmo sem publicar comandos ou payloads, a sequência comportamental é suficientemente específica para orientar detecção por EDR, proxy, gateway de e-mail e logs de arquivos.
No endpoint, vale procurar loaders DLL com nomes próximos a Trammy, Gammy, Brammy e Kammy, especialmente quando associados a processos iniciados por atalhos recém-extraídos. O BBTok é escrito em Delphi e usa VCL para construir formulários bancários falsos, portanto janelas inesperadas que imitam bancos, aparecem sobre navegadores ou solicitam códigos de autenticação podem ser tratadas como incidente de fraude em andamento. A manipulação de área de transferência, controle remoto de teclado e mouse, encerramento de processos e instalação de extensão de navegador são comportamentos defensivamente relevantes quando aparecem perto de navegação bancária.
Na rede, a caça deve observar downloads de ISO e ZIP originados de links recebidos por e-mail, conexões SMB para destinos incomuns após abertura de arquivo de isca e comunicação posterior com infraestrutura de comando e controle. Indicadores pontuais devem ser tratados com cautela porque o servidor gera payloads únicos por vítima, o que reduz valor de hashes isolados. O valor maior está em classes de artefato, ordem de eventos, uso anômalo de LOLBins, geofencing e mudanças no comportamento de processos após interação com o link.
- Arquivo LNK executado a partir de ISO ou ZIP baixado logo após clique em link externo recebido por e-mail.
MSBuildiniciado em contexto de usuário comum e associado a busca de arquivos por SMB.- Cópia renomeada de
comando operacional omitidoembutida em ISO ou diretório temporário relacionado a arquivo de isca. - DLLs com nomes próximos a
Trammy,Gammy,BrammyouKammycarregadas após abertura de LNK. - Janelas falsas de bancos solicitando código de autenticação, token ou número de cartão fora do fluxo legítimo do navegador.
A resposta deve começar pela redução da execução inicial. Gateways de e-mail e proxy precisam tratar links que entregam ISO, ZIP e LNK como alto risco quando associados a temas bancários ou iscas regionais. Em estáções de trabalho, controles de aplicação devem restringir abertura de LNK a partir de arquivos baixados, montagem automática de ISO e execução de binários renomeados em diretórios de usuário. A cadeia descrita depende de confiança excessiva em artefatos aparentemente comuns; bloquear a transição entre arquivo baixado, atalho e LOLBin reduz a superfície sem depender de um hash específico.
Para contenção, endpoints com sinais compatíveis devem ser isolados antes de qualquer interação bancária adicional. A investigação deve reconstruir a linha do tempo desde o clique, identificar arquivos baixados, atalhos, imagens montadas, DLLs carregadas, processos filhos e conexões SMB. Como o BBTok pode receber comandos sob demanda do C2, a ausência de ação bancária imediata não elimina risco. Contas bancárias usadas no endpoint afetado devem passar por validação antifraude pelos canais legítimos da instituição, e códigos de autenticação digitados em telas suspeitas devem ser tratados como comprometidos para fins de resposta.
No médio prazo, organizações com usuários no Brasil e no México devem reforçar políticas contra arquivos ISO e LNK vindos da internet, revisar regras de saída SMB, monitorar MSBuild fora de pipelines de desenvolvimento e treinar equipes de suporte para reconhecer telas bancárias falsas que pedem token ou cartão. Para equipes de DFIR, o foco deve ser preservar artefatos de usuário, eventos de processo, histórico de navegador e registros de rede. Para equipes de detecção, a prioridade é modelar a cadeia comportamental inteira: phishing com link, geração dinâmica de payload, LNK, LOLBins, loader Delphi, interface falsa e comunicação de comando e controle.
- Restringir execução de LNK, ISO e ZIP provenientes da internet em estáções de usuário.
- Criar alertas para
MSBuild,comando operacional omitidoecomando operacional omitidorenomeado quando iniciados por arquivos de isca ou atalhos baixados. - Bloquear ou justificar tráfego SMB de saída que não faça parte de fluxos corporativos aprovados.
- Investigar qualquer solicitação inesperada de token bancário, código 2FA ou número de cartão exibida fora do site legítimo da instituição.
- Correlacionar eventos de proxy, e-mail, EDR e identidade para reconstruir a cadeia desde o clique até a possível execução do BBTok.
0 Comentários