BackSwap evolui web-injects para fraude bancária sem injeção direta no navegador

Malware bancário inserido em executáveis legítimos usa código independente de posição, eventos de janela e interação simulada com o navegador para alterar transações e capturar dados.

Componente	BackSwap, malware bancário embutido em executáveis legítimos como 7-Zip, FileZilla, Notepad++, WinGraph e SQLMon.
Vetor	Execução de programas aparentemente legítimos adulterados, nos quais trechos de inicialização do runtime C desviam o fluxo para shellcode independente de posição antes da lógica original do aplicativo.
Impacto	Manipulação de sessões bancárias por web-injects, substituição de IBAN em transações, coleta de credenciais e comunicação de dados entre JavaScript e binário por título de janela, área de transferência ou URL do navegador, conforme a versão.
Prioridade	Caçar binários legítimos com seções alteradas, eventos de janela incomuns, uso anômalo de área de transferência por processos não esperados e interação automatizada com barras de endereço ou ferramentas de desenvolvedor.
Artefatos	Código independente de posição em assembly, resolução dinâmica de APIs via PEB, hashes de funções, recursos .rsrc criptografados por XOR de byte único e payload criptografado embutido em imagem BMP.
Alvos	Amostras iniciais miravam bancos poloneses, com exemplos defangados como ipko[.]pl, 24[.]pl e mbank[.]pl; versões posteriores passaram a focar bancos espanhóis.

Resumo técnico

BackSwap representa uma evolução específica dentro da categoria de malware bancário porque evita uma parte do modelo clássico de injeção direta de código na memória do navegador. Em vez de depender de hooks internos adaptados a cada navegador moderno, o malware se apoia em executáveis legítimos adulterados, shellcode independente de posição e manipulação da interface gráfica para interferir em sessões bancárias. A cadeia observada entre março e novembro de 2018 mostra mudanças frequentes nos web-injects, na forma de armazenamento dos recursos e no canal usado para trocar dados entre o JavaScript executado no navegador e o binário em execução no sistema Windows.

A característica operacional mais importante é a combinação entre simplicidade externa e complexidade interna. O arquivo executado pelo usuário aparenta ser um programa popular, mas trechos específicos do código original foram sobrescritos para redirecionar a execução antes da função principal do aplicativo. Esse redirecionamento leva ao payload do BackSwap, escrito em assembly e preparado para rodar sem depender de endereço fixo em memória. A técnica reduz a necessidade de tocar diretamente estruturas internas do navegador e desloca a atividade para eventos de janela, área de transferência, barra de endereço e recursos do próprio processo adulterado.

A evolução também mostra uma mudança de alvos. As primeiras amostras observadas em meados de março de 2018 tinham foco em bancos poloneses e armazenavam recursos separados para cada instituição. Em agosto de 2018, a operação passou a mirar principalmente bancos espanhóis e consolidou web-injects em um único recurso delimitado por marcadores internos. A partir de setembro e até novembro, as alterações se concentraram menos em novas funções visíveis e mais em camadas de criptografia, junk-code e mudanças nos separadores usados para organizar o JavaScript bancário.

Fluxo técnico

O fluxo começa com um executável legítimo modificado. A adulteração não é tratada como simples empacotamento externo: o payload pode ser inserido em áreas arbitrárias do programa original, substituindo trechos específicos de código. Um dos pontos explorados fica na inicialização do runtime C, antes da chamada normal da função principal. A tabela usada pela rotina __initterm() recebe um ponteiro adicional, fazendo com que a inicialização invoque o código malicioso antes de qualquer funcionalidade legítima esperada pelo usuário. Em algumas amostras, o programa original sequer chega a executar sua lógica real.

Depois do desvio, o BackSwap prepara o ambiente para o payload final. Dependendo da versão, ele aloca memória dedicada, cria uma nova thread ou apenas redireciona o ponteiro de instrução para o código seguinte. Como o payload é independente de posição, ele usa endereçamento relativo, saltos e chamadas indiretas, evitando dependência de base fixa. Esse desenho dificulta análise estática e exige que ferramentas de engenharia reversa tratem corretamente strings embutidas no fluxo de instruções. O malware usa strings inline após instruções CALL, de forma que o endereço empilhado aponte para o texto necessário como argumento de função.

Para resolver funções do Windows, o BackSwap não depende da tabela de importação original. O código percorre o PEB para localizar módulos carregados, recupera o endereço de kernel32.dll, encontra LoadLibraryA por análise da estrutura PE e carrega bibliotecas adicionais. Em seguida, monta uma tabela própria de funções em tempo de execução por comparação entre hashes de nomes exportados e hashes já embutidos no payload. Essa estratégia permite que o binário adulterado apresente menos sinais óbvios na tabela de importação e transfere parte relevante da lógica para a fase de execução.

