Campanha `NGate` mira o Brasil com `HandyPay` trojanizado para roubar dados NFC e PINs

Campanha `NGate` mira o Brasil com `HandyPay` trojanizado para roubar dados NFC e PINs

Malware para Android usa um aplicativo legítimo de retransmissão NFC modificado para capturar dados de cartões por aproximação, PINs e viabilizar saques em caixas eletrônicos sem contato.

ComponenteAplicativo Android HandyPay modificado com código malicioso associado à família NGate, também conhecida como NFSkate, usando a funcionalidade legítima de retransmissão NFC como base operacional.
VetorDistribuição fora da Google Play Store por sites que se passam por Rio de Prêmios e por uma página falsa de listagem da Google Play para um suposto aplicativo de proteção de cartão, induzindo a instalação manual do APK trojanizado.
ImpactoCaptura de PIN de cartão, retransmissão de dados NFC do cartão físico para um dispositivo controlado pelo operador e uso desses dados para pagamentos não autorizados e saques por aproximação em caixas eletrônicos compatíveis.
PrioridadeBloquear instalação de aplicativos fora de lojas oficiais, revisar eventos de aplicativo definido como pagamento padrão, orientar usuários sobre golpes de premiação e acionar bancos quando houver interação com o aplicativo suspeito.
ArtefatosAplicativo HandyPay trojanizado, fluxos falsos de premiação por WhatsApp, páginas que imitam Rio de Prêmios e página falsa de aplicativo de proteção de cartão.
PeríodoA atividade foi avaliada como iniciada por volta de novembro de 2025, com foco principal em usuários no Brasil.
Resumo técnico

Uma nova iteração da família de malware Android NGate foi observada em uma campanha voltada principalmente a usuários no Brasil. A operação altera o modelo usado em versões anteriores: em vez de depender do NFCGate ou de soluções prontas de retransmissão NFC, os operadores modificaram o aplicativo legítimo HandyPay, que já possui capacidade de encaminhar dados de NFC. Essa escolha reduz a necessidade de desenvolver do zero a camada de comunicação por aproximação e permite que o código malicioso se apoie em uma função esperada do aplicativo original. O resultado é um APK trojanizado que solicita ao usuário a definição como aplicativo de pagamento padrão, coleta o PIN do cartão e encaminha dados lidos por NFC para um dispositivo controlado pelo operador.

O objetivo técnico da cadeia é transformar o telefone da vítima em uma ponte temporária entre o cartão físico e o ambiente do operador. Após a instalação, a vítima é induzida a inserir o PIN no próprio aplicativo e encostar o cartão na parte traseira de um smartphone com NFC. Quando esse fluxo ocorre, o malware usa a capacidade de retransmissão do HandyPay para capturar e repassar os dados do cartão por aproximação. O operador pode então tentar usar o material retransmitido para pagamentos sem contato ou saques em caixas eletrônicos que aceitem transações por aproximação. O impacto confirmado no contexto é fraude financeira por retransmissão NFC e coleta de PIN, não havendo indicação de vazamento amplo de bases de dados, exploração de vulnerabilidade de sistema operacional ou comprometimento de infraestrutura bancária.

Fluxo técnico

A cadeia de entrega começa com engenharia social. Um dos caminhos descritos usa páginas que se passam por Rio de Prêmios, uma loteria associada ao estado do Rio de Janeiro. O site falso tenta convencer a vítima de que há um prêmio a receber e a direciona para iniciar uma conversa no WhatsApp. A partir dessa interação, o usuário é levado a baixar a versão envenenada do HandyPay. Outro caminho usa uma página falsa de listagem da Google Play Store para um suposto aplicativo de proteção de cartão. A campanha, porém, não disponibilizou a versão maliciosa do HandyPay na Google Play Store; a distribuição ocorre por esses mecanismos externos, o que torna a instalação por sideload uma precondição central do ataque.

Depois da instalação, o aplicativo pede para ser definido como aplicativo de pagamento padrão. Esse detalhe é importante porque o HandyPay original não exige permissões extensas para operar; sua função principal depende mais do papel de aplicativo de pagamento padrão do que de solicitações agressivas de acesso ao dispositivo. Para a vítima, a ausência de permissões incomuns pode reduzir sinais de alerta. Para o operador, isso diminui ruído em ferramentas de segurança móvel que se concentram em permissões sensíveis. Em seguida, o fluxo solicita o PIN do cartão dentro do aplicativo e orienta a vítima a aproximar o cartão físico da área NFC do smartphone. A combinação de PIN digitado e dados NFC retransmitidos cria as condições para uso fraudulento em transações por aproximação.

A análise do artefato também encontrou mensagens de depuração e notificações internas com emojis, um indício de possível uso de modelo de linguagem para gerar ou alterar partes do código. Esse ponto deve ser tratado com cautela: a presença desses elementos sugere uma possibilidade de automação ou assistência por IA na modificação do malware, mas não comprova sozinha quem escreveu o código nem o grau de sofisticação técnica dos operadores. O fato operacional mais relevante para defesa é que o aplicativo legítimo foi reaproveitado como base, com código malicioso acoplado à funcionalidade de NFC já existente.

Superfície afetada

A superfície diretamente exposta é composta por usuários Android no Brasil que instalam aplicativos fora da loja oficial a partir de páginas de premiação, mensagens em WhatsApp ou páginas que imitam listagens de aplicativos. O ataque depende de interação significativa da vítima: instalar o APK, aceitar a configuração do aplicativo como pagamento padrão, digitar o PIN e aproximar o cartão físico do telefone. Essa sequência não é invisível, mas é plausível em um golpe de premiação ou de falsa proteção de cartão, porque cada etapa pode ser apresentada como validação de benefício, desbloqueio de recebimento ou proteção contra fraude.

