Trojans Android miram Pix ao abusar do Serviço de Acessibilidade para automatizar transferências

PixStealer e MalRhino exploram permissões de acessibilidade no Android para operar sobre aplicativos bancários brasileiros, ocultar ações na tela e direcionar transações Pix a contas controladas por operadores.

Componente	Aplicativos Android maliciosos PixStealer e MalRhino, distribuídos como falsos serviços ligados a bancos brasileiros e dependentes do Serviço de Acessibilidade do Android.
Vetor	A vítima instala o aplicativo malicioso, concede permissão de acessibilidade após uma tela de convencimento e abre o aplicativo bancário alvo em um dispositivo já habilitado para transações Pix.
Impacto	PixStealer automatiza a leitura do saldo e a transferência do valor disponível via Pix; MalRhino adiciona processamento dinâmico de eventos de acessibilidade com JavaScript recebido de servidor de comando e controle.
Prioridade	Revisar aplicativos Android com permissões de acessibilidade, bloquear falsos utilitários bancários, monitorar sobreposições suspeitas e reforçar validações transacionais no próprio aplicativo bancário.
Artefatos	PixStealer usou o nome interno Pag Cashback 1.4, pacote com.pagcashback.beta e serviço com.gservice.autobot.Acessibilidade; MalRhino apareceu como falso iToken para Inter Bank no pacote com.gnservice.beta.
Técnica	A cadeia usa leitura de elementos de interface, cliques automatizados, preenchimento de campos, sobreposição falsa e, no MalRhino, execução de macros JavaScript pelo mecanismo Rhino.

Resumo técnico

Uma onda de trojans bancários Android foi direcionada ao ecossistema de pagamentos brasileiro com foco em Pix e aplicativos móveis de bancos. O caso combina engenharia social simples, abuso do Serviço de Acessibilidade do Android e automação de interface para executar ações que normalmente exigiriam interação legítima do usuário. O ponto central não é a quebra criptográfica do Pix nem a exploração de uma falha no protocolo de pagamento, mas o sequestro operacional da sessão já autenticada no aparelho da vítima. Em vez de capturar credenciais e depender de uso posterior em outro ambiente, o malware age dentro do próprio dispositivo que já passou por etapas de confiança do banco.

O PixStealer representa a variante mais enxuta dessa família. Ele foi apresentado como um falso serviço de cashback ligado ao PagBank, identificado internamente como Pag Cashback 1.4 e associado ao pacote com.pagcashback.beta. O aplicativo malicioso solicita acesso ao Serviço de Acessibilidade com uma justificativa fraudulenta e, depois da concessão, espera a vítima abrir o aplicativo bancário. A partir desse ponto, a automação lê o saldo exibido, armazena o valor em SharedPreferences sob a chave valor, exibe uma tela falsa de sincronização e opera em segundo plano para iniciar uma transferência Pix no valor total disponível para um beneficiário controlado pelo operador.

A segunda variante, chamada MalRhino, usa a mesma base comportamental, mas amplia a flexibilidade operacional. Ela foi distribuída como um falso aplicativo iToken para Inter Bank, com pacote com.gnservice.beta, e incorpora o mecanismo Rhino, uma implementação Java de JavaScript mantida como software aberto. No contexto do malware, esse componente permite processar eventos de acessibilidade de forma dinâmica e executar macros recebidas de um servidor de comando e controle quando um aplicativo bancário suportado está em primeiro plano. Isso reduz a necessidade de embutir toda a lógica no binário Android e permite adaptar ações de interface conforme o aplicativo alvo.

Fluxo técnico

A cadeia começa com a instalação de um aplicativo Android que se apresenta como funcionalidade bancária auxiliar. No PixStealer, a isca é um suposto cashback; no MalRhino, a isca é um falso aplicativo de token. Em ambos os casos, a etapa decisiva é a concessão do Serviço de Acessibilidade. Esse recurso existe para permitir que usuários com deficiência interajam melhor com o sistema e com aplicativos, mas sua capacidade de observar texto, identificar elementos visuais, executar cliques, inserir dados e realizar gestos também cria uma superfície crítica quando entregue a software hostil.

Após receber a permissão, o PixStealer não demonstra um perfil tradicional de trojan bancário com exfiltração ampla de credenciais ou comunicação recorrente com infraestrutura externa. A característica mais relevante é a redução deliberada de funções: o aplicativo tem poucas permissões, não depende de comunicação com C&C para seu objetivo principal e concentra sua lógica em uma ação de transferência. Essa limitação diminui a exposição comportamental do malware e dificulta a detecção por sinais clássicos, porque não há necessidade de upload de dados bancários nem de atualização remota para completar a fraude descrita.

