Aplicativos falsos de histórico de chamadas no Google Play cobraram usuários por dados fabricados

Campanha CallPhantom reuniu 28 aplicativos Android com mais de 7,3 milhões de instalações, uso de assinaturas, pagamentos por UPI e telas enganosas que prometiam registros de chamadas, SMS e WhatsApp inexistentes.

Componente	28 aplicativos Android fraudulentos publicados no Google Play, agrupados como CallPhantom, com promessa falsa de consulta de histórico de chamadas, SMS e chamadas do WhatsApp por número telefônico.
Vetor	Instalação voluntária a partir da loja oficial, seguida de engenharia social dentro do aplicativo para induzir pagamento por assinatura, checkout por cartão ou transferência via aplicativos compatíveis com UPI.
Impacto	Perda financeira por cobrança de serviços inexistentes e exposição de e-mail ou dados de pagamento inseridos pelo usuário; os aplicativos retornavam nomes e números fabricados, embutidos no código, sem recuperar registros reais.
Prioridade	Revisar dispositivos com os pacotes listados, cancelar assinaturas vinculadas, contestar cobranças indevidas e investigar logs de instalação, notificações e fluxos de pagamento associados.
Artefatos	calldetaila.ndcallhisto.rytogetan.ynumber, com.callhistory.calldetails.callerids.callerhistory.callhostoryanynumber.getcall.history.callhistorymanager, com.callinformative.instantcallhistory.callhistorybluethem.callinfo, com.anycallinformation.datadetailswho.callinfo.numberfinder, com.calldetails.smshistory.callhistoryofanynumber, com.callhistory.anynumber.chapfvor.history, com.getanynumberofcallhistory.callhistoryofanynumber.findcalldetailsofanynumber, com.easyranktools.callhistoryforanynumber, callhistoryeditor.callhistory.numberdetails.calleridlocator e com.all_historydownload.anynumber.callhistorybackup.
Mitigação	Remover aplicativos remanescentes, verificar cobranças no Google Play e em meios externos, rotacionar credenciais de e-mail se reutilizadas em fluxos suspeitos e endurecer políticas corporativas de instalação de aplicativos móveis.

Resumo técnico

Uma campanha de fraude em aplicativos Android explorou a confiança operacional associada ao Google Play para distribuir 28 aplicativos que prometiam acesso a históricos de chamadas, registros de SMS e chamadas do WhatsApp de qualquer número telefônico. O conjunto, rastreado como CallPhantom, acumulou mais de 7,3 milhões de instalações antes da remoção da loja. Um único aplicativo ultrapassou 3 milhões de downloads, o que indica alcance significativo mesmo sem uso de permissões sensíveis ou de uma cadeia de infecção complexa. O núcleo do golpe era econômico e de engenharia social: convencer o usuário de que uma consulta privada de telecomunicações seria tecnicamente possível mediante pagamento, entregar dados fabricados e manter a cobrança por assinatura ou por métodos externos.

Os aplicativos apresentavam interfaces simples e não continham capacidade real para consultar bases de operadoras, mensagens, chamadas de WhatsApp ou histórico de SMS. Depois do pagamento, o resultado exibido era composto por nomes e números gerados ou pré-definidos no próprio código do aplicativo. Essa arquitetura reduz sinais técnicos tradicionalmente usados para classificar malware móvel, porque a fraude não dependia de coleta agressiva de permissões, exploração local, escalonamento de privilégio ou exfiltração direta de contatos. O risco, no entanto, permanece concreto: cobrança indevida, exposição de dados de contato informados pelo usuário, captura de intenção de consulta sobre terceiros e possível direcionamento posterior por canais de pagamento ou e-mail.

A atividade teve foco primário em usuários Android na Índia e na região Ásia-Pacífico. Um dos aplicativos usou o nome de desenvolvedor Indian gov.in, escolha que tenta induzir confiança por proximidade semântica com identidade governamental. O uso de uma loja oficial aumenta a taxa de conversão, porque o usuário tende a interpretar a presença no catálogo como validação suficiente de segurança e legitimidade. Para operadores de segurança, o caso reforça que fraude móvel publicada em loja oficial pode não acionar indicadores clássicos de abuso de permissões, mas ainda exige resposta de endpoint móvel, governança de assinaturas e revisão de pagamentos recorrentes.

Fluxo técnico

O fluxo começa com a descoberta do aplicativo pelo usuário, normalmente por busca relacionada a histórico de chamadas, identificação de chamadas ou consulta de detalhes de número telefônico. Após a instalação, a interface induz o usuário a acreditar que o aplicativo tem acesso a registros de chamadas, SMS e chamadas do WhatsApp vinculados a qualquer número. Essa alegação é tecnicamente inconsistente com o modelo de segurança esperado para Android, serviços de telecomunicações e aplicativos de mensagens, porque esses dados não ficam disponíveis para consulta arbitrária por aplicativos de terceiros instalados por usuários comuns. A campanha explora exatamente essa assimetria de conhecimento: a promessa tem aparência utilitária, mas não corresponde a uma capacidade disponível ao aplicativo.

