Mobile T1643 Generate Traffic from Victim: Detecting Billing and Ad Fraud on Phones

Some mobile malware does not steal data at all: it quietly uses the victim's phone to send premium SMS, sign up for carrier billed services or click adverts, and the victim pays the bill. MITRE ATT&CK for Mobile tracks this as T1643 Generate Traffic from Victim, an Impact technique in which outbound traffic is generated from devices to manipulate external outcomes such as carrier billing fraud or app store rankings and ratings. ATT&CK lists it for Android and iOS. This guide explains the three fraud patterns behind the technique, the store and OS controls that cut them back, and how enterprises and app owners detect and respond. It is for mobile security teams, fraud teams and app store or ad operations staff, and builds on the MITRE ATT&CK for Mobile Guide.

Key takeaways

• Three patterns, one technique. ATT&CK v20 folds the former Carrier Billing Fraud, Generate Fraudulent Advertising Revenue and Manipulate App Store Rankings or Ratings techniques into T1643.
• SMS fraud needs a permission Google now restricts. Android apps must hold SEND_SMS, premium numbers need user consent, and Google Play limits SMS permissions to default SMS, Phone or Assistant handlers plus listed exceptions.
• iOS apps cannot send SMS. ATT&CK states this plainly, so on iOS the technique is about web and ad traffic, not premium messages.
• Attackers moved to web billing. Google reports that the Bread (Joker) family switched from SMS fraud to WAP billing after the SEND_SMS restriction and better Play Protect coverage.
• Device checks do not prove consent. Carrier and payment flows that only confirm a request came from the device can be automated by malware; confirm intent with the user.

The three fraud patterns

Case detail: Google's Android security team described Bread (also known as Joker) in January 2020. Early versions had phones text a premium shortcode; newer versions sent users to carrier payment pages, where the carrier verified the request through mobile data or an SMS code. Google's point was that these checks confirm the request came from the device, not that the user intended it, and malware automated the steps. Play Protect removed about 1.7 thousand unique Bread apps from the Play Store before users downloaded them.

For the advertising side of the problem beyond phones, see Ad fraud and connected TV ad fraud. For SMS abuse aimed at your own verification flows, see Phone Number Fraud.

Platform controls: Android and iOS

Prevention

1. Control what gets installed (M1012 Enterprise Policy): allow list apps on managed devices and disable unknown sources on Android; many of the families above spread through repackaged or sideloaded apps.
2. Keep Play Protect on and devices current (M1001, M1006): scanning and OS updates remove known families quickly.
3. Block premium services at the carrier: for corporate lines, ask the carrier to bar premium SMS and third party carrier billing. This is the most direct control on the billing pattern.
4. Coach users (M1011 User Guidance): ATT&CK advises telling users that apps generally do not need permission to send SMS.
5. For app and service owners: confirm billing or subscription intent with a user step that malware cannot read from the device, and rate limit actions per device and account. Treat review and install spikes with fake looking reviews as a fraud signal, as Google did with Bread.

Where identity fits: ad networks, carrier billing APIs and app store review systems all trust device and app identifiers. Fraud traffic exploits that trust, so server side checks should treat device level signals as one input, not as proof of a human. See the Mobile App Attestation.

Detection and measurement

ATT&CK detection strategy DET0608 has Android and iOS analytics. On Android it correlates dynamic vetting traces of SmsManager.sendTextMessage called by an app outside the approved messaging apps, Android Enterprise network logs (DnsEvent and ConnectEvent) or VPN flow data, and permission grant state. On iOS it correlates MDM installed and managed application lists with Network Extension or per-app VPN flow metadata.

Metrics: monthly premium or carrier billing charges on corporate lines (target zero); count of non-messaging apps holding SEND_SMS; percentage of fleet with app allow listing; percentage of Android devices with Play Protect on; time from detection to app removal.

Response

1. Identify the app from MDM inventory and network logs, and remove it across the fleet.
2. Ask the carrier to block premium services and dispute fraudulent charges; keep invoices as evidence.
3. Check whether the same app requested other sensitive permissions (SMS read, notifications, accessibility) and, if so, rotate credentials and one-time code channels it could reach.
4. Report the app to the store so it can be taken down for other users.
5. Add the package and domains to blocklists and update app vetting rules.

Common failure patterns

• Nobody reads the phone bill: premium charges on corporate lines go unnoticed for months.
• Trusting store presence: Google's own reporting shows Bread apps submitted to Play at up to 23 a day at peak.
• Static app checks only: Google notes Bread used encryption, reflection, native code and server side cloaking, so behaviour needs dynamic analysis.
• Billing flows that trust the device: device confirmation alone is not user consent.
• Ignoring ad SDK behaviour: hidden ad traffic drains battery and data and signals a compromised app.

Framework mapping

Practitioner checklist

• Bar premium SMS and third party carrier billing on corporate lines.
• Review carrier invoices monthly for premium charges.
• Alert on SEND_SMS held by any non-messaging app.
• Allow list apps and disable unknown sources on managed Android.
• Feed network logs or VPN flows into detection for ad and billing domains.
• Vet apps dynamically, not only statically.
• Confirm billing intent with the user in your own apps and services.

Standards and references

• MITRE ATT&CK: T1643 Generate Traffic from Victim (Mobile)
• Google Play Console Help: Use of SMS or Call Log permission groups
• Google Play Help: Use Google Play Protect
• Google Security Blog: PHA Family Highlights, Bread (and Friends)
• Google: Google Play Protect

Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide · Mobile Malware Guide · Ad fraud and connected TV ad fraud · Mobile Threat Defense Buyer's Guide