RedHook usa Wireless ADB e transforma o próprio Android em cliente contra o dono
Análise da Group-IB publicada em 12 de julho detalha nova variante do trojan bancário. Malware ativa Debugging via Acessibilidade e obtém shell sem cabo. Vietnã e Indonésia são o alvo atual.
A Group-IB publicou em 12 de julho a análise da nova variante do trojan bancário RedHook, e a novidade técnica marca uma inflexão para times de fraude em bancos. A família de malware passou a abusar do Wireless ADB nativo do Android para obter acesso a nível de shell sem depender de nenhum computador conectado ao aparelho. Até a versão anterior, catalogada em 2025, esse tipo de escalada dependia de o atacante ter meios físicos para plugar o dispositivo. Agora o próprio celular executa o papel do cliente ADB contra si mesmo.
O truque
O caminho da infecção começa por engenharia social. Operadores do RedHook se passam por servidores de órgãos públicos ou por atendimento de bancos em ligações e em mensagens pelo Zalo, principal app de mensagens do Vietnã, e conduzem a vítima até sites falsos estilizados como se fossem a Google Play Store, de onde o APK malicioso é baixado por sideload. Depois de instalado, o app pede permissão de Acessibilidade, aquele conjunto de APIs pensado para leitores de tela e usuários com deficiência visual, e que dá ao software controle amplo sobre o que aparece e o que é tocado.
Com essa permissão, RedHook manipula Settings, ativa as Opções de Desenvolvedor, liga o Wireless Debugging e captura o código de pareamento exibido na tela. A partir daí conecta o serviço ADB pelo próprio loopback do dispositivo, 127.0.0.1, e obtém shell. O ADB com shell é acesso quase raiz para fins práticos: permite instalar aplicativos sem consentimento adicional, encerrar processos que estariam protegidos, injetar acesso e ler áreas de armazenamento fora do alcance de apps comuns. A Group-IB registra que o RedHook mantém as capacidades clássicas de RAT que já tinha em 2025, incluindo streaming de tela, interceptação de teclas digitadas, automação de UI e roubo de credenciais, agora reforçadas por persistência via foreground activity spoofing e reprodução silenciosa de mídia para evitar ser suspenso pelo sistema.
O ângulo bancário
A telemetria coletada pela Group-IB no momento da análise contabilizou 570 IDs de usuário reportando ao servidor de comando, o que indica mais de 500 dispositivos ativamente infectados. É volume modesto para padrões de campanha global, mas suficiente para uma operação de fraude regional, e a distribuição atual mira preferencialmente aplicativos de bancos e órgãos fiscais no Vietnã e na Indonésia, dois mercados em que a adoção de mobile banking cresceu mais rápido que a maturidade das áreas de fraude corporativas.
Para o banco no meio do golpe, o problema não é ter o próprio app comprometido, e sim ver a credencial do cliente flanquear a autenticação multifator via captura de OTP na tela e automação de fluxo dentro da UI oficial. É o padrão que analistas de fraude chamam de on-device compromise: o pedido de transferência sai autenticado do dispositivo legítimo do cliente, do IP legítimo e com o token gerado pelo próprio app. Nenhum dos sinais tradicionais de anomalia detecta a operação como maliciosa em tempo real, porque, tecnicamente, ela não é.
O que preocupa fora do Sudeste Asiático
O padrão do RedHook interessa a áreas de segurança de instituições globais por dois motivos. Primeiro, a técnica não é geograficamente exclusiva. Wireless Debugging é recurso nativo de Android desde a versão 11 e está disponível em qualquer dispositivo do mundo com essa base, o que significa que nada impede a recompilação da mesma família para se passar por bancos brasileiros, europeus ou africanos assim que o retorno financeiro compense o ajuste. Segundo, o vetor via Acessibilidade continua sendo o gargalo. O Google endureceu a política em versões recentes exigindo justificativa para uso de Accessibility Services por apps distribuídos na Play Store, mas o RedHook opera fora da loja, por sideload, o que anula a proteção de forma limpa.
O que times de fraude bancária podem fazer no curto prazo é limitado pelo fato de o dono do dispositivo ter dado consentimento a cada passo. Alertas em produto quando Wireless Debugging é ativado, deteção server-side de padrão de digitação automatizada em fluxos sensíveis, revalidação fora de banda em transações de alto valor e comunicação preventiva a clientes contra apps instalados por sideload continuam sendo o kit básico. O que essa variante realmente muda é o custo do primeiro estágio para o atacante: sem depender de acesso físico ou de CVE do fabricante, uma engenharia social bem executada agora abre shell num aparelho comum e transforma a autenticação multifator em teatro. Bancos brasileiros que dependem fortemente de OTP em app têm interesse direto em olhar essa cadeia antes de a mesma técnica chegar traduzida.