Um novo trojan bancário para Android identificado pela ThreatFabric não se limita a sobrepor telas enganosas sobre o aplicativo do banco: o Hirudo desinstala o app legítimo e instala uma cópia adulterada que desliga as próprias verificações de segurança do banco de dentro do aplicativo. Já existem substitutos prontos para oito apps de sete bancos da Indonésia, e rotas de download seguiam ativas em outubro de 2026. Para equipes de segurança de instituições financeiras e times que gerenciam frotas de celulares corporativos, a ação prioritária é tratar assinatura, atestação e veredito de integridade produzidos no aparelho como dados não confiáveis, exigindo validação no servidor.
Dois aplicativos e um golpe
O Hirudo chega ao celular em duas etapas. O primeiro app é uma isca funcional — loja virtual batizada de Shopora, catálogos de dramas curtos como ZoyaTV e KoiShort ou um app de vídeo adulto, o 1V1 X — que carrega o trojan como pacote separado. Conteúdo de verdade é exibido em uma WebView para a vítima não desconfiar; em segundo plano, o dropper coleta dados de rastreamento, baixa a configuração da campanha e confere se o payload já está instalado com o serviço de acessibilidade e o acesso a notificações habilitados. Faltando o payload, o app exibe uma atualização simulada e oferece o APK embutido para instalar o RAT, trojan de acesso remoto.
Um dos droppers analisados vai além e levanta uma VPN do tipo blackhole durante a instalação, cortando o tráfego IPv4 do aparelho enquanto o segundo app entra. Instalado o payload, as superfícies de fraude se abrem: página de checkout falsa renderizada em uma WebView transparente sobre a tela de pedido, com a marca do banco ou da carteira digital informada pela isca e tradução em oito idiomas; captura do padrão e do PIN da tela de bloqueio via acessibilidade; visualização da tela ao vivo por WebRTC; sessões de câmera frontal e traseira; e coleta de SMS com varredura inicial de 90 dias sobre uma lista configurada de remetentes bancários. O PIN digitado no checkout sobe para o backend dos operadores como appPayPwd, e um resultado de pagamento forjado devolve à isca a sensação de compra concluída.
O app do banco, reescrito
O que separa o Hirudo da leva atual de bankers orientados a acessibilidade é o destino final do ataque. O trojan mantém um registro com 42 aplicativos financeiros, mas só oito — de sete bancos da Indonésia — têm substitutos dedicados. Ao detectar pelo serviço de acessibilidade que um desses apps está instalado, o RAT compara o certificado de assinatura com uma referência armazenada, exibe um aviso de atualização, abre o desinstalador do Android sem esperar o toque da vítima e baixa em paralelo a versão preparada para aquele banco.
A cópia preserva o nome do pacote e o número de versão, mas é assinada com uma test key pública do Android — por isso o sistema jamais a aceitaria como atualização sobre o app original, o que obriga o trojan a remover o legítimo antes. A engenharia reversa de um desses builds mostrou que o código do banco fica quase intacto: uma única linha injetada na classe Application carrega, a partir dos assets, um motor de hooks baseado em YAHFA, que substitui métodos Java, e Dobby, que intercepta funções nativas. O motor só se arma quando um arquivo-gatilho gravado pelo RAT existe no aparelho; um app substituído parado revela pouco.
Com o motor ativo dentro do processo do banco, as defesas passam a trabalhar para o atacante. A consulta ao certificado de assinatura devolve o certificado genuíno, escondendo a chave de teste. A lista de serviços de acessibilidade volta vazia, ocultando o serviço controlador. A flag FLAG_SECURE, que bloqueia capturas, é removida, e a tela bancária fica gravável. Certificados de key attestation são re-assinados com um keybox embutido, e as requisições do Play Integrity segem por HTTP sem criptografia até um servidor dos operadores, que devolve o veredito que o app deve aceitar.
Por onde a técnica quebra
O próprio relatório aponta os limites. A substituição exige que o app genuíno seja desinstalado e que o instalador esteja autorizado — dois momentos em que a vítima pode interromper tudo. O keybox usado para re-assinar atestações não pertence aos operadores: é um keybox vazado publicamente, e a ThreatFabric confirmou que ao menos dois certificados dele constam na lista de revogação de atestação do Google, marcados como comprometidos. Um backend que valide a revogação segue capaz de rejeitar as falsificações.
Há também uma diferença de custo para o atacante. Nas técnicas de sobreposição, a vítima digita dentro do app legítimo e o golpe depende de timing e engenharia visual. Na substituição, o operador precisa manter um build por banco, acompanhar atualizações das vítimas e operar a logística de remoção e reinstalação — mais trabalho de engenharia, porém um controle muito mais profundo do ambiente quando o golpe vinga. A troca indica que os bancos endureceram o suficiente para o overlay deixar de compensar em certos fluxos, empurrando o ataque para dentro do próprio aplicativo.
Distribuição com anúncios de verdade
O abastecimento imita o marketing legítimo. As iscas são divulgadas como apps comuns de vídeo, drama e compras, e os APKs são servidos do Amazon CloudFront, com rotas separadas por família de isca e um host dedicado aos oito apps bancários substitutos. Verificações de download do fim de setembro ao início de outubro de 2026 mostravam parte dessas rotas ainda no ar, servindo o mesmo dropper recuperado em agosto. A costura da campanha usa ferramentas comuns de aquisição: OpenInstall para atribuição de instalação e identificadores Meta Pixel compartilhados entre páginas de isca e grupos do backend. Por trás, um painel de processamento de APKs acessível sem login remonta shell e payload em iscas e apps bancários prontos, com buckets e credenciais de armazenamento expostos.
O foco da substituição é a Indonésia, mas o alcance configurado é maior. As listas de credenciais nomeiam alvos na China, Índia, México, Marrocos e Tailândia, e o checkout embutido traz marcas de bancos e carteiras da Malásia. Registros do backend capturados em agosto de 2026 incluíam milhares de entradas de credenciais, histórico de telas de bloqueio e perfis financeiros com renda mensal e score de risco — um back office maduro, com grupos por país, pronto para migrar de região.
Sinais locais que não valem
A conclusão operacional vai além de um malware específico. Quando o atacante pode substituir o aplicativo inteiro, qualquer sinal que o app produza sobre si mesmo — assinatura, lista de acessibilidade, veredito de integridade — passa a ser potencialmente escolhido pelo atacante. A documentação oficial do Android já estabelece o princípio para atestação de chaves: a validação deve ocorrer fora do dispositivo, em servidor confiável, conferindo a lista de revogação de certificados; se a raiz não for a chave de atestação do Google ou houver certificado revogado na cadeia, a atestação não merece confiança plena. O caso Hirudo estende esse princípio a todos os sinais locais.
| Sinal no aparelho | Como o Hirudo o contorna | Decisão no servidor |
|---|---|---|
| Assinatura do aplicativo | Cópia assinada com test key; hook devolve o certificado genuíno | Conferir a assinatura contra a referência do banco em cada atualização de pacote |
| Lista de serviços de acessibilidade | Hook devolve lista vazia | Usar o sinal como dado de risco, não como bloqueio único |
| FLAG_SECURE | Flag removida; tela bancária vira capturável | Detector de reprodução remota e análise de comportamento de sessão |
| Key attestation | Re-assinatura com keybox vazado | Validar cadeia completa e revogação fora do aparelho |
| Veredito do Play Integrity | Requisição repassada por HTTP sem criptografia | Gerar nonce por sessão e ação e validar o veredito no backend |
| Telemetria comportamental | Malware pode suprimir a coleta | Ausência de telemetria esperada é indicador próprio de risco |
Ações priorizadas para o time
P1 — Instituições financeiras: impor verificação de integridade no servidor, vinculada à sessão e à ação protegida, com checagem da lista de revogação de atestação; manter controles de risco transacional no backend no login, na recuperação de credencial, na criação de beneficiário e na aprovação de pagamento — pontos em que um resultado local forjado não substitui a decisão do servidor.
P1 — Times de mobilidade corporativa: monitorar em MDM padrões de desinstalação seguida de instalação de apps bancários e serviços de acessibilidade recém-habilitados; acessibilidade e acesso a notificações são pré-requisitos da operação do Hirudo.
P2 — Sinal local como evidência de apoio: acessibilidade e captura de tela alimentam o score de risco, mas não fecham a decisão sozinhos, já que apps substituídos sabem escondê-los.
P2 — Analítica comportamental: quando o trojan suprime a coleta de comportamento, a ausência do fluxo esperado de telemetria é, ela mesma, um indicador de adulteração.
A campanha confirma que o combate ao fraudador móvel se vence no backend e no processo, não na tela do celular. É a mesma desconfiança metódica do que o próprio ambiente relata que orienta outras análises deste portal, da anatomia do backdoor MLTBackdoor à detecção da infraestrutura de fast flux que esconde a hospedagem criminosa. Times que tratarem assinatura, atestação e integridade como dados a validar — e não como garantias — entram à frente do próximo banco a ser reescrito.