Quando a vítima abre o aplicativo PagBank e autentica sua conta, a automação usa acessibilidade para interagir com a tela. Um dos passos descritos envolve acionar o controle visual que revela o saldo. O valor exibido é armazenado localmente em SharedPreferences com a chave valor, servindo como base para o montante da transação. Em seguida, uma sobreposição falsa informa que há uma sincronização em andamento e orienta a vítima a não desligar a tela. Essa camada visual tem função operacional: mascarar as ações realizadas no aplicativo bancário enquanto o malware navega pelo fluxo de transferência.

Durante a etapa de pagamento, o malware localiza elementos da interface relacionados à transferência, preenche o campo de valor com o saldo coletado e procura o campo de identificação do beneficiário, como CPF ou CNPJ. O identificador usado pertence ao operador ou a uma conta sob seu controle, mas o valor específico não foi fornecido no contexto técnico e não deve ser inferido. A ação é viável porque o dispositivo já está vinculado ao cliente e já passou por validações exigidas pelo banco para habilitar Pix no aparelho, incluindo verificação de documento e selfie descrita para o aplicativo alvo.

O MalRhino mantém o mesmo abuso estrutural, porém adiciona uma camada de decisão remota. Para identificar se o aplicativo em primeiro plano é suportado, a variante calcula o MD5 do nome do pacote observado e compara o resultado com uma lista predefinida, evitando deixar nomes de pacotes bancários em texto claro dentro do aplicativo. Quando há correspondência, o malware solicita ao servidor de comando e controle uma macro JavaScript adequada ao aplicativo atual. Esse código é executado pelo mecanismo Rhino com acesso a métodos utilitários expostos pelo serviço de acessibilidade, como criação de janelas falsas, clique em elementos, gestos e inserção de texto.

Superfície afetada

A superfície primária é composta por usuários Android que instalaram aplicativos falsos relacionados a bancos brasileiros e concederam permissão de acessibilidade. A campanha descrita teve relação direta com o ambiente brasileiro por mirar Pix, PagBank e Inter Bank. O risco não depende apenas de credenciais roubadas; ele depende de um dispositivo no qual o cliente já consiga operar o aplicativo bancário real. Por isso, controles que protegem contra login indevido em um novo aparelho não eliminam completamente o cenário, pois a automação ocorre no aparelho que já está validado.

O PixStealer afeta especialmente fluxos nos quais o saldo é exibido na interface e a transferência pode ser conduzida por elementos acessíveis ao serviço do Android. O malware não precisa conhecer internamente a lógica do banco; ele manipula a interface do mesmo modo que um usuário faria, mas em velocidade e com intenção fraudulenta. A presença de uma sobreposição também aumenta o risco de a vítima não perceber a transação em andamento, principalmente quando a mensagem falsa é coerente com a isca inicial de sincronização ou ativação de benefício.

No MalRhino, a superfície se amplia porque a lógica de automação pode ser recebida sob demanda. A presença do Rhino cria uma ponte entre código JavaScript remoto e métodos Java do serviço malicioso, permitindo que o operador ajuste a automação para diferentes telas e aplicativos suportados. Essa arquitetura é mais adaptável do que uma sequência rígida embutida no aplicativo e pode reduzir o tempo necessário para reagir a mudanças de interface em aplicativos bancários.

• Dispositivos Android nos quais o usuário instalou aplicativos falsos com aparência de serviço bancário, cashback ou token.
• Contas bancárias acessadas em aparelhos já autorizados para Pix e com etapas de verificação do banco previamente concluídas.
• Aplicativos bancários em que elementos de saldo, transferência, valor e beneficiário são legíveis ou acionáveis pelo Serviço de Acessibilidade.
• Ambientes de detecção que dependem apenas de comunicação C&C podem perder a variante PixStealer, que executa a fraude principal sem esse canal.

Hunting e telemetria

A investigação defensiva deve começar pela concessão de permissões de acessibilidade a aplicativos que não tenham justificativa legítima e verificável. Em aparelhos corporativos, MDM e EDR móvel devem gerar alertas quando aplicativos recém-instalados solicitarem esse tipo de permissão com nomes relacionados a serviços financeiros, cashback, token ou sincronização. O nome do serviço com.gservice.autobot.Acessibilidade é um artefato relevante no caso descrito e deve ser tratado como sinal de risco quando observado em conjunto com os pacotes mencionados.

No endpoint móvel, a telemetria de sobreposição de tela é importante porque o PixStealer usa uma janela falsa para esconder a navegação real no aplicativo bancário. Sinais úteis incluem aplicativos de baixa reputação exibindo overlays logo após a abertura de aplicativos financeiros, alternância rápida entre telas de banco, ações de clique e preenchimento originadas de serviço de acessibilidade e uso de armazenamento local para guardar valores extraídos da interface. Em ambientes Android gerenciados, também é útil correlacionar a instalação a partir da loja, a primeira execução, a concessão de acessibilidade e a abertura subsequente do aplicativo bancário.