A monetização ocorreu por três caminhos observados. O primeiro usava assinaturas pelo sistema oficial de cobrança do Google Play. O segundo direcionava pagamentos por aplicativos compatíveis com UPI, incluindo carteiras e aplicativos de pagamento populares na Índia. O terceiro inseria formulários de cartão diretamente nos aplicativos. Os dois últimos caminhos violam a política de cobrança esperada para aplicativos distribuídos pela loja quando usados para contornar o mecanismo oficial. Em todos os casos, o pagamento era tratado como pré-condição para liberar o suposto relatório, mas a aplicação não executava consulta real em serviço externo legítimo nem validava acesso a uma base confiável de telecomunicações.

Depois da cobrança, o resultado apresentado ao usuário consistia em dados fabricados. A presença de nomes e números embutidos no código mostra que a aplicação não dependia de infraestrutura sofisticada para gerar a resposta. Em um segundo agrupamento, o usuário era solicitado a inserir endereço de e-mail para receber os detalhes do número informado. Ainda assim, a geração do suposto relatório só era desbloqueada após pagamento. Em ao menos um caso, se o usuário abandonasse o aplicativo antes de pagar, uma notificação enganosa informava que o histórico de chamadas de determinado número havia sido enviado ao e-mail. O toque na notificação reabria a tela de assinatura, criando um ciclo de pressão comportamental sem entrega de serviço real.

Superfície afetada

A superfície exposta abrange dispositivos Android que instalaram os aplicativos antes da remoção, contas Google associadas a assinaturas, meios de pagamento usados dentro ou fora do fluxo oficial e endereços de e-mail submetidos nas telas de suposta entrega de relatório. Como os aplicativos não solicitavam permissões sensíveis, a ausência de alertas de privacidade não deve ser interpretada como ausência de risco. O principal ativo afetado é financeiro, mas também há risco de privacidade contextual: consultas digitadas, números pesquisados e e-mails inseridos podem revelar relações pessoais, intenção de monitoramento ou alvos de curiosidade indevida.

Ambientes corporativos com política de dispositivo pessoal ou BYOD devem tratar o incidente como exposição de higiene móvel e de pagamento, não como comprometimento automático do sistema operacional. A investigação deve separar dispositivos apenas expostos a fraude financeira daqueles que também instalaram APKs de fora da loja ou concederam permissões de acessibilidade, SMS, contatos ou notificações a outros aplicativos suspeitos. Essa distinção é importante porque o material relacionado menciona campanhas móveis separadas que usam phishing por WhatsApp, sideloading de APKs e famílias como Gigabud RAT, MMRat e Taotie; esse outro padrão envolve comprometimento de dispositivo e transferência não autorizada, enquanto CallPhantom foi descrito como cobrança fraudulenta sem funcionalidade real de coleta de histórico.

A lista de pacotes deve ser usada como ponto de partida para inventário. Nomes semelhantes, erros ortográficos e cadeias longas com termos como callhistory, calldetails, calleridlocator e anynumber são consistentes com otimização para busca e com tentativa de parecer utilitário comum. Isso não substitui análise de hash, certificado ou telemetria de instalação, mas ajuda a orientar consultas em plataformas de MDM, inventário Android, logs de loja gerenciada e histórico de aplicativos removidos.

• Usuários que instalaram aplicativos de histórico de chamadas de qualquer número antes da remoção do Google Play.
• Contas com assinaturas ativas ou cobranças recentes vinculadas aos aplicativos fraudulentos.
• Meios de pagamento usados por Google Play Billing, aplicativos de UPI ou formulários de cartão dentro do aplicativo.
• Endereços de e-mail informados para recebimento de supostos relatórios de chamadas, SMS ou WhatsApp.
• Dispositivos corporativos ou pessoais gerenciados que permitiam instalação direta de aplicativos da loja sem revisão adicional.

Hunting e telemetria

A busca deve priorizar eventos de instalação e remoção dos pacotes conhecidos, assinaturas do Google Play iniciadas no período de exposição e transações de baixo a médio valor associadas aos aplicativos. Os planos observados variavam aproximadamente de 6 a 80 dólares, o que torna útil procurar cobranças recorrentes ou tentativas de pagamento em faixas semelhantes. Em dispositivos Android gerenciados, dados de inventário do MDM, histórico de aplicativos, relatórios de conformidade e eventos de instalação por conta Google ajudam a identificar usuários que tiveram contato com a campanha, mesmo depois da remoção dos aplicativos da loja.