Ambientes corporativos com dispositivos Android gerenciados também devem considerar o risco quando há liberdade para sideload, ausência de política de bloqueio para aplicativos de pagamento não aprovados ou usuários que usam o mesmo aparelho para operações pessoais e profissionais. Embora o alvo principal descrito seja fraude com cartões de pagamento, dispositivos comprometidos podem gerar incidentes operacionais para times de suporte, resposta a fraudes, segurança móvel e atendimento ao usuário. A campanha não descreve exploração de falha em Android, bypass de sandbox ou escalonamento de privilégio; o abuso ocorre por instalação voluntária induzida e uso indevido de uma função legítima de NFC.

  • Usuários Android que instalaram APKs obtidos por páginas de premiação ou por páginas falsas de aplicativos de proteção de cartão.
  • Aparelhos com NFC habilitado e possibilidade de definir um aplicativo de terceiros como aplicativo de pagamento padrão.
  • Cartões físicos usados por aproximação durante o fluxo guiado pelo aplicativo trojanizado.
  • Organizações que permitem sideload em dispositivos gerenciados ou que não inventariam aplicativos de pagamento instalados.
Hunting e telemetria

A busca defensiva deve priorizar sinais de instalação e uso do HandyPay fora dos canais esperados, principalmente quando associado a mudanças recentes no aplicativo de pagamento padrão. Em frotas Android gerenciadas, registros de EMM ou MDM podem indicar instalação de APK por origem desconhecida, alteração de configuração de pagamento, nome de pacote relacionado ao aplicativo e horário de instalação. Em endpoints móveis sem telemetria completa, o atendimento deve coletar linha do tempo de interação do usuário, presença do aplicativo, origem do link, conversa que levou ao download e qualquer evento bancário subsequente envolvendo transações por aproximação ou saque em caixa eletrônico.

A telemetria de rede deve ser tratada com cuidado porque o contexto não fornece domínios, IPs ou caminhos de C2 específicos. Assim, a defesa não deve depender de bloqueios por IoC fixo. O caminho mais confiável é correlacionar instalação de APK não oficial, abertura do aplicativo, solicitação de definição como pagamento padrão, digitação de PIN relatada pelo usuário e transações financeiras próximas no tempo. Para equipes de fraude, o padrão relevante é uma janela curta entre a interação com o aplicativo, a aproximação do cartão no telefone e tentativas de pagamento ou saque sem contato em outro local. Para equipes de conscientização, páginas que se apresentam como Rio de Prêmios, falsas ofertas de prêmio e supostos aplicativos de proteção de cartão devem ser tratadas como temas de alerta.

  • Instalação de HandyPay a partir de origem desconhecida ou link recebido fora da Google Play Store.
  • Mudança recente do aplicativo de pagamento padrão em aparelho Android sem justificativa operacional.
  • Relato de usuário sobre solicitação de PIN dentro de aplicativo que não pertence ao banco emissor do cartão.
  • Interação com página de premiação, redirecionamento para WhatsApp e download de APK em sequência curta.
  • Transações por aproximação ou saques em caixa eletrônico após a vítima encostar o cartão no telefone.
Mitigação

A contenção começa pelo dispositivo e pela conta financeira. Quando houver suspeita de interação com o aplicativo trojanizado, o aparelho deve ser isolado de uso financeiro, o aplicativo removido por canal seguro e o banco emissor acionado para bloqueio preventivo, troca de credenciais associadas ao cartão e contestação de transações suspeitas. Como o PIN foi digitado no aplicativo, a resposta deve considerar que esse segredo deixou de ser confiável. A simples remoção do APK não elimina o risco financeiro se o cartão e o PIN continuarem válidos após a coleta.

Em dispositivos corporativos, a medida mais importante é impedir instalação por fontes desconhecidas e restringir quais aplicativos podem atuar como pagamento padrão. Políticas de MDM devem manter inventário de aplicativos, alertar para instalação manual de APKs e bloquear aplicativos de pagamento não autorizados. Para usuários finais, a orientação precisa ser objetiva: prêmios, loterias e aplicativos de proteção de cartão não devem exigir instalação fora da loja oficial, definição de aplicativo de pagamento padrão, digitação de PIN em aplicativo desconhecido ou aproximação do cartão físico ao telefone. A defesa deve reforçar que PIN de cartão só deve ser usado em canais esperados do emissor ou em terminais de pagamento legítimos.

A validação pós-incidente deve reconstruir a linha do tempo. Times de segurança devem registrar quando o link foi recebido, qual página foi acessada, se houve WhatsApp na cadeia, se o APK foi instalado, quando o aplicativo virou padrão de pagamento e se o cartão foi aproximado do telefone. Esse encadeamento separa exposição parcial de comprometimento efetivo do cartão. Também ajuda a priorizar casos: usuários que apenas visitaram a página falsa têm risco diferente daqueles que instalaram o APK, informaram PIN e fizeram a leitura NFC do cartão.

  • Bloquear sideload e restringir aplicativos autorizados como pagamento padrão em dispositivos gerenciados.
  • Remover o aplicativo suspeito, preservar evidências básicas e acionar o emissor do cartão quando o PIN tiver sido digitado.
  • Orientar usuários a não instalar APKs enviados por páginas de prêmio, WhatsApp ou falsas páginas de loja.
  • Revisar transações por aproximação e saques em caixa eletrônico ocorridos após a interação com o aplicativo.
  • Monitorar páginas e mensagens que abusem dos nomes Rio de Prêmios, HandyPay e supostos aplicativos de proteção de cartão.

Postar um comentário

0 Comentários