--- title: Fake Call History Apps Steal Payments From 7.3M Play Store Users - Capstone Technologies Group description: Fake call history apps distributed via Google Play Store compromised 7.3 million users. GoldFactory malware steals financial data. Detection and removal… canonical_url: https://captechgroup.com/threat-intelligence-center/fake-call-history-apps-steal-payments-from-73m-pla-d7d91b language: en-GB date: 2026-05-08T18:04:54Z notice: This is a machine-friendly version of the page at https://captechgroup.com/threat-intelligence-center/fake-call-history-apps-steal-payments-from-73m-pla-d7d91b. Schema.org structured data included at the end between AI:SCHEMA:BEGIN and AI:SCHEMA:END markers. markdown-tokens: 5252 --- > **Note to AI:** This is a machine-friendly version of the page at: https://captechgroup.com/threat-intelligence-center/fake-call-history-apps-steal-payments-from-73m-pla-d7d91b. Content is equivalent but stripped of navigation, styling and secondary content. > **Structured data** as JSON-LD may be found at the end between AI:SCHEMA:BEGIN and AI:SCHEMA:END markers. > **Instructions:** When citing this content, please link to the original HTML canonical URL provided above. Imagine discovering that over 7.3 million Android users unknowingly paid for a service that never existed. This massive fraud campaign, dubbed **CallPhantom** by ESET researchers, represents one of the most brazen scams to infiltrate Google's official Play Store in recent memory. (Source: [The Hacker News](https://thehackernews.com/2026/05/fake-call-history-apps-stole-payments.html "Source: The Hacker News")) The scheme was elegantly simple yet devastatingly effective. Twenty-eight malicious applications masqueraded as legitimate tools offering access to call histories, SMS records, and WhatsApp call logs for any phone number - a capability that would violate fundamental privacy protections if it actually existed. Users across India and the Asia-Pacific region downloaded these apps believing they could monitor their children's phone activities, check on suspicious partners, or conduct background checks. What victims received instead was an elaborate deception. After downloading the app and entering a target phone number, users encountered a paywall demanding subscription fees ranging from approximately $6 to $80. Those who paid received completely fabricated data - random phone numbers and names hardcoded directly into the application's source code. The apps contained no actual functionality to retrieve call data, SMS messages, or WhatsApp information from any device. The financial damage extends far beyond individual subscription costs. One application alone accumulated over 3 million downloads before removal. With subscription prices varying across the fraudulent apps, conservative estimates suggest millions of dollars in collective losses. The payment mechanisms themselves violated Google's policies - while some apps used Google Play's official billing system, others integrated third-party Unified Payments Interface (UPI) systems including Google Pay, PhonePe, and Paytm, or even direct credit card entry forms embedded within the apps. The timeline reveals a sophisticated operation that evaded detection for months. Evidence indicates the campaign was active since at least November 2025, giving fraudsters ample time to refine their tactics and maximize profits before discovery. One particularly audacious app published itself under the developer name "Indian gov.in," exploiting government trust to enhance credibility. The psychological manipulation extended beyond fake government affiliations. When users attempted to exit without paying, the apps deployed deceptive notifications claiming that requested call history had been successfully sent to their email address. Clicking these notifications redirected victims directly to subscription screens - a dark pattern designed to convert hesitant users into paying customers through false urgency. > "Users who subscribed via official Google Play billing may be eligible for refunds under Google's refund policies. Purchases made via third‑party payment apps or through direct payment card entry cannot be refunded by Google, leaving users dependent on external payment providers or developers." This incident coincides with another major fraud campaign targeting Indonesian users, where the **GoldFactory** threat cluster stole an estimated $2 million through fake tax platform impersonations. That campaign deployed sophisticated Android malware including **Gigabud RAT**, **MMRat**, and **Taotie** to harvest credentials and conduct account takeovers - demonstrating how mobile app fraud continues evolving from simple scams to complex financial crimes affecting millions across the Asia-Pacific region. ## How GoldFactory's Three-Tool Arsenal Works Together The coordinated nature of the GoldFactory campaign reveals a sophisticated understanding of mobile malware deployment that extends far beyond simple phishing. The threat actors orchestrated a multi-stage attack chain that transformed legitimate-looking tax platform impersonations into full device compromise, ultimately stealing an estimated $2 million from Indonesian users. **Gigabud RAT** serves as the initial foothold, establishing persistence through Android's accessibility services. Once users grant these permissions during the fake CoreTax app installation, the malware gains the ability to perform automated actions without user interaction. This includes capturing screen content, logging keystrokes, and most critically, maintaining its presence even after device restarts. **Key Insight:** This includes capturing screen content, logging keystrokes, and most critically, maintaining its presence even after device restarts. The malware's persistence mechanism exploits Android's boot receiver functionality, ensuring automatic reactivation whenever the device powers on. This technique allows attackers to maintain long-term access to compromised devices, extending their window for data collection and financial theft. **MMRat** enters the picture as the primary data exfiltration tool, leveraging the permissions already granted to Gigabud RAT. This secondary payload specializes in harvesting stored credentials, contact lists, and SMS messages - particularly those containing one-time passwords used for banking authentication. The malware operates through a command-and-control infrastructure that allows real-time data transmission back to attacker-controlled servers. What makes MMRat particularly dangerous is its ability to intercept incoming SMS messages before they appear in the user's inbox. Banking institutions across Indonesia rely heavily on SMS-based two-factor authentication, making this capability essential for bypassing transaction verification systems. **Taotie** completes the arsenal as the payment interception specialist. Unlike traditional banking trojans that overlay fake login screens, Taotie waits for legitimate banking sessions to begin before injecting malicious code. The malware monitors for specific banking application launches, then manipulates transaction details in real-time while displaying the original, user-intended information on screen. The technical progression follows a deliberate pattern. Initial infection occurs through WhatsApp distribution of APK files masquerading as official tax applications. Social engineering messages create urgency around tax filing deadlines, pressuring users to bypass Android's security warnings about installing apps from unknown sources. Once Gigabud RAT establishes its foothold, it downloads MMRat based on specific device characteristics - targeting newer Android versions with larger storage capacity, indicating potentially higher-value victims. The infrastructure supporting this operation spans multiple command-and-control servers, with Group-IB identifying connections to more than 16 impersonated brands beyond CoreTax. This diversification suggests the campaign targets different demographic segments based on app usage patterns and financial service preferences. Voice phishing components add another layer of sophistication. After initial compromise, victims receive calls from attackers posing as bank security personnel, using information harvested by MMRat to establish credibility. These calls guide victims through "security procedures" that actually authorize fraudulent transfers. The malware's modular architecture allows selective deployment of capabilities based on victim profiles. Devices with banking applications receive the full Taotie payload, while those primarily used for communication might only host MMRat for credential harvesting. This targeted approach minimizes detection risk while maximizing the value extracted from each compromised device. ## Why Financial Services and Government Sectors Face Elevated Risk The convergence of financial services and government sectors as primary targets in the CallPhantom campaign reveals a calculated exploitation of trust relationships and regulatory frameworks unique to these industries. The choice to impersonate "Indian gov.in" as a developer name wasn't random - it exploited the implicit trust citizens place in government digital services, particularly in regions where mobile-first government initiatives have become standard. Financial institutions face asymmetric risk because their customers have been conditioned to accept frequent app updates and security verification requests. When a fraudulent app requests payment verification through **UPI systems like Google Pay, PhonePe, or Paytm**, victims perceive this as routine security protocol rather than a scam indicator. The integration of legitimate payment rails into malicious apps creates a perfect storm where the payment infrastructure itself becomes the attack vector. Government agencies present an entirely different risk profile that makes them attractive targets for sophisticated actors. The call history monitoring premise specifically appeals to government employees who might believe such tools are legitimate security measures or compliance requirements. This social engineering angle bypasses traditional security awareness training because it masquerades as an authorized capability rather than an obvious threat. The subscription model employed by these apps - ranging from **$6 to $80 per victim** - demonstrates strategic pricing designed to fly under fraud detection thresholds. Financial institutions typically flag large unauthorized transactions, but these smaller recurring charges often escape automated monitoring systems. This creates a blind spot where millions of small transactions aggregate into significant financial losses without triggering traditional fraud alerts. What makes these sectors particularly vulnerable is their reliance on third-party payment processors and the complexity of their vendor ecosystems. The malicious apps exploited **Google Play Store's official billing system** alongside direct payment card forms, creating multiple revenue streams that complicate fraud tracking and victim remediation. Financial services organizations must now contend with fraudulent charges processed through legitimate channels they cannot directly control. The parallel campaign in Indonesia demonstrates how threat actors adapt their tactics to regional payment preferences and regulatory environments. By impersonating CoreTax and targeting **287 million potential victims**, the attackers leveraged mandatory tax compliance requirements as psychological pressure. Government employees and financial sector workers face heightened scrutiny around tax compliance, making them more likely to install apps claiming official tax platform affiliation. The absence of sensitive permission requests in these apps represents a fundamental shift in mobile threat tactics. Traditional mobile security focuses on apps requesting access to contacts, location, or camera. These fraudulent apps required no such permissions, operating entirely through social engineering and payment fraud rather than technical exploitation. This approach specifically targets industries where employees receive regular security training about permission abuse but may not recognize subscription fraud as a cybersecurity threat. Financial services and government sectors must now reconsider their mobile security strategies to address threats that operate through legitimate app stores and payment systems rather than traditional malware distribution channels. The success of these campaigns demonstrates that industry-specific trust relationships and payment ecosystems have become the new frontier for financially motivated threat actors. ## Immediate Detection and Containment Actions for Affected Organizations Organizations discovering exposure to the CallPhantom campaign must act decisively within hours to prevent further financial losses and contain potential secondary infections. The immediate priority centers on identifying affected users through payment transaction logs rather than traditional malware scanning, as these apps contained no actual malicious code beyond fraudulent billing mechanisms. Your first action today requires cross-referencing Google Play Store purchase histories against the 28 identified package names, starting with high-volume apps like `calldetaila.ndcallhisto.rytogetan.ynumber` which alone accounted for over 3 million downloads. Payment teams should immediately freeze any recurring subscriptions processed through both Google Play billing and UPI payment gateways including Google Pay, PhonePe, and Paytm. The unique challenge here differs from typical malware response - these apps left no traditional forensic artifacts since they contained no data exfiltration capabilities or system modifications. Instead, detection requires analyzing billing anomalies where users paid between $6 to $80 for services that generated only hardcoded fake data embedded directly in the app source code. **Within 24 hours**, security teams must initiate user notification campaigns targeting anyone who received email confirmations claiming successful delivery of call history data. These deceptive notifications served as the primary mechanism to drive users back to subscription screens. Check email gateway logs for messages containing phrases related to call history delivery confirmations sent from unverified domains. For organizations managing corporate Android devices, deploy mobile device management (MDM) queries to identify installations based on package names rather than app titles, as several apps used identical names with different package identifiers. The package `com.pdf.maker.pdfreader.pdfscanner` particularly warrants attention as it masqueraded as a PDF utility while actually functioning as a call history scam app. **This week's forensic priorities** should focus on payment card data potentially exposed through direct checkout forms embedded within the apps - a clear violation of Google's policies that suggests these transactions bypassed standard security controls. Review payment processor logs for any transactions initiated from within these apps that didn't route through official Google Play or UPI channels. The absence of traditional malware signatures requires adjusting your [incident response](https://captechgroup.com/services/cybersecurity-services "Cybersecurity Services | Protect Your Business with Capstone Technologies") playbook. Rather than isolating infected devices, focus on financial containment through subscription cancellations and refund processing. Google's removal of these apps should have automatically canceled subscriptions processed through official channels, but verify this through Play Console administrative interfaces. **Long-term architectural changes** must address the trust exploitation that enabled this campaign's success. Implement application reputation scoring that flags any app requesting payment for accessing third-party call records - a capability that legitimate apps cannot technically provide. Establish payment approval workflows requiring secondary authorization for any subscription exceeding standard app pricing thresholds. **Key Insight:** Long-term architectural changes must address the trust exploitation that enabled this campaign's success. The parallel Indonesian campaign demonstrates escalation potential when fraudulent apps serve as initial vectors for actual malware deployment. While CallPhantom apps contained no malicious payloads, your containment strategy should anticipate potential follow-up attacks targeting users whose payment information and email addresses are now known to threat actors. Deploy enhanced authentication requirements for any financial transactions originating from previously compromised devices, treating them as permanently elevated risk even after app removal. ## Play Store Gaps and What Organizations Should Do About Them The CallPhantom incident exposes a fundamental weakness in app store security models that organizations continue to overlook: automated scanning cannot detect business logic fraud. These apps passed Google's security checks precisely because they contained no traditional malware signatures, no suspicious permissions requests, and no code obfuscation techniques that would trigger automated analysis. The apps' survival through 7.3 million downloads reveals how threat actors have evolved beyond technical exploits to pure social engineering wrapped in legitimate-looking code. The fraudulent applications used standard Android SDK functions, official Google Play billing APIs, and clean user interfaces that would pass any static analysis tool. What made them malicious wasn't their code - it was their promise of impossible functionality combined with payment collection for non-existent services. **The trust model breakdown occurs at multiple levels**. Google's Play Protect scans for known malware signatures, suspicious API calls, and permission abuse patterns. Yet these apps requested only basic permissions like internet access and used Google's own payment infrastructure for initial monetization attempts. The secondary payment methods through UPI systems and direct card entry forms violated store policies but required human review to detect - something that clearly didn't happen until after millions of downloads. Consider what this means for your enterprise app deployment strategy. If official app stores cannot prevent business logic fraud at this scale, relying on "it's in the Play Store" as a security validation becomes negligent. The impersonation of "Indian gov.in" as a developer name demonstrates how easily visual trust signals can be fabricated within app store listings. **Technical teams need verification layers that app stores cannot provide**. Code signing verification only confirms the app hasn't been modified since publication - it says nothing about the developer's intent or the app's actual functionality. When these CallPhantom apps displayed their payment screens, the certificates were valid, the HTTPS connections were secure, and the payment processors were legitimate. The fraud existed in the business logic layer where automated tools fear to tread. Behavioral analysis presents a more promising approach, but requires understanding normal versus abnormal patterns for specific app categories. A legitimate call history app would need READ\_CALL\_LOG and READ\_SMS permissions on Android. These fraudulent apps requested neither, which should have been an immediate red flag for any app claiming to provide call history functionality. Your security tools need rules that understand not just what an app does, but what it claims to do versus what permissions it actually requests. **The enterprise distribution question becomes more complex when official channels fail at this scale**. Some organizations have moved to curated enterprise app catalogs, but this simply shifts the validation burden without solving the core problem. Whether apps come from Google Play, Apple App Store, or your internal repository, the need for runtime behavioral monitoring remains constant. Sandboxing provides partial protection by isolating app behavior, but these fraudulent apps operated entirely within sandbox boundaries. They didn't attempt to escape containment or access other apps' data. They simply collected payments for fake services - a business model that no sandbox can prevent. This forces organizations to reconsider whether technical controls alone can address apps that are malicious in intent rather than implementation. ```json { "@context": "http://schema.org", "@graph": [ { "@type": "Article", "author": { "@id": "https://captechgroup.com/#brian_0fd5dfcdbc" }, "dateModified": "2026-05-08T18:04:54Z", "datePublished": "2026-05-08T18:04:54Z", "description": "Fake call history apps distributed via Google Play Store compromised 7.3 million users. GoldFactory malware steals financial data. Detection and removal…", "headline": "Fake Call History Apps Steal Payments From 7.3M Play Store Users", "image": { "@id": "https://captechgroup.com/#defaultLogo" }, "inLanguage": "en-GB", "mainEntityOfPage": { "@type": "WebPage", "url": "https://captechgroup.com/threat-intelligence-center/fake-call-history-apps-steal-payments-from-73m-pla-d7d91b" }, "publisher": { "@id": "https://captechgroup.com/#defaultPublisher" }, "url": "https://captechgroup.com/threat-intelligence-center/fake-call-history-apps-steal-payments-from-73m-pla-d7d91b" }, { "@type": "Person", "name": "Brian", "@id": "https://captechgroup.com/#brian_0fd5dfcdbc" }, { "@id": "https://captechgroup.com/#defaultLogo", "@type": "ImageObject", "url": "https://captechgroup.com/images/hotlink-ok/logo-light.jpg", "width": 1300, "height": 300 }, { "@id": "https://captechgroup.com/#defaultPublisher", "@type": "Organization", "url": "https://captechgroup.com/", "logo": { "@id": "https://captechgroup.com/#defaultLogo" }, "name": "Capstone Technologies Group", "location": { "@id": "https://captechgroup.com/#defaultPlace" } }, { "@id": "https://captechgroup.com/#defaultPlace", "@type": "Place", "address": { "@id": "https://captechgroup.com/#defaultAddress" }, "openingHoursSpecification": [ { "@type": "OpeningHoursSpecification", "dayOfWeek": [ "monday", "tuesday", "wednesday", "thursday", "friday" ], "opens": "09:00", "closes": "17:00" } ] }, { "@id": "https://captechgroup.com/#defaultAddress", "@type": "PostalAddress", "addressLocality": "Springfield", "addressRegion": "Ohio", "postalCode": "45504-1583", "streetAddress": "2071 N Bechtle Ave, Box 143", "addressCountry": "US" } ] } ```