Midnight Mimosa: Android Phones Arriving With Malware Already in the Firmware

Most mobile security advice assumes the threat arrives after you unbox the phone — a bad app, a phishing link, a sketchy download. The Midnight Mimosa campaign skips that step entirely. Thousands of low-cost Android devices, observed across more than 150 countries, have been found carrying a malicious component baked into their firmware before they ever reached a customer.

What happened

Investigators at Bitdefender tracked thousands of infected devices over roughly two years, and PolySwarm expanded on that work in a research report published on 19 October 2026. The highest infection counts were observed in Mexico, France and Italy, followed by the United States, Germany, Brazil and Spain — numbers that reflect where infections were seen, not evidence of deliberate geographic targeting.

The root of the problem is a privileged system application signed with an Android platform certificate. That signature gives it the same standing as core OS components: it can install and remove packages, grant permissions and change protected settings without the owner doing anything.

The chain works roughly like this:

• Hidden loader. The core logic sits inside a native library that uses RC4 to decrypt a concealed Java framework at runtime.
• Remote plugins. The framework contacts command-and-control infrastructure, pulls configuration, and downloads DEX/JAR modules — letting operators change what the malware does without touching the original system app.
• Ad fraud and silent installs. Observed plugins generate fake ad impressions, clicks and conversions through hidden windows, and quietly install additional apps. The visible apps involved look mundane: weather tools, app lockers, text scanners, file managers. At least 32 disguised applications were identified in the wider payload network.
• Sidestepping Play Protect. Before dropping extra payloads, the component briefly disables the Google Play Store package and then restores it — assessed as an attempt to avoid Play Protect scanning during that window, not proof that protections stay off. Some payloads also falsely list Google Play as their installer, despite lacking the signature block real Play installs carry.
• Proxy capability. One payload can register the device and open two-way TCP tunnels, which could let third-party traffic flow out through the victim's connection. The capability was confirmed, but actual relaying was not observed during testing, and one early control endpoint turned out to be a sinkhole.

The enabler also contains functions tied to Accessibility, Notification Access and SMS permissions, including ways to switch sensitive access on automatically. Researchers did not see these used for data theft — but because the framework can fetch new code at any time, today's ad-fraud modules are not a reliable guide to what it might do tomorrow.

A separate set of 13 ad-fraud apps on Google Play shared markers and infrastructure with the campaign, though without the firmware-level privileges.

Who is affected — and what is still unknown

Affected hardware included inexpensive MediaTek-based phones, counterfeit "flagship" models, and devices reporting Doogee and Cubot identifiers. Some firmware certificates referenced Shenzhen Zediel, but researchers could not establish where the malware entered the supply chain or that the certificate holder knowingly took part. Overlaps with the Joker, Phantom and Click malware families likewise do not prove a shared operator. Treat attribution here as open.

Why it matters

This is a supply-chain problem, not a user-behaviour problem. App-store vetting and "only install trusted apps" hygiene cannot help when the malicious code ships as part of the operating system. Uninstalling a suspicious app may simply let the firmware enabler reinstall a replacement. And the proxy capability turns a cheap phone into a potential exit node for someone else's traffic — on a home network or inside a corporate Wi-Fi.

What to do

• Know what is on your network. Inventory the Android devices that touch corporate resources, including BYOD. Flag no-name, counterfeit or unusually cheap models and keep them off sensitive segments.
• Buy from accountable sources. Prefer devices from vendors with a track record of signed, regularly updated firmware, sold through authorised channels.
• Hunt for the indicators. Look for the package com.android.system.lite (firmware enabler), com.mobile.applock.en (proxy-capable payload), the native library libeasy.so, and plugin classes com.wz.sdk.DxFactory, com.earnsdk.lib.DxFactory and com.gogo.third.lib.DxFactory. At the network layer, watch DNS and proxy logs for api.weatherlive[.]world and oss.showtimetool[.]com.
• Watch for proxy behaviour. Unexpected long-lived outbound TCP sessions from mobile devices are worth investigating.
• Remediate at the firmware level. On an infected device, removing apps is not enough. Re-flash with clean vendor firmware where that exists — otherwise, retire the device.
• Use MDM controls. Enforce attestation and minimum patch levels, and alert on devices that report an unexpected installer or system-app changes.

Hidden capabilities buried in third-party and supply-chain components are exactly what our Bug Hunting team goes looking for: hypothesis-driven research across your mobile and supply-chain exposure, with every finding validated by an analyst before it reaches you.

Reported by the 4Tify Team, based on reporting by Cyber Security News and research from Bitdefender and PolySwarm.