Malware Android RatHat Usa IA, mas a Persistência via ADB É a Ameaça Maior

O malware Android RatHat introduziu controle de tela orientado por IA, mas sua ameaça mais profunda vem de uma arquitetura em três partes criada para sobreviver à remoção. Pesquisadores de segurança divulgaram o malware em 16 de setembro de 2026, após analisarem sua navegação automatizada, roubo de credenciais e mecanismos incomuns de persistência. Segundo relatos, o RatHat combina acesso à Acessibilidade do Android, depuração sem fio local e dois agentes nativos que operam além do aplicativo malicioso principal.

O componente de IA ajuda o RatHat a interpretar interfaces em mudança, em vez de depender inteiramente de instruções fixas. Isso oferece aos operadores uma forma mais flexível de encontrar botões, ler rótulos e navegar em dispositivos comprometidos. No entanto, a IA não cria o acesso inicial. As vítimas ainda precisam instalar um pacote Android fora do Google Play e conceder as permissões necessárias para iniciar o ataque.

A mudança mais relevante é a tentativa do RatHat de preservar o controle depois que o aplicativo visível desaparece. Malwares anteriores assistidos por IA, incluindo o PromptSpy, mostraram como um modelo de linguagem poderia navegar por interfaces específicas de fabricantes. Segundo relatos, o RatHat une essa adaptabilidade ao acesso em nível de shell, sobreposições para roubo de credenciais, keylogging e um túnel de rede persistente.

Malware Android RatHat Combina IA com Controle Persistente

O RatHat transforma um aplicativo Android malicioso no ponto de entrada para um sistema de controle mais amplo, capaz de sobreviver ao próprio aplicativo.

A equipe zLabs da Zimperium divulgou o RatHat após examinar uma cadeia de infecção em múltiplos estágios distribuída por smishing, malvertising, páginas de phishing e fóruns de terceiros. Esses canais direcionam os usuários a arquivos APK maliciosos, que são pacotes de aplicativos Android instalados fora do fluxo usual da Play Store.

O aplicativo malicioso primeiro busca permissões de Acessibilidade. Os serviços de Acessibilidade do Android foram projetados para ajudar pessoas a interagir com dispositivos, mas também podem expor conteúdo de interfaces e permitir entrada automatizada. Operadores de malware frequentemente abusam desses recursos para ler telas, pressionar botões e aprovar ações sensíveis.

Segundo relatos, o RatHat usa esse acesso para ativar as Opções do desenvolvedor e a Depuração sem fio. Em seguida, ele extrai o código de pareamento de seis dígitos necessário para uma conexão local com o Android Debug Bridge. O ADB é a interface legítima de comandos do Android para desenvolvimento, testes e administração de dispositivos.

Segundo a detalhada análise do RatHat, esse processo permite que um agente Go incorporado execute comandos em nível de shell sem um computador externo. O agente é armazenado sob o nome enganoso de biblioteca liblocal-service.so.

Esse agente pode executar comandos, obter isenções de gerenciamento de bateria, coletar entradas e dar suporte à persistência. A Zimperium afirma que ele também pode verificar se o aplicativo malicioso continua instalado e restaurá-lo quando necessário. Da mesma forma, o aplicativo pode restaurar o agente se esse componente desaparecer.

Um segundo componente nativo, chamado libmedia_codec.so, atua como cliente Fast Reverse Proxy. Ele cria um túnel entre serviços locais no telefone e a infraestrutura do invasor. Esse caminho oferece aos operadores acesso que não depende apenas do canal de comando original do aplicativo.

O RatHat pode apresentar sobreposições HTML que imitam aplicativos bancários, de pagamentos e de criptomoedas. Uma sobreposição posiciona uma interface fraudulenta sobre um aplicativo legítimo, incentivando os usuários a inserir credenciais em campos controlados pelo invasor.

Os pesquisadores também encontraram funções para interceptar mensagens SMS, notificações e senhas de uso único. O malware pode registrar alterações de texto, inspecionar barras de endereço de navegadores, capturar telas e coletar listas de aplicativos instalados.

Segundo relatos, seu agente nativo também monitora entradas de toque de baixo nível. Esse recurso pode ajudar a reconstruir toques na tela, PINs, senhas e padrões de desbloqueio a partir dos movimentos do usuário.

Essas capacidades fazem do subsistema de IA apenas uma parte da ameaça. O RatHat usa IA para tornar a navegação mais adaptável, enquanto o acesso ADB e os agentes nativos fornecem a base operacional duradoura.