A etapa bancária usa hooks de eventos de janela criados por SetWinEventHook. Eventos como foco, seleção, mudança de estado, alteração de nome, localização, descrição e valor são monitorados para observar a interação do usuário com aplicativos de janela. Quando a rotina intercepta atividade compatível, ela procura uma URL iniciada por https nos dados coletados. Nas versões mais recentes descritas, ao encontrar uma URL, o malware descriptografa recursos na seção .rsrc, extrai web-injects e compara o destino visitado com bancos visados pela amostra.

Evolução das versões

As primeiras amostras, vistas em março de 2018, eram menos protegidas contra análise e expunham strings com bancos e navegadores visados. Cada amostra costumava mirar de uma a três instituições, e alguns exemplos de domínios bancários poloneses aparecem como ipko[.]pl, 24[.]pl e mbank[.]pl. O web-inject tinha uma lógica direta: ao identificar uma tentativa de transação, o código JavaScript substituía o IBAN de destino por um valor controlado pelos operadores. Os recursos eram protegidos por XOR de byte único com chave 0x9, uma proteção fraca do ponto de vista criptográfico, mas suficiente para remover texto claro de inspeções superficiais.

Em abril de 2018, o número de bancos por amostra aumentou, com alguns binários carregando até seis recursos. A comunicação entre web-inject e payload passou a explorar o título da janela do navegador, permitindo que dados preenchidos no site fossem transferidos para o binário. Ao mesmo tempo, um thread em segundo plano armazenava informações coletadas em arquivo local antes do envio ao servidor de comando e controle. Ainda em abril, o malware começou a criar campos falsos no DOM das páginas bancárias, ocultando campos reais e mantendo o IBAN do operador no elemento legítimo submetido ao site.

No fim de abril e durante maio, a família alterou chaves de XOR e passou a incorporar o IBAN diretamente no JavaScript dos web-injects. Algumas amostras adicionaram nomes associados a possíveis participantes da operação financeira. Em maio também apareceu a função copyStringToClipboard, usada pelo JavaScript para colocar dados na área de transferência, de onde o componente nativo podia ler e processar as informações. No mesmo período, a telemetria de infecções passou a envolver requisições HTTP para yadro[.]ru, um serviço legítimo de contagem de acessos usado como mecanismo indireto de medição pelos operadores.

Junho de 2018 introduziu a técnica de colocar payload criptografado dentro de uma imagem BMP. O cabeçalho BMP começa por bytes que também podem ser interpretados como instruções válidas em x86; após instruções inofensivas, a execução salta para a rotina de descriptografia do código independente de posição. As imagens usadas evoluíram de conteúdo abstrato para imagens reconhecíveis. Em agosto, após uma pausa de atividade em julho, as amostras passaram a focar bancos espanhóis, consolidaram web-injects em recurso único e usaram separadores como [start:] e [fartu:]. Entre setembro e novembro surgiram novos delimitadores, incluindo [mumuo:], [pghtyq], [tempo:], [code:], [joke:] e [asap:], além de mais camadas de criptografia e junk-code.

Superfície afetada

A superfície principal é o endpoint Windows que executa programas legítimos adulterados. O risco não depende apenas da instalação de um aplicativo suspeito; ele aparece quando um binário de aparência confiável contém código implantado no fluxo de inicialização. Isso torna relevante comparar hashes, assinaturas, metadados e integridade de programas populares distribuídos fora de canais confiáveis. 7-Zip, FileZilla e Notepad++ aparecem como exemplos de software usado para ocultar o payload, mas a técnica descrita não está limitada a esses nomes se o operador conseguir adulterar outro executável e induzir sua execução.

Navegadores são afetados como alvo funcional da fraude, mas não pelo mesmo caminho típico de injeção em memória usado por outras famílias bancárias. O BackSwap interage com a janela do navegador, abre ou foca componentes como ferramentas de desenvolvedor ou barra de endereço e cola JavaScript malicioso simulando teclas. Essa escolha cria ruído parecido com ação humana e pode escapar de controles que procuram apenas injeção de DLL, manipulação direta de memória do navegador ou hooks em funções de rede. A defesa precisa correlacionar comportamento do processo adulterado, foco de janelas, área de transferência e alterações de DOM durante sessões bancárias.

A superfície bancária muda conforme a campanha. No início, os bancos poloneses eram predominantes; depois, os espanhóis passaram a concentrar a operação. Os web-injects são específicos por instituição, porque precisam reconhecer estrutura de página, campos de transação e fluxo de autenticação. Portanto, a presença do BackSwap em um endpoint não implica automaticamente manipulação de qualquer banco, mas indica capacidade de alterar transações quando o usuário acessa um alvo suportado pela amostra em execução.

• Executáveis populares adulterados com trechos de inicialização modificados antes da função principal.
• Processos que usam SetWinEventHook para observar alterações de foco, seleção, nome, valor e localização em janelas.
• Recursos .rsrc criptografados contendo web-injects bancários e delimitadores internos por versão.
• Uso anômalo da área de transferência, título de janela ou URL do navegador para transmitir dados entre JavaScript e código nativo.

