Como funcionam os golpes de Pix com acesso remoto e sobreposição de tela, e o que um app bancário pode fazer

O Pix liquida em segundos e não pode ser desfeito por quem pagou. Essas duas propriedades o tornam ótimo para empresas e atraente para criminosos. Em março de 2026, a equipe de pesquisa da Zimperium descreveu uma família de malware Android chamada PixRevolution, e o jeito como ela funciona é um bom estudo de caso, porque combina três ideias que aparecem em muitas campanhas de fraude financeira: abuso de acessibilidade, observação ao vivo da tela e troca do destinatário no último instante.

Este artigo explica o padrão no nível de que um defensor precisa, resume as mudanças de plataforma que chegaram ao Brasil em 2026 e lista os controles que um app bancário ou de pagamentos pode adicionar. Ele não traz detalhe operacional de como construir ou operar esse tipo de malware, e nenhum artigo sobre o tema deveria trazer.

O padrão, passo a passo, do lado da vítima

A campanha descrita em reportagens públicas começa pela distribuição. As vítimas são levadas a uma página falsa de loja de apps, que imita uma listagem legítima, e induzidas a instalar um pacote Android de fora da loja oficial. Isso se chama sideloading e importa porque a loja oficial aplica verificações que um arquivo instalado manualmente nunca enfrenta.

Depois de instalado, o app pede permissão de acessibilidade, em geral com um motivo plausível, como "necessário para o app funcionar". Serviços de acessibilidade existem para ajudar pessoas com deficiência e, por isso, têm capacidades poderosas: conseguem ler o que está na tela e fazer toques e digitação em nome do usuário. Em mãos erradas, essas capacidades são exatamente o que a fraude precisa.

Com essa permissão e a capacidade de capturar a tela, o malware transmite a tela para o servidor do atacante. Segundo as reportagens públicas, o PixRevolution então espera. Quando a vítima inicia uma transferência por Pix, um operador remoto acompanha em tempo quase real. No momento em que o usuário confirma, o malware mostra uma breve tela de "aguarde" e troca a chave do destinatário por uma que o atacante controla. A vítima vê um fluxo com aparência normal e uma confirmação, e o dinheiro vai para outro lugar. A Zimperium descreveu isso como um modelo de "agente no circuito", em que o operador pode ser uma pessoa ou um agente automatizado, o que dificulta pegar o golpe com regras simples de comportamento roteirizado.

Uma segunda família de ataques, a sobreposição de tela (overlay), funciona de outro modo, mas com a mesma superfície de permissões. Uma janela falsa é desenhada por cima do app bancário real para coletar credenciais ou para mascarar o que de fato está sendo enviado. Trojans de acesso remoto e kits de overlay muitas vezes são distribuídos juntos.

Por que o app em si dificilmente é o culpado, e mesmo assim precisa agir

O app bancário nessa história geralmente é genuíno e não modificado. O ataque acontece ao redor dele, a partir de outro app no mesmo aparelho. Por isso os controles tradicionais de resiliência (ofuscação, detecção de adulteração) não o impedem sozinhos: nada no seu binário foi tocado.

Ainda assim, o app pode fazer várias coisas, porque roda no mesmo ambiente e controla o momento sensível. O objetivo não é garantir segurança em um aparelho comprometido, o que nenhum app consegue. O objetivo é tornar o ataque mais difícil, mais barulhento e menos lucrativo, e passar a decisão ao servidor sempre que possível.

O que um app pode fazer

1. Perguntar à plataforma o que mais existe no aparelho

A Play Integrity API do Google oferece um sinal opcional de "risco de acesso ao app" que informa se outros apps no aparelho poderiam capturar a tela, controlar o aparelho ou desenhar sobreposições, distinguindo apps conhecidos e desconhecidos. Serviços de acessibilidade verificados ficam de fora, o que ajuda, porque um leitor de tela legítimo não deve ser punido. Um backend pode usar esse sinal para exigir confirmação extra antes de uma transferência de alto valor quando houver um app desconhecido que capture ou controle o aparelho.

Use com cuidado. É uma pista, e não prova, e uma política bruta de "bloquear todo mundo que tem um gravador de tela" prejudica quem depende de tecnologia assistiva e aumenta o custo de suporte. Uma resposta graduada funciona melhor: ignorar para ver o saldo, exigir etapa extra para um novo destinatário, recusar com uma mensagem clara nas maiores operações.

2. Proteger a própria tela sensível