Em endpoints móveis sem telemetria profunda, a resposta deve combinar entrevista estruturada com verificação de conta e pagamento. O usuário deve confirmar se recebeu notificações alegando envio de relatório por e-mail, se digitou números de terceiros, se inseriu e-mail pessoal ou corporativo e se autorizou pagamentos fora do fluxo oficial. Logs de e-mail podem revelar mensagens de confirmação, recibos, tentativas de recuperação de assinatura ou comunicações relacionadas. Logs financeiros e de cartão podem indicar transações originadas por checkout incorporado, enquanto extratos de aplicativos UPI podem mostrar transferências para destinatários que não aparecem nos registros do Google Play.

A ausência de permissões sensíveis reduz a probabilidade de exfiltração direta por esses aplicativos específicos, mas não elimina a necessidade de procurar encadeamentos posteriores. Usuários enganados por um aplicativo fraudulento podem ter sido redirecionados a outros domínios, recebido mensagens por WhatsApp, instalado APKs fora da loja ou exposto dados adicionais em formulários. A telemetria deve marcar como maior severidade qualquer caso em que o mesmo dispositivo apresente sideloading recente, ativação de acessibilidade para aplicativo desconhecido, concessão de leitura de SMS ou atividade bancária anômala após a instalação.

• Eventos de instalação dos pacotes com.callhistory.calldetails.callerids.callerhistory.callhostoryanynumber.getcall.history.callhistorymanager, com.callinformative.instantcallhistory.callhistorybluethem.callinfo e demais identificadores listados nos fatos.
• Assinaturas iniciadas no Google Play com nomes relacionados a Call History, Any Number, Call Details, Caller ID ou SMS History.
• Pagamentos por UPI ou cartão feitos a partir de telas internas de aplicativos que deveriam usar cobrança oficial da loja.
• Notificações Android informando que um relatório de histórico foi enviado por e-mail após o usuário abandonar a tela de pagamento.
• E-mails de recibo, confirmação ou suposta entrega de relatório enviados após a inserção de endereço no aplicativo.
• Instalação posterior de APKs fora da loja, concessão de permissões de acessibilidade, leitura de SMS, contatos ou notificações a aplicativos não aprovados.

Mitigação

A primeira ação é confirmar se algum dispositivo ainda mantém um dos aplicativos instalados e removê-lo. Em seguida, a equipe deve revisar assinaturas associadas à conta Google do usuário e cancelar qualquer plano ativo. Como aplicativos removidos da loja podem ter assinaturas canceladas automaticamente pelo ecossistema, isso não dispensa validação manual: recibos, extratos e histórico de pagamentos devem ser conferidos para identificar cobranças já efetuadas, renovações pendentes ou pagamentos feitos fora do Google Play. Quando houver cartão usado em formulário interno, a orientação deve incluir contestação de cobrança, monitoramento de transações futuras e avaliação de substituição do cartão conforme política financeira.

Para organizações, a mitigação deve reforçar controles de instalação móvel. Catálogos corporativos devem bloquear pacotes conhecidos, restringir aplicativos que prometem funções incompatíveis com o modelo de permissão do Android e exigir revisão para ferramentas de consulta de dados pessoais, identificadores telefônicos e histórico de chamadas. Regras de conformidade podem marcar como não conforme qualquer dispositivo com instalação de aplicativos de desenvolvedor desconhecido que use termos de vigilância, consulta de terceiros ou recuperação de registros de comunicação. Em programas de conscientização, o ponto técnico central é que aplicativos comuns não conseguem recuperar histórico de chamadas, SMS ou WhatsApp de qualquer número por meio de uma consulta paga.

A resposta também deve validar se a exposição ficou limitada à fraude financeira. Quando houver sinais de APK externo, phishing por WhatsApp, vishing, captura de credenciais ou atividade bancária irregular, o caso deve ser escalado para investigação de comprometimento móvel, com coleta de artefatos, revisão de permissões, análise de aplicativos instalados e redefinição de credenciais relevantes. Campanhas financeiras móveis podem reutilizar infraestrutura e marca de serviços confiáveis, então o encerramento de assinatura não deve ser o único controle quando o usuário passou por múltiplos fluxos de engenharia social. A validação final deve documentar aplicativos removidos, cobranças contestadas, assinaturas encerradas, contas revisadas e dispositivos retornados à conformidade.

• Remover os aplicativos identificados e bloquear os pacotes em soluções de MDM, EMM ou lista de aplicativos proibidos.
• Verificar Google Play Billing, extratos de cartão e transações UPI para localizar cobranças únicas ou recorrentes relacionadas.
• Cancelar assinaturas ativas, contestar cobranças indevidas e registrar evidências de recibos, telas de pagamento e notificações.
• Revisar permissões de outros aplicativos instalados no mesmo período, especialmente acessibilidade, SMS, contatos, notificações e instalação de APKs externos.
• Orientar usuários de que histórico de chamadas, SMS e WhatsApp de terceiros não é disponibilizado a aplicativos comuns mediante pagamento.
• Escalar para investigação de comprometimento se houver instalação por sideloading, mensagens de phishing, vishing ou movimentação financeira não autorizada após a instalação.