---
title: "Midnight Mimosa: Proxy Malware Pre-Installed on Android Phones"
description: "Midnight Mimosa malware ships in the firmware of low-cost Android phones, enabling ad fraud and residential proxies. Learn the risks, detection and defences."
url: "https://www.gowrishankar.me/blog/midnight-mimosa-preinstalled-android-proxy-malware"
author: "Gowri Shankar Balasubramaniam"
published: 2026-10-08T20:56:36.685Z
category: "Mobile Security"
tags: ["Ad Fraud","Android Security","BYOD Security","Bitdefender","Firmware Malware","MediaTek","Midnight Mimosa","Mobile Device Management","Play Integrity","Pre-installed Malware","Residential Proxy","Supply Chain Attack","Third-Party Risk Management","Threat Intelligence","Zero Trust"]
---

# Midnight Mimosa: Proxy Malware Pre-Installed on Android Phones

> Some budget Android phones are compromised before they leave the box. The Midnight Mimosa campaign puts malicious code directly into device firmware, where it gains system-level privileges, commits ad fraud, and turns phones into residential proxies. This post explains how the framework works, why it is a supply-chain risk for enterprises, and what users, security teams and procurement leaders should do.

## When the threat ships in the box

Some budget Android phones are compromised before their owners ever power them on. Bitdefender has documented a campaign it calls Midnight Mimosa, in which malicious code is baked into the firmware of low-cost devices, as [reported by BleepingComputer](<https://www.bleepingcomputer.com/news/security/low-cost-android-phones-ship-with-residential-proxy-malware/>) on 8 October 2026.

This inverts the usual mobile threat model. Most guidance assumes the device is trustworthy and the danger arrives later through a malicious app, link or download. Here, the operating system image itself is the attacker's foothold, and the user did nothing wrong.

For security teams, the lesson reaches beyond one malware family. Hardware supply-chain integrity is now a practical endpoint-security concern, not only a procurement footnote.

## What researchers found

Midnight Mimosa has reached thousands of devices in more than 150 countries over roughly two years. Infections cluster in Mexico, France, Italy, the United States, Germany, Brazil and Spain, according to [Bitdefender's analysis](<https://www.bitdefender.com/en-us/blog/labs/midnight-mimosa-malware>).

| Attribute | Reported detail |
| --- | --- |
| Affected hardware | Low-cost Android phones built on MediaTek chipsets |
| Named models | Doogee S200 X, Cubot KINGKONG X, plus devices posing as Samsung or Apple products |
| Location of malware | System partition, running with system-level privileges |
| Disguised package names | com.android.system.lite, com.android.sys.prot, com.android.sys.gmsprot, com.android.non.szcz |
| Payload apps | About 32 modules, posing as weather, file manager, app lock, OCR and audio tools |
| Google Play spillover | 13 apps sharing the ad-fraud code and infrastructure |
| Firmware signing | Certificates linked to Shenzhen Zediel; involvement unconfirmed |

User reports on [XDA Forums](<https://xdaforums.com/t/need-help-identifying-com-android-sys-extplv-google-play-installed-package-on-cubot-kingkong-x.4793574/>) add an uncomfortable detail. One owner said an official firmware update introduced the infection, which vanished on rollback and returned on re-update. Some vendors have since shipped clean updates, but none has explained publicly how the code got in.

## How the framework operates

The firmware component is a loader, not the money-maker. It pulls modules from command-and-control (C2) servers and installs them silently, so the operators can change what infected phones do at any time.

- **Persistence through the system image.** The loader is a signed system app, so the standard uninstall path cannot remove it, and a factory reset restores it.
- **Defense evasion.** Before a silent install, it briefly disables the Play Store package (com.android.vending) to keep Google Play Protect from inspecting the new app, then re-enables it. Some variants also falsify the recorded installer so dropped apps appear to come from Google Play.
- **Monetisation through ad fraud.** Dropped "cover" apps load real ads from a legitimate ad SDK inside invisible overlay windows, generating impressions and clicks the user never sees.
- **Residential proxy capability.** A fake app locker (com.mobile.applock.en) carries a TCP proxy that registers the phone with a C2 server and can be told to relay traffic to arbitrary hosts.

### Why residential proxies are valuable

Traffic from a home or mobile connection looks like an ordinary consumer. Fraud, credential-stuffing and scraping operators rent such exit nodes because they evade IP-reputation filters, geo-blocks and rate limits that stop datacenter IP ranges.

Bitdefender confirmed the proxy C2 was live and accepting registrations. Its test device received no relay targets, so active traffic forwarding is not yet proven. The capability, however, is fully in place.

## The supply-chain blind spot

Nobody has yet identified where the tampering happened, and that uncertainty is the core risk. Budget Android devices typically pass through several parties: a chipset vendor's reference image, an original design manufacturer (ODM), the branded vendor, and often third-party firmware or OTA update providers.

Each handoff is a point where code can be added and then signed as legitimate. Once a malicious component is signed with a platform key, Android treats it as part of the operating system. The trust model works as designed; it is simply anchored to a compromised party.

The Midnight Mimosa pattern echoes earlier cases such as Triada and the BADBOX operations, which also abused pre-installed firmware on inexpensive Android hardware. The recurrence suggests a systemic weakness in low-margin device ecosystems rather than a one-off incident.

The reported reinfection through an official OTA update is especially significant. It means the update channel, normally a control that fixes problems, can itself become the delivery mechanism.

## Why this matters beyond ad fraud

Ad fraud is the visible business model, but a remotely updatable system-level loader is a general-purpose access platform. The operator can push any payload at any time.

| Risk | Who is affected | Why it matters |
| --- | --- | --- |
| Arbitrary code execution with system privileges | Device owners, organisations | The loader can install spyware, credential stealers or banking trojans without consent |
| Network pivoting via the proxy | Corporate and home networks | Relayed connections can reach hosts on the Wi-Fi or VPN the phone joins |
| Attribution and legal exposure | Device owners | Malicious traffic exits from the owner's IP address |
| IP reputation damage | Organisations, carriers | Shared egress IPs can be blocklisted, disrupting legitimate services |
| BYOD and compliance gaps | Regulated organisations | An untrusted OS undermines controls assumed under PCI DSS, SOC 2 and ISO 27001 |

The network-pivot risk deserves particular attention. A phone on a corporate guest or staff Wi-Fi segment becomes an internal relay controlled from outside. If it holds an always-on VPN profile, the exposure extends into the corporate network.

For compliance, the issue is assurance rather than a specific control failure. Mobile access to cardholder data environments or customer data assumes a trustworthy endpoint. A device whose firmware is untrusted cannot meet that assumption, regardless of the MDM policies applied on top.

## How to spot an infected device

The most reliable check is a package inventory over Android Debug Bridge (ADB). Enable Developer options and USB debugging, connect the phone, and run the following from a trusted workstation.

```bash
# Look for package names reported in this campaign
adb shell pm list packages -f | grep -E \
  'com\.android\.system\.lite|com\.android\.sys\.prot|com\.android\.sys\.gmsprot|com\.android\.non\.szcz|com\.mobile\.applock\.en'

# List system packages with their installer, to review unfamiliar entries
adb shell pm list packages -s -i

# Inspect a suspicious package: code path, flags and recorded installer
adb shell dumpsys package com.android.system.lite | grep -E 'codePath|pkgFlags|installerPackageName'
```

Behavioural signs also help when package names change between variants:

- Apps that reappear after removal or after a factory reset.
- Unfamiliar utility apps (weather, app lock, OCR) the user never installed.
- Ads appearing on the home screen or while the phone is idle.
- Unexplained battery drain and background data use, especially overnight.
- On the network side, persistent outbound TCP sessions from a phone to unfamiliar hosts, or the phone accepting relay instructions and opening many onward connections.

Package names are only a starting point. Treat the list above as indicators for this campaign, and expect renamed variants.

## What to do about it

### For individual users

- Buy devices that are Play Protect certified and listed under Google's Android Enterprise Recommended programme, from vendors with a published security-update policy.
- Check for a vendor firmware update that addresses the issue, and install it only from the manufacturer's official channel.
- As an interim containment step, disable the malicious package for the current user. A system app cannot be fully removed this way, and the loader may restore it, so this is not a cure:

```bash
adb shell pm disable-user --user 0 com.android.system.lite
adb shell pm uninstall -k --user 0 com.mobile.applock.en
```

- If no clean firmware exists, retire the device. Do not use it for banking, work accounts or two-factor authentication in the meantime.

### For security teams

- **Device admission.** Enforce Play Integrity verdicts (MEETS\_DEVICE\_INTEGRITY at minimum; MEETS\_STRONG\_INTEGRITY for sensitive access) in MDM or conditional access. Maintain an allowlist of approved manufacturers and models for corporate and BYOD enrolment.
- **Inventory and hunting.** Use MDM app inventory to search the fleet for the package names above. Alert on system apps that are not present in the vendor's stock image for that model.
- **Network segmentation.** Place personal and unmanaged mobile devices on isolated segments with client isolation. Never allow them to reach internal services directly.
- **Egress monitoring.** Flag mobile endpoints with long-lived outbound TCP sessions, high fan-out to many destinations, or traffic volumes inconsistent with interactive use.
- **Zero Trust access.** Grant access per application based on device posture, rather than giving network-level VPN access to any enrolled phone.

### For procurement and governance

- Add firmware provenance to hardware vendor assessments: who builds the image, who holds the platform signing keys, and how OTA updates are signed and distributed.
- Require contractual commitments on update cadence, vulnerability disclosure and notification of supply-chain incidents.
- Record pre-installed firmware compromise as an explicit scenario in the third-party risk register, with BYOD policy and mobile standards updated to match.
- Before deploying a new device model at scale, sample units and compare their package list against a known-good baseline.

## My Summary

A cheap phone can carry an expensive risk. Midnight Mimosa shows that the device's trust anchor can be compromised before purchase, and that even official updates are not automatically safe.

For most organisations, the practical response is not new technology but discipline: approved device lists, attestation-based access, segmented networks, and supplier assessments that ask about firmware as seriously as they ask about data handling. Endpoint security now starts at the factory.

## Sources

- [Low-cost Android phones ship with residential proxy malware](<https://www.bleepingcomputer.com/news/security/low-cost-android-phones-ship-with-residential-proxy-malware/>), BleepingComputer, 8 October 2026
- [Midnight Mimosa malware analysis](<https://www.bitdefender.com/en-us/blog/labs/midnight-mimosa-malware>), Bitdefender Labs
- [XDA Forums user reports on Cubot KINGKONG X](<https://xdaforums.com/t/need-help-identifying-com-android-sys-extplv-google-play-installed-package-on-cubot-kingkong-x.4793574/>)

---

Source: https://www.gowrishankar.me/blog/midnight-mimosa-preinstalled-android-proxy-malware