O Android permite marcar uma janela como segura para que ela não apareça em capturas de tela nem em gravações de tela não seguras. Para as telas de confirmação de pagamento, esse é um controle barato e sensato, embora não seja absoluto: um serviço de acessibilidade lê a hierarquia de views, e não uma imagem, então você também quer limitar o que a hierarquia expõe. É possível marcar views com conteúdo sensível como não importantes para a acessibilidade quando isso não prejudica um usuário genuíno que depende desses serviços, e você precisa testar essa troca com pessoas que usam tecnologia assistiva, em vez de supô-la.

3. Tornar o destinatário imutável depois de o usuário tê-lo visto

O PixRevolution tem sucesso porque o dado que o usuário confirmou não é o dado que foi enviado. A defesa mais eficaz é vincular os dois. Mostre o nome do destinatário que o seu servidor resolve a partir da chave, e não só a chave, e peça ao servidor que assine os detalhes exatos da transação (valor, nome resolvido, chave) que o usuário confirma. A etapa de confirmação passa então a autorizar esse objeto assinado, e qualquer alteração no caminho o invalida. Isso não depende de detectar o malware.

4. Aumentar o atrito onde a fraude se concentra

A fraude no Pix tende a seguir um perfil: aparelho novo, destinatário novo, uma primeira transferência alta, um horário incomum ou uma sessão que mudou recentemente uma configuração de acessibilidade. Regras de risco no servidor que acrescentam um atraso, um segundo fator ou um período de espera para essas combinações reduzem perdas sem incomodar a maioria dos clientes. Limites e atrasos são uma ferramenta conhecida em pagamentos, e um app pode aplicar a mesma ideia por usuário e por situação.

5. Detectar o ambiente e reportar

Detectar que um serviço de acessibilidade está ligado, que a tela está sendo capturada ou que outro app tem permissão de sobreposição são sinais que o seu app pode enviar ao backend. Não derrube o app nem mostre um erro assustador na detecção: você ensinaria o atacante o que dispara a reação e frustraria usuários genuínos. Envie o sinal ao servidor, onde ele pesa em uma decisão de risco, e responda com uma mensagem calma e específica quando precisar recusar.

O que mudou no Brasil em 2026

Duas mudanças de plataforma importam para esta ameaça, e vale ser preciso sobre o que cada uma faz e não faz.

Primeiro, a exigência de verificação de desenvolvedores do Google. Segundo a documentação do Google, a partir de 30 de setembro de 2026, apps instalados por lojas participantes em aparelhos Android certificados no Brasil, na Indonésia, em Singapura e na Tailândia precisam vir de desenvolvedores registrados. Instalar um app não registrado não é impossível: passa por um "fluxo avançado" mais trabalhoso ou pelas ferramentas de desenvolvedor. O objetivo é dificultar a distribuição anônima de malware e tornar mais difícil substituir um desenvolvedor banido.

Segundo, a proteção avançada contra fraude do Play Protect. Reportagens públicas de 2024 e 2025 descrevem pilotos, entre eles no Brasil, em que o Play Protect bloqueia a instalação, a partir de uma fonte de sideloading pela internet, de um app que pede permissões de alto risco, como acessibilidade, acesso a notificações ou leitura de SMS. O Google informou que, na sua análise das principais famílias de malware de fraude, mais de 95% das instalações vinham de fontes de sideloading. Confira o alcance atual nas páginas do próprio Google, porque pilotos mudam.

Nenhuma das duas medidas torna o seu app seguro. Um aparelho já comprometido, um usuário enganado a usar o fluxo avançado ou uma loja não coberta continuam sendo possíveis. Pense nelas como redução do número de aparelhos infectados, e não como garantia, e mantenha os seus controles no servidor.

Uma lista que você pode executar neste trimestre

1. Habilite o sinal de risco de acesso ao app e registre-o por algumas semanas antes de impor qualquer coisa.
2. Adicione uma confirmação assinada e resolvida no servidor para os pagamentos, para que o dado que o usuário viu seja o dado autorizado.
3. Marque as janelas de confirmação como seguras e teste as trocas de acessibilidade com usuários reais.
4. Adicione regras de risco para aparelho novo, mais destinatário novo, mais valor alto, com um atraso ou segundo fator.
5. Envie sinais de ambiente ao backend e decida lá.
6. Escreva uma mensagem ao cliente que explique, em português simples, por que você vai pedir uma confirmação extra, para que o suporte não seja pego de surpresa.

A fraude no Pix é um alvo em movimento, e este artigo descreve o que era público em 2026. O princípio que dura é simples: não deixe o cliente ser o único juiz de um pagamento e faça de toda confirmação sensível algo que o servidor consiga verificar.

Todos os artigos