Hunting e telemetria

A caça deve começar pela integridade dos binários. Programas amplamente usados, quando obtidos de repositórios não controlados, devem ser comparados com versões conhecidas e assinaturas esperadas. Um binário com tamanho, entropia, seções, recursos ou fluxo de inicialização divergentes merece análise. A presença de código independente de posição inserido em áreas incomuns do executável, strings embutidas entre instruções e resolução dinâmica de APIs via PEB são sinais compatíveis com a técnica descrita. Como o payload é pequeno em relação ao programa hospedeiro, varreduras parciais ou baseadas apenas em cabeçalhos podem deixar artefatos fora do recorte analisado.

No endpoint, é importante observar processos de aplicativos comuns criando hooks globais de eventos de janela, interagindo com o navegador sem relação funcional legítima, alterando a área de transferência em períodos de acesso bancário ou disparando eventos de foco e seleção de forma repetitiva. A técnica de colar JavaScript na barra de endereço ou em ferramentas de desenvolvedor deve gerar uma sequência rara para aplicativos como compactadores, editores de texto e clientes FTP. A telemetria de EDR pode correlacionar mudança de foco, chamadas a APIs de janela, leitura de clipboard e requisições HTTP posteriores feitas por processo que não deveria atuar como componente bancário.

A rede deve ser tratada com cuidado porque parte do tráfego pode envolver serviços legítimos usados para telemetria ou infraestrutura externa. O domínio defangado yadro[.]ru aparece como mecanismo de contagem de vítimas em determinada fase, mas não deve ser interpretado isoladamente como prova de comprometimento. A investigação deve combinar o acesso a esse tipo de serviço com execução de binário adulterado, recursos criptografados, comportamento de clipboard e visitas a bancos suportados pela amostra. Quando houver referência a servidores externos para carregar JavaScript, a defesa deve procurar padrões de importação remota em web-injects extraídos, sem acessar links ativos em ambiente de produção.

• Divergência de hash, assinatura ou estrutura PE em executáveis populares instalados no endpoint.
• Uso de SetWinEventHook por processos que não têm motivo operacional para monitorar eventos de janelas do sistema.
• Leitura e escrita de área de transferência durante sessões bancárias, especialmente por processos não relacionados ao navegador.
• Recursos .rsrc com conteúdo cifrado por XOR simples, delimitadores como [start:], [fartu:], [tempo:], [code:], [joke:] ou [asap:].
• JavaScript bancário armazenado localmente no recurso do binário ou encapsulado para carregar código de terceiros.

Mitigação

A resposta deve priorizar contenção do endpoint e validação de integridade dos aplicativos afetados. Máquinas com suspeita de BackSwap devem ser isoladas de sessões bancárias e analisadas com foco em binários recentemente baixados, instaladores fora de repositórios oficiais e executáveis populares com alteração de assinatura. A remoção deve incluir o binário adulterado, artefatos locais de log criados por versões que armazenam dados em disco e qualquer persistência associada que tenha sido identificada na investigação. Como a descrição não estabelece um mecanismo único de persistência, a defesa não deve assumir apenas um local de inicialização.

Para reduzir exposição, organizações devem restringir execução de binários não autorizados, aplicar allowlisting, reforçar reputação de arquivos e controlar fontes de instalação de ferramentas comuns. Navegadores usados para operações financeiras devem ter monitoramento de alterações de DOM, abusos de área de transferência e interações automatizadas quando possível. Controles que procuram apenas injeção em memória no navegador não cobrem o desenho completo do BackSwap; é necessário incluir sinais de automação de interface e manipulação de janelas. Usuários que operam pagamentos devem ser orientados a validar beneficiário, IBAN e resumo da transação fora da página editável antes da confirmação.

Em ambientes corporativos, a mitigação também exige rotação de credenciais bancárias ou revisão de transações quando houver evidência de sessão manipulada. O risco confirmado é fraude de transação e coleta de dados bancários, não uma capacidade genérica de movimentação lateral. Portanto, a resposta deve ser proporcional: preservar imagem forense quando necessário, extrair web-injects para entender quais instituições foram visadas, verificar se houve acesso aos bancos cobertos pela amostra e revisar logs financeiros no período em que o binário adulterado esteve presente.

• Isolar endpoints suspeitos antes de novas sessões bancárias e preservar evidências do binário adulterado.
• Comparar executáveis populares com versões legítimas, assinaturas esperadas e hashes conhecidos internamente.
• Bloquear execução de software obtido fora de canais aprovados e aplicar allowlisting para ferramentas comuns.
• Monitorar clipboard, hooks de janela e automação de foco quando ocorrer acesso a portais bancários.
• Revisar transações e credenciais apenas quando a telemetria indicar que o usuário acessou banco suportado pela amostra.