O Mecanismo de Navegação por IA Elimina uma Etapa Manual Custosa

A IA do RatHat importa porque transforma telas Android em constante mudança em decisões estruturadas de navegação, sem exigir intervenção contínua do operador.

A automação móvel tradicional depende fortemente de layouts previsíveis, identificadores de recursos ou instruções cuidadosamente escritas. Essa abordagem se torna pouco confiável quando fabricantes de dispositivos alteram menus, traduzem rótulos ou redesenham diálogos do sistema.

Uma instrução que funciona em um Google Pixel pode falhar em um dispositivo Samsung, Oppo ou Xiaomi. Até diferenças rotineiras no tamanho da tela, na versão do software e na estrutura de acessibilidade podem quebrar uma sequência fixa.

O RatHat aborda esse problema serializando a árvore de Acessibilidade atual em XML. Essa árvore descreve elementos visíveis da interface, rótulos de texto, tipos de elementos e posições na tela. O malware envia esse retrato estruturado ao que a Zimperium chama de um popular assistente de IA generativa.

Os pesquisadores não identificaram o serviço, o modelo, a conta ou o arranjo de hospedagem. Portanto, o RatHat não deve ser descrito como usuário de nenhum modelo comercial específico sem evidências adicionais.

Segundo relatos, o componente de IA responde a perguntas direcionadas sobre a interface. Ele pode retornar as coordenadas centrais de um elemento nomeado, determinar o texto exibido por um elemento ou fornecer instruções como SCROLL_DOWN.

Esse é um papel limitado, mas útil. O modelo não inventa o ataque de forma independente nem concede novas permissões Android. Ele atua como intérprete da interface entre o objetivo de um operador e a tela atual do dispositivo.

Essa distinção importa porque descrições sensacionalistas de malware autônomo podem obscurecer a mecânica subjacente. O RatHat ainda depende de engenharia social, permissões perigosas, acesso de depuração, código nativo malicioso e infraestrutura controlada pelo invasor.

Ainda assim, sua camada de IA pode reduzir o trabalho. Um operador não precisa observar cada tela infectada nem manter um script de automação separado para cada variante de interface. O modelo pode converter dados de interface em tempo real na próxima ação.

A reportagem sobre navegação por IA da BleepingComputer afirma que essa adaptabilidade distingue o RatHat de automações baseadas inteiramente em scripts estáticos. Ela também oferece aos operadores remotos outra forma de navegar sem interação manual contínua.

A técnica se assemelha à descoberta anterior do PromptSpy. Esse malware enviava dados de estado da tela ao Google Gemini e recebia instruções para fixar-se na interface de aplicativos recentes de um dispositivo. O comportamento de fixação varia entre fabricantes Android, tornando-o um problema adequado para navegação orientada por modelo.

A ESET não havia observado o PromptSpy em sua telemetria quando a pesquisa anterior foi divulgada. Portanto, seu alcance no mundo real permanecia incerto. O RatHat expande o conceito para uma arquitetura mais extensa, embora sua prevalência também permaneça não divulgada.

A progressão é importante. A IA generativa está passando de um auxílio ao desenvolvimento de ataques para o ciclo de execução de alguns malwares. Sua vantagem imediata não é um raciocínio sobre-humano. É a tolerância a variações de interface.

A Persistência, e Não a IA, Cria o Problema de Segurança Mais Difícil

O conflito central do RatHat é entre adaptabilidade e contenção: o aplicativo inicia o comprometimento, enquanto agentes separados tentam preservá-lo.

A sandbox de aplicativos do Android normalmente separa os apps das funções sensíveis do sistema e uns dos outros. Segundo relatos, o RatHat usa o pareamento ADB local para mover parte de sua operação para um contexto em nível de shell, com acesso mais amplo a comandos.

Isso não significa que o malware obtenha privilégios root ilimitados. Acesso de shell e acesso root são diferentes. No entanto, um shell ADB ainda pode executar ações indisponíveis para um aplicativo convencional e pode sustentar a execução persistente de comandos.

O agente Go do RatHat expõe um serviço HTTP na interface de loopback do dispositivo. O componente de proxy reverso pode então tornar esse serviço interno acessível por meio de um túnel controlado pelo invasor. Esse arranjo separa o acesso remoto da interface visível do aplicativo malicioso.

O projeto resultante tem três elementos cooperativos. O aplicativo Android obtém permissões e coordena atividades. O agente Go executa comandos e gerencia a persistência. O proxy mantém uma rota externa para os serviços locais.

