Unexplained Mobile Network Traffic: Update or Malware?

When a phone or tablet suddenly moves a lot of network data, the deciding question is what generated the traffic and when. Legitimate OS and app updates are bursty, scheduled, attributable to the system updater or app store in the device’s own per-app data logs, and they stop when the download finishes. Malware traffic is the opposite: continuous or repeating, attributed to an app that has no business talking to the internet, and active at times when the device should be idle. A technician settles the question by checking the device’s per-app data usage against its update history — before reaching for any removal tool.

Where the evidence lives on the device

Both Android and iOS meter data per application, and this attribution is the single most useful evidence when investigating a traffic spike. On Android it is under Settings → Network & internet → Data usage (with per-app Wi-Fi and cellular breakdowns); on iOS under Settings → Cellular. Managed devices report the same telemetry to a Mobile Device Management (MDM) console, which adds timestamps and history.

The first thing to review is which app owns the spike and when it occurred:

• If the traffic belongs to the OS update service or the app store, and the timing lines up with the platform’s update window or the organization’s patch schedule, the spike is almost certainly a legitimate update. Cross-checking the device’s update history (Settings → System → System update on Android; Settings → General → Software Update on iOS, plus the app store’s update log) confirms it: an update entry stamped at the same time as the spike closes the case.
• If the traffic belongs to a user app that shouldn’t be chatty — a flashlight tool, a wallpaper app, a game the user doesn’t recall installing — or the “app” is unnamed or generic, the investigation shifts to compromise.

This is why “check what was scheduled” beats every other first move. Running an antivirus scan, wiping the device, or blocking the network might eventually be right, but none of them answer the actual question, and a wipe destroys the evidence.

Update traffic vs. malware traffic

Characteristic	Legitimate update	Likely malware
Shape	One burst, then stops	Continuous or repeating beacons
Timing	Matches update window / patch schedule	Idle hours, overnight, no schedule match
Attribution	OS updater, app store, known app updating	Unknown app, sideloaded app, or unattributed
Duration	Bounded — ends when download completes	Open-ended, persists across reboots
Corroboration	Entry in update history at the same time	No matching update entry anywhere

The “bounded vs. open-ended” row is the sharpest discriminator. Consider a single-purpose device: a manufacturing-floor tablet locked to one approved inventory app, sitting on its charging dock overnight, showing continuous high Wi-Fi traffic. An update cannot explain that — updates finish. Continuous traffic from an idle, single-app device means something unapproved is running: malware exfiltrating data, a cryptominer, or an unauthorized app phoning home. Idle single-purpose devices have essentially flat baselines, so any sustained deviation is a red flag, not a quirk.

The wider symptom cluster

Unexplained traffic rarely travels alone. The mobile-malware indicators A+ Core 2 expects you to recognize as one cluster:

• High network traffic the user can’t explain (the topic of this article).
• Rapid battery drain and a device that runs hot — background processes burning CPU and radio. See phone battery drain for separating malware drain from ordinary causes.
• Data-usage limit notifications arriving far earlier in the billing cycle than normal.
• Pop-ups, fake antivirus warnings, and browser redirects.
• Apps the user did not install, or an enabled “install unknown apps” / developer setting the user never touched — evidence of sideloading, installing apps from outside the official store.
• Sluggish performance and random crashes.
• Leaked or accessed personal data noticed downstream (password-reset emails, odd account activity).

On Android, sideloading is the classic infection path: the user is socially engineered into enabling installation from unknown sources, installs a trojanized Android Package (APK) from a link or third-party store, and grants it broad permissions. The app then runs in the background, generating exactly the traffic pattern described above. A permissions review (why does a wallpaper app hold SMS and Contacts access?) often exposes it.

Investigation sequence for a suspect device

1. Review per-app data usage — identify the app and timestamps behind the spike.
2. Compare against update history and any organizational patch schedule. A match ends the investigation.
3. Inventory installed apps — look for unknown, duplicate, or sideloaded entries, and check whether unknown-sources installation was enabled.
4. Review app permissions for grants that don’t fit the app’s purpose.
5. Run a reputable mobile anti-malware scan (or check the MDM’s compliance/threat report on managed devices).

Remediation on a confirmed compromise

For a personal device: uninstall the offending app (boot to safe mode on Android if it resists), revoke its device-administrator rights if it claimed any, disable unknown-sources installation, run a full scan, change passwords for accounts used on the device, and if trust can’t be re-established, back up user data and factory reset. The desktop analog of this cleanup is the CompTIA seven-step malware removal procedure, which the exam tests in the same spirit: contain, clean, then restore trust.

For a corporate-managed device the playbook is stricter and runs through policy: report the incident per the organization’s procedures, let the MDM quarantine or isolate the device from corporate resources, then remote wipe and re-enroll rather than spot-cleaning — on managed hardware, provable cleanliness beats salvage. The technician also documents what the indicators showed and how the infection likely arrived (typically a sideloaded app or malicious link), because that feeds user education: the durable fix is the user no longer enabling unknown sources or clicking installer links.

How the 220-1202 exam tests this

• A scenario gives you a traffic spike at a specific time and asks for the MOST useful evidence to review FIRST — the answer is the device’s per-app data usage and update logs (attribution + timing), never “wipe it” or “run a scan” as the opening move.
• A single-purpose or kiosk device (one approved app, idle on a dock) shows continuous high traffic, and the question asks for the most likely explanation — testing whether you know updates are bounded bursts, so sustained idle traffic implies malware or an unauthorized app.
• A performance-based item hands you several indicators from a managed Android phone (data spike, unknown app, unknown-sources enabled, battery drain) and asks you to reconstruct what happened, how it got there (sideloading), and the correct remediation (report, quarantine, wipe/re-enroll per policy) — exactly the kind of multi-indicator stem worth rehearsing in a practice exam bank.
• A symptom-cluster question lists battery drain + pop-ups + high data and asks you to name the common cause, checking that you group these as mobile-malware indicators rather than treating each in isolation.

Mobile malware sits at the intersection of the Security and Software Troubleshooting domains — the full 220-1202 study guide shows how the exam splits its weight between them.

Quick reference

• First evidence to review: per-app data usage attribution and timestamps, cross-checked against OS/app update history.
• Update traffic: one bounded burst, attributed to the updater/app store, matches a schedule.
• Malware traffic: continuous or repeating, attributed to an unknown/sideloaded app, active while idle.
• A single-app kiosk device with sustained idle traffic is presumed compromised — updates finish; malware doesn’t.
• Mobile malware cluster: high data, battery drain/heat, pop-ups, unknown apps, sluggishness, leaked data.
• Sideloading (unknown-sources APK installs) is the classic Android infection vector; check permissions and install source.
• Corporate device remediation: report → quarantine via MDM → wipe and re-enroll; document and educate the user.
• Never wipe before capturing evidence — the data logs are the investigation.