Campanha avaliada como de origem chinesa combina smishing, malvertising, abuso de Accessibility e túnel reverso FRP para manter persistência fora do ciclo de vida do aplicativo, com uso de IA generativa para navegação autônoma na tela.
| Componente | Malware Android RatHat, composto por aplicativo dropper, agente nativo em Go disfarçado de biblioteca ("liblocal-service.so") e cliente de proxy reverso FRP |
| Vetor | Smishing direcionado e malvertising conduzindo a portais de download de terceiros que distribuem APKs maliciosos; pipeline de infecção em múltiplas etapas com abuso de Accessibility e auto-pareamento local do ADB |
| Impacto | Execução com privilégios de shell fora do sandbox Android, persistência sobrevivente à desinstalação, captura de tela, interceptação de SMS, keylogger de hardware, coleta de credenciais, PIN/padrão/senha, arquivos, URLs digitadas e reinstalação remota do malware |
| Prioridade | Bloquear instalação de APKs fora de lojas oficiais, auditar permissões de Accessibility e depuração sem fio habilitada, e monitorar túneis reversos FRP e processos nativos executando como shell |
| Artefatos | Quatro técnicas antianálise: container tampering com manipulação de estrutura ZIP, manifest bomb com chunk 0x9999 em AndroidManifest.xml, DEX bytecode poisoning com element_width inválido e dupla criptografia de strings via StringCrypto: Base64 |
Uma nova família de malware Android denominada RatHat foi identificada por pesquisadores de segurança móvel, com avaliação de que a operação está ligada a atores de ameaça baseados na China. O diferencial técnico da amostra está na combinação de abuso do serviço de Accessibility com auto-pareamento autônomo do Android Debug Bridge (ADB) em modo local, o que permite ao código malicioso romper o sandbox padrão do sistema operacional e executar daemons nativos independentes com privilégios de shell, fora do ciclo de vida gerenciado pelo Android para aplicativos.
A distribuição ocorre principalmente por smishing direcionado e campanhas de malvertising que conduzem as vítimas a portais de download de terceiros que se passam por lojas legítimas, além de fóruns que induzem a instalação de APKs contaminados. Esses pacotes atuam como dropper do payload principal e incorporam múltiplas camadas de verificações antianálise e antidepuração para dificultar a detecção em pipelines automatizados de sandbox, o que explica parte da capacidade de evasão observada na campanha.
Após a instalação, o APK dropper solicita permissões críticas, em especial o acesso aos serviços de Accessibility. Com esse privilégio, o malware manipula a interface do sistema para desbloquear as Opções do Desenvolvedor, habilitar a Depuração sem Fio (Wireless Debugging) e extrair o código de pareamento ADB de seis dígitos exibido ao usuário. Esse auto-pareamento local concede ao agente um canal ADB que não depende do aplicativo original, viabilizando execução de comandos com privilégios de shell, isenção de gerenciamento de energia e instalação de componentes que escapam do sandbox.
A arquitetura é composta por três elementos: o aplicativo Android malicioso, um agente escrito em Go e um cliente de proxy reverso FRP. O agente Go se disfarça de biblioteca nativa com o nome "liblocal-service.so" e usa o acesso shell obtido via daemon ADB local para executar comandos e consolidar persistência. O cliente FRP, por sua vez, recupera a configuração do túnel diretamente do servidor de comando e controle (C2) e estabelece um túnel reverso persistente até o operador, que passa a ter acesso direto ao daemon ADB do dispositivo — um canal de propósito geral, independente do conjunto de funcionalidades do próprio malware.
Um aspecto notável é o uso de um assistente de IA generativa de grande popularidade como componente de decisão em tempo real. O malware serializa a árvore de Accessibility do dispositivo para XML e consulta o modelo para ações não maliciosas em si, porém operacionais: resolver as coordenadas centrais de um alvo nomeado na tela em JSON para direcionar cliques sintéticos, extrair o texto real exibido de um elemento a partir do XML e emitir comandos automáticos de navegação, como rolar para baixo. Esse laço de decisão com GenAI permite ao operador interagir com a interface de forma autônoma sem depender de coordenadas fixas.
- Dropper APK com antidepuração conduz à obtenção de Accessibility
- Accessibility é usada para habilitar Depuração sem Fio e extrair código de pareamento ADB
- Daemon ADB local executa agente Go ("liblocal-service.so") com privilégios de shell
- Cliente FRP cria túnel reverso persistente para o C2
- Reinstalação remota é possível mesmo após desinstalação do aplicativo original
O alvo direto são dispositivos Android cujos usuários instalam aplicativos fora da loja oficial, induzidos por mensagens de SMS fraudulentas, anúncios maliciosos ou fóruns de terceiros. A superfície de coleta é ampla: o malware dispõe de sobreposições (overlays) exibidas sobre aplicativos específicos para colher credenciais, gravação de tela via API MediaProjection do Android, interceptação de mensagens SMS e substituição de tentativas de instalação legítimas por uma sobreposição falsa que imita uma falha da Google Play Store, induzindo o usuário a instalar pacotes adicionais.
Os comandos emitidos pelo C2 permitem coletar mensagens SMS, credenciais, arquivos, PIN, padrão ou senha de bloqueio de tela, capturas de tela, digitação de teclado — incluindo URLs digitadas na barra de endereço de navegadores — e a lista de aplicativos instalados. Há ainda um keylogger em nível de hardware, executado pelo agente Go, capaz de registrar toques físicos na tela, ampliando a captação para além do contexto de aplicativos individuais.
- Usuários Android que instalam APKs de fontes não oficiais
- Credenciais de aplicativos via overlays e keylogger de hardware
- PIN, padrão e senha de bloqueio do dispositivo
- SMS interceptados e capturas de tela via MediaProjection
- URLs digitadas em navegadores e inventário de aplicativos instalados
Para equipes de segurança corporativa, os sinais mais distintivos estão na combinação de permissões e eventos de sistema raramente legítimos em conjunto: habilitação de Opções do Desenvolvedor e Depuração sem Fio imediatamente após concessão de Accessibility a um aplicativo de origem externa, extração de código de pareamento ADB e presença de processos nativos executando como usuário shell. O túnel reverso FRP gera tráfego de saída persistente para infraestrutura do operador, um indicador de rede relevante para monitoramento em dispositivos gerenciados.
No plano de engenharia reversa e análise automatizada, as quatro técnicas antianálise documentadas servem como pistas de triagem: manipulação de contêiner ZIP com arquivos declarados como diretórios ou com bit de criptografia ativado, chunk 0x9999 não documentado em AndroidManifest.xml que derruba pipelines automatizados, pseudo-instruções DEX com atributo element_width inválido que quebram desassembladores e criptografia dupla de strings via esquema StringCrypto com Base64. Ferramentas de análise que dependem de libziparchive ou desmontadores padrão podem falhar silenciosamente diante dessas amostras.
- Concessão de Accessibility seguida de habilitação de Depuração sem Fio no mesmo dispositivo
- Processo nativo rodando como shell com nome de biblioteca ("liblocal-service.so")
- Conexões de saída persistentes compatíveis com túnel reverso FRP para C2
- Falhas anômalas de desmontagem em APKs suspeitos (manifest bomb, DEX com element_width inválido)
- Sobreposição que simula falha de instalação da Google Play Store
A resposta prioritária para ambientes corporativos é restringir a instalação de aplicativos de fontes desconhecidas por política de dispositivo, auditar quais aplicativos detêm permissão de Accessibility e investigar imediatamente qualquer dispositivo com Depuração sem Fio habilitada sem justificativa. Como a persistência sobrevive à desinstalação do aplicativo visível, remover o APK não encerra o comprometimento: é necessário desativar a depuração, revogar pareamentos ADB, inspecionar processos em execução como shell e, em casos confirmados, considerar restauração completa do dispositivo.
A investigação também destaca por que controles móveis baseados em assinatura são insuficientes diante de arquiteturas multiestágio com daemons fora do ciclo de vida do aplicativo e laços de decisão com IA generativa em tempo real. Defesas comportamentais, monitoramento de permissões sensíveis e visibilidade de tráfego de saída assumem papel central, complementadas por educação de usuários contra smishing e portais de download enganosos promovidos por malvertising.
- Bloquear instalação de APKs fora de lojas oficiais por política de MDM
- Auditar e restringir permissões de Accessibility por dispositivo
- Investigar Depuração sem Fio e pareamentos ADB sem justificativa
- Revogar pareamentos ADB e inspecionar processos shell em caso de comprometimento confirmado
- Monitorar tráfego de saída persistente compatível com túneis FRP
0 Comentários