Para bancos e equipes antifraude, a detecção precisa considerar comportamento de sessão. O uso de um dispositivo já aprovado não deve encerrar a análise de risco, porque o caso mostra que a fraude pode ocorrer no próprio aparelho confiável. Transações Pix iniciadas logo após a revelação do saldo, preenchimento do valor total disponível e mudança rápida para campo de beneficiário devem compor regras comportamentais, especialmente quando combinadas com sinais de sobreposição, acessibilidade ativa ou ausência de interação humana típica entre etapas sensíveis.

No MalRhino, a presença de tráfego para obtenção de macros JavaScript é um sinal adicional. A defesa não deve publicar nem executar o conteúdo dessas macros; o valor está em observar a sequência: aplicativo bancário em primeiro plano, cálculo ou comparação relacionada a identificadores de pacote, chamada ao servidor de comando e controle e execução dinâmica no mecanismo Rhino. A combinação de bibliotecas Rhino em um suposto aplicativo de token bancário, uso de acessibilidade e métodos utilitários para clique, gesto, janela falsa e entrada de texto é altamente suspeita.

• Aplicativos com.pagcashback.beta e com.gnservice.beta instalados em dispositivos Android com acesso a contas bancárias.
• Serviço de acessibilidade nomeado com.gservice.autobot.Acessibilidade ou serviços semelhantes sem finalidade legítima clara.
• Sobreposição exibida durante uso de aplicativo bancário, especialmente com mensagens de sincronização, espera ou ativação de benefício.
• Ações automatizadas em sequência: revelar saldo, iniciar transferência, preencher valor total e inserir CPF ou CNPJ de beneficiário.
• Uso de Rhino ou biblioteca rhino-android em aplicativo que se apresenta como token, cashback ou utilitário bancário.

Mitigação

A resposta deve separar duas frentes: proteção do usuário e endurecimento do fluxo bancário. No dispositivo, a medida imediata é remover aplicativos falsos, revogar permissões de acessibilidade concedidas a software não essencial e revisar aplicativos financeiros instalados recentemente. Em ambientes corporativos, políticas de MDM devem restringir a concessão de acessibilidade a uma lista aprovada e impedir aplicativos de origem ou reputação incompatível com o perfil do usuário. O fato de os aplicativos descritos terem sido distribuídos pela Google Play mostra que a presença na loja oficial não deve ser tratada como garantia suficiente.

Para instituições financeiras, o controle precisa olhar para além da autenticação inicial. O caso mostra que verificações de documento, selfie e associação do aparelho são eficazes contra credenciais roubadas e troca de SIM, mas não impedem totalmente automação maliciosa no dispositivo já autorizado. Etapas de alto risco, como transferência do saldo total via Pix para novo beneficiário, devem incorporar sinais de integridade do ambiente móvel, presença de serviços de acessibilidade ativos, overlays em execução, velocidade de preenchimento, padrão de gestos e histórico de beneficiários.

A contenção após suspeita de infecção deve incluir bloqueio temporário de transações, revisão de beneficiários recentes, análise do histórico de instalação e preservação de artefatos do aparelho quando houver capacidade forense. Quando houver transação Pix confirmada, a prioridade operacional é acionar o fluxo antifraude do banco, correlacionar horário da transação com eventos no dispositivo e confirmar se havia aplicativo com acessibilidade ativa no momento. Para usuários finais, a orientação deve ser objetiva: nenhum cashback, token ou sincronizador deve exigir controle amplo de acessibilidade para operar uma conta bancária.

Equipes de segurança móvel também devem revisar regras que dependem exclusivamente de coleta de credenciais, SMS ou comunicação com C&C. O PixStealer demonstra que uma variante mínima, sem canal externo para a fraude principal, ainda pode produzir impacto financeiro direto. Já o MalRhino exige atenção a execução dinâmica e uso incomum de mecanismos de script dentro de aplicativos Android. A defesa mais consistente combina reputação de aplicativo, análise de permissões, comportamento de interface, proteção contra sobreposição e validação transacional no backend bancário.

• Revogar permissões de acessibilidade de aplicativos não essenciais e remover falsos serviços de cashback, token ou sincronização bancária.
• Bloquear ou colocar em quarentena aplicativos com os pacotes com.pagcashback.beta e com.gnservice.beta quando encontrados em inventário móvel.
• Monitorar transações Pix de valor total disponível, novo beneficiário e sequência anormalmente rápida de interação na interface.
• Adicionar sinais de risco para overlays, acessibilidade ativa e automação de clique durante operações bancárias sensíveis.
• Reforçar educação do usuário sobre solicitações de acessibilidade feitas por aplicativos que prometem benefício financeiro ou autenticação bancária auxiliar.