Se uma vítima remover apenas o aplicativo, outro componente poderá reinstalá-lo, segundo relatos. Se o agente nativo parar, o aplicativo poderá restaurar esse agente. Essa recuperação recíproca é mais problemática do que um único truque de persistência.

O RatHat também interfere nas tentativas comuns de remoção. Pesquisadores afirmam que ele observa a tela de confirmação de desinstalação do Android, cancela a ação e exibe um falso erro do Google Play sobre a interface.

Comportamentos semelhantes contra remoção antecedem o RatHat. Há muito tempo malwares Android abusam de serviços de Acessibilidade para pressionar botões de navegação ou cobrir controles de segurança. O RatHat combina essa técnica conhecida com um canal independente de acesso ao shell.

As defesas contra análise do malware acrescentam outra camada. Pesquisadores identificaram adulteração de contêiner, atributos ZIP incomuns, strings criptografadas, pseudo-instruções DEX inválidas e verificações em tempo de execução para ferramentas de análise.

Segundo relatos, seu manifesto Android tem 61MB, com 99 por cento composto por dois tipos de blocos não documentados. O runtime do Android ignora esses blocos, enquanto algumas ferramentas de análise podem falhar ou esgotar recursos ao processá-los.

A bomba de manifesto não rouba credenciais nem controla diretamente um telefone. Seu objetivo é retardar a inspeção automatizada e dificultar a classificação do pacote. Esse atraso pode dar mais tempo a uma campanha antes que assinaturas e indicadores circulem.

O RatHat também verifica depuradores, reempacotamento, emuladores, artefatos de root, Frida e Xposed. Essas ferramentas são comuns em ambientes de análise de malware. Detectá-las permite que o código malicioso mude de comportamento ou pare de executar sob inspeção.

A arquitetura combinada pressiona defensores que se concentram apenas em arquivos de aplicativos. Remover um APK, corresponder um hash conhecido ou bloquear um servidor de comando pode não eliminar todos os componentes ativos.

Os sinais comportamentais se tornam mais importantes. Equipes de segurança podem procurar concessões suspeitas de Acessibilidade, atividade inesperada de Depuração sem fio, pareamento ADB local, daemons nativos incomuns e túneis reversos persistentes.

Isso não torna a detecção por assinatura inútil. Hashes de pacotes conhecidos, domínios, certificados e indicadores de rede continuam valiosos. O RatHat mostra por que esses sinais precisam do apoio de monitoramento em tempo de execução e do estado do dispositivo.

Aplicativos Bancários Enfrentam um Adversário no Nível da Interface

O RatHat ataca a interação confiável entre um usuário e um aplicativo financeiro, não apenas os dados armazenados nesse aplicativo.

Um aplicativo bancário pode criptografar seu banco de dados local e proteger o tráfego com o servidor enquanto o malware observa a tela do usuário. Se um serviço hostil de Acessibilidade puder ler o conteúdo da interface ou injetar toques, as proteções da camada de aplicativo enfrentam um problema diferente.

Segundo relatos, o RatHat exibe interfaces HTML falsas sobre aplicativos bancários e de criptomoedas visados. Uma vítima pode acreditar que um prompt de login pertence ao serviço legítimo enquanto insere detalhes em uma sobreposição maliciosa.

O malware pode então interceptar mensagens SMS ou conteúdo de notificações que contenham códigos de verificação. Também pode coletar texto digitado e monitorar endereços do navegador, dando aos operadores contexto sobre as credenciais capturadas.

O Android adicionou defesas contra essas técnicas. O Android 15 limita parte da exposição de senhas de uso único durante o compartilhamento de tela e para serviços de escuta de notificações. O Android 16 introduziu uma forma de os desenvolvedores marcarem elementos sensíveis da interface.

A configuração accessibilityDataSensitive pode impedir que serviços de Acessibilidade não verificados leiam ou interajam com visualizações protegidas. A orientação do Android 16 do Google a recomenda para senhas, informações financeiras e outros campos sensíveis.

Os desenvolvedores também podem usar sinais de ambiente do Play Integrity. O veredito de acesso ao app pode indicar se outro aplicativo tem permissões capazes de capturar a tela, exibir sobreposições ou controlar o dispositivo.

Essas defesas elevam o custo operacional do RatHat, mas não eliminam o problema. A proteção depende da versão do Android, da configuração do dispositivo, da adoção pelos desenvolvedores e de o aplicativo malicioso já ter estabelecido outro canal de controle.

A Acessibilidade também apresenta uma difícil escolha para a plataforma. O Android precisa oferecer suporte a softwares assistivos legítimos que leem o conteúdo da interface e executam ações para os usuários. Bloquear toda interação automatizada prejudicaria essas ferramentas essenciais.

O Google analisa ferramentas de Acessibilidade distribuídas pela Play e alerta para usos enganosos. Sua orientação do Play Protect afirma que um serviço suspeito pode solicitar controle total do dispositivo e acesso a informações pessoais ou financeiras.

O RatHat supostamente entra por meio de downloads de APK fora do Google Play. Isso limita a exposição direta pela loja oficial, mas o sideloading continua disponível por navegadores, mensagens, fóruns e mercados de terceiros.

O Google informou em março de 2026 que o malware apareceu mais de 90 vezes mais frequentemente em fontes de sideloading do que no Google Play. A empresa está ampliando a verificação de desenvolvedores, com requisitos regionais de instalação programados para começar em 30 de setembro de 2026.

O momento coloca o RatHat ao lado de uma resposta mais ampla da plataforma à distribuição maliciosa. A verificação de desenvolvedores pode aumentar a responsabilização por softwares instalados fora da Play, embora caminhos avançados de instalação continuem disponíveis.

As instituições financeiras também têm trabalho a fazer. Ações de alto risco não devem depender inteiramente de evidências exibidas ou inseridas em um telefone potencialmente comprometido.

A confirmação de transações pode incorporar pontuação de risco no lado do servidor, histórico de dispositivos confiáveis, mudanças comportamentais e limites para destinatários recém-adicionados. Os bancos também podem desafiar sessões quando sinais de integridade do dispositivo ou de acesso a aplicativos indicarem risco elevado.

Para equipes corporativas, dispositivos móveis merecem a mesma profundidade de resposta a incidentes que laptops. Um telefone que armazena aplicativos de autenticação, mensagens de trabalho, sessões na nuvem e acesso bancário pode se tornar uma ponte para diversos sistemas.

O Alcance e a Atribuição do RatHat Permanecem Incertos

As capacidades do malware estão documentadas em detalhes, mas o número de vítimas, a escala da campanha e a identidade dos operadores continuam sem solução.

A Zimperium associa o RatHat a agentes que parecem operar a partir da China. As evidências públicas incluem prompts em chinês encontrados no malware e infraestrutura de campanha observada.

O idioma não constitui atribuição definitiva. Desenvolvedores de malware podem reutilizar código, inserir pistas enganosas, atuar além das fronteiras ou vender ferramentas a operadores não relacionados. Os relatos disponíveis não identificam um grupo nomeado nem um patrocinador governamental.

A pesquisa pública também não fornece uma contagem confirmada de infecções. Ela não lista países afetados, bancos visados, duração da campanha nem o número de servidores de comando ativos.

Essa falta de informação limita as conclusões sobre a exposição imediata. O RatHat pode dar suporte a uma campanha altamente direcionada, a um serviço criminoso em desenvolvimento ou a uma operação mais ampla que os pesquisadores observaram apenas parcialmente.

O serviço de IA não identificado cria outra incerteza. Os investigadores não explicaram publicamente como o malware se autentica no assistente, com que frequência envia solicitações ou o que acontece quando a conectividade falha.

Solicitações de IA baseadas na nuvem podem gerar atividade de rede detectável. Os provedores também podem suspender contas abusivas, filtrar prompts suspeitos ou cooperar com investigações. Os atacantes podem responder alternando contas, usando serviços de proxy ou migrando para modelos hospedados localmente.

A confiabilidade do modelo também merece escrutínio. A automação de interfaces pode falhar quando os dados XML estão incompletos, os rótulos são ambíguos ou as telas contêm diálogos inesperados. Um toque equivocado pode expor o malware, interromper um ataque ou bloquear o acesso dos operadores.

Essas limitações não neutralizam a ameaça. Elas mostram que malwares assistidos por IA ainda dependem de infraestrutura, credenciais, conectividade e lógica de contingência cuidadosamente projetada.

O caso anterior do PromptSpy oferece uma referência útil. Seu recurso assistido por modelo abordava uma tarefa restrita de persistência, enquanto um módulo VNC separado permitia controle remoto. Os pesquisadores não conseguiram confirmar se suas amostras representavam uma campanha ativa ou uma prova de conceito.

O RatHat parece mais operacionalmente completo. Seus canais de entrega, sobreposições para roubo de credenciais, sistema de comando, serviços nativos e componente de tunelamento formam uma cadeia de ataque coerente.

No entanto, completude técnica não equivale a implantação em larga escala. Os leitores devem evitar tratar cada capacidade documentada como evidência de que ela afetou uma grande população.

A Zimperium também vende produtos de segurança móvel e afirma que seus produtos detectam o RatHat. Esse contexto comercial não invalida as descobertas técnicas, mas a replicação independente continua valiosa.

Um segundo relato técnico do The Hacker News corrobora a arquitetura com base na divulgação da Zimperium. Ele não representa uma análise independente do malware com amostras separadas.

A conclusão mais sólida no momento é mais restrita. Pesquisadores analisaram um malware que combina interpretação de interface guiada por IA com técnicas já estabelecidas de tomada de controle do Android e uma arquitetura incomumente persistente baseada em ADB.

Três Sinais Mostrarão se o RatHat Muda o Malware Móvel

O próximo teste é saber se as técnicas do RatHat se espalham além de uma única família relatada e forçam mudanças mensuráveis de defensores, aplicativos financeiros e do Android.

O primeiro sinal são evidências independentes de campanha. Outros pesquisadores devem procurar amostras correspondentes, infraestrutura de comando, certificados de assinatura, páginas de entrega e infecções na telemetria de clientes.

A geografia confirmada das vítimas esclareceria se o RatHat visa bancos ou regiões específicos. Um número crescente de amostras sugeriria desenvolvimento ou distribuição ativos, e não um experimento técnico isolado.

A ausência de telemetria ampla enfraqueceria as alegações de que o RatHat representa uma onda global imediata. Isso não eliminaria a lição arquitetural, mas mudaria o senso de urgência.

O segundo sinal é a reutilização da cadeia de persistência local via ADB. Autores de malware frequentemente copiam técnicas que se mostram confiáveis, especialmente quando pesquisas públicas revelam detalhes de implementação suficientes para inspirar imitações.

Os defensores devem monitorar novas famílias que ativem a Depuração sem fio, recuperem códigos de pareamento, implantem agentes no nível do shell e preservem o acesso após a remoção do aplicativo. A adoção repetida tornaria esse mecanismo mais relevante do que a marca RatHat.

O Android e os fabricantes de dispositivos podem responder tornando mais rígidas as transições entre Acessibilidade, Opções do desenvolvedor, pareamento sem fio e processos de shell em segundo plano. Melhores alertas aos usuários também poderiam expor combinações suspeitas dessas ações.

O terceiro sinal é a expansão da IA em tempo de execução além da consulta de interfaces. O RatHat supostamente pede a um modelo coordenadas, texto visível e comandos de navegação. Amostras futuras podem usar modelos para classificar telas financeiras, adaptar prompts fraudulentos ou selecionar ações a partir de objetivos mais amplos.

Esse desenvolvimento reforçaria a necessidade de monitorar o tráfego de serviços de IA em investigações de malware. Também pressionaria provedores de modelos a identificar abusos automatizados sem bloquear fluxos de trabalho legítimos de acessibilidade e testes.

Se a IA continuar limitada a algumas tarefas frágeis de navegação, o RatHat parecerá uma atualização incremental de automação. Se múltiplas famílias de malware adotarem ciclos de decisão, os defensores enfrentarão comportamentos mais variáveis entre dispositivos.

Os usuários podem reduzir o risco atual sem esperar por esses sinais. Evite arquivos APK enviados por mensagens não solicitadas, anúncios ou páginas de download desconhecidas. Trate solicitações inesperadas de Acessibilidade como um alerta sério, especialmente quando vierem de aplicativos sem relação com funções assistivas.

Mantenha o Play Protect ativado e permita que ele examine aplicativos desconhecidos. Revise os serviços de Acessibilidade ativados, o acesso a notificações, os aplicativos de administrador do dispositivo, as Opções do desenvolvedor e a Depuração sem fio quando houver suspeita de comprometimento.

Um dispositivo que bloqueia a desinstalação ou restaura um aplicativo removido precisa de mais do que outra tentativa comum de remoção. Desconecte-o de contas e redes sensíveis e, em seguida, procure suporte qualificado de resposta a incidentes.

As organizações devem revogar sessões ativas, alternar credenciais expostas e revisar atividades financeiras a partir de outro dispositivo confiável. Uma redefinição de fábrica pode se tornar necessária, mas os responsáveis pela resposta devem preservar evidências quando uma investigação for importante.

O malware Android RatHat merece atenção porque combina navegação adaptável com controle duradouro do dispositivo. A questão decisiva é se os defensores conseguem conter cada componente, e não se sua IA consegue pressionar o próximo botão.