Mobile
Midnight Mimosa: proxy malware in cheap Android firmware
Bitdefender found ad fraud and proxy malware preinstalled on low-cost MediaTek Android phones in 150+ countries. How it works and how to check a fleet.
Bitdefender published research on October 8 into Midnight Mimosa, malware that sits in the firmware of low-cost Android phones built on MediaTek chips. It is a system app signed with the phone's platform key, so it is already installed when the buyer first turns the phone on, and a factory reset does not remove it. Bitdefender counts thousands of devices in more than 150 countries over about two years, with Mexico, France, Italy and the United States among the most affected.
The implant installs apps silently, grants them permissions and loads code from its operators. The payloads it was seen dropping do ad fraud and enrol the phone as a residential proxy node, a relay that lets paying customers send their traffic out through your IP address. Affected models include the Doogee S200 X, the Cubot KINGKONG X and counterfeit phones sold under names such as "S25 Ultra" and "i17 Pro Max". Any company that lets staff bring their own Android phone, or buys cheap handsets for warehouse, delivery or kiosk work, should check what it has.
How it works
Android phones carry a platform key, the signing key the manufacturer uses for the operating system's own components. An app signed with that key and declared as part of the system user runs with the same trust as the OS. Midnight Mimosa's core is one such app, com.android.system.lite, labelled "System". Bitdefender also found it under com.android.sys.prot, com.android.sys.gmsprot and com.android.sys.bcprot, names chosen to look like parts of Android or Google services. It holds INSTALL_PACKAGES, DELETE_PACKAGES and GRANT_RUNTIME_PERMISSIONS, and because it lives on the read-only system partition, the Settings app cannot uninstall it.
A native library, libeasy.so, decrypts a framework hidden inside the app and contacts api.weatherlive.world, a command server dressed up as a weather API. The server tells the implant which plugins to fetch from oss.showtimetool.com, which serves them as files with a .png extension. Plugins handle in-app ad fraud and the silent installation or removal of partner apps.
Before each install, the implant runs pm disable com.android.vending, which switches off the Google Play Store app, and turns it back on once the install finishes. Bitdefender assesses that this keeps Google Play Protect from checking the new app. Some samples also mark the dropped app as installed by Google Play. A genuine Play install carries Google's "frosting" signature block in the APK; these apps do not, which is how the spoofed source can be spotted.
The proxy payload is com.mobile.applock.en, an app with no launcher icon built on a library that calls itself EnLoaderLib v1.0.6. It registers the phone with a control server over raw TCP on port 6000 and waits for a list of host and port pairs to relay traffic to. A phone doing this on office Wi-Fi is a relay sitting inside your network, run by someone else.
What attackers are doing
Everything Bitdefender observed was about making money, with no sign of data theft. Cover apps that look like weather, app lock, note and OCR tools load real ads and fake the clicks in the background. The companion com.mobile.applock.wt adds ad fraud and remote code loading. The implant switches Accessibility and Notification Access on and off for itself, but Bitdefender did not see it use either.
The proxy side was live. Bitdefender's test device registered with the control server, which accepted it, but no relay targets came back, so the researchers could not confirm traffic being forwarded through infected phones. The same ad fraud code also turned up in 13 apps on Google Play, so the operators are not limited to phones they reached through firmware.
The firmware's platform certificate is associated with Shenzhen Zediel Co., Ltd. Bitdefender says this does not prove the company inserted or knowingly distributed the malware, and the point where it entered the supply chain is unknown.
What to do
Find candidate devices. In your mobile device management (MDM) inventory, filter Android devices by manufacturer and model for Doogee, Cubot, unknown brands, and any device reporting a Samsung or Apple style model name ("S24 Ultra", "S25 Ultra", "S26 Ultra", "i17 Pro Max") while its manufacturer field is not Samsung. A real iPhone never reports as Android, so any Android device calling itself an "i17 Pro Max" is counterfeit. Then search the installed app inventory for any package starting com.android.sys., plus com.android.system.lite and com.mobile.applock.
Check a suspect phone by hand. With USB debugging on, adb shell pm list packages -s | grep -E "system.lite|android.sys\." lists matching system packages. adb shell pm list packages -i | grep applock shows any app lock packages and the installer each one claims. A hidden app lock package that reports installer=com.android.vending on a phone you never installed it on is a strong sign.
Watch the network. Block and alert on api.weatherlive.world and oss.showtimetool.com at your DNS resolver and web proxy. Outbound TCP 6000 from a phone has no business reason on most corporate Wi-Fi, so deny it at the firewall for the mobile and guest segments and treat any hit as a lead. Put BYOD phones on a segment that cannot reach internal servers, which also limits what a relay could reach.
Contain what you find. Uninstalling and factory resetting do not work. The fix has to happen at the firmware level, or the component has to be disabled. For a company device, adb shell pm disable-user --user 0 com.android.system.lite (with whichever variant name you found) stops it for that user, then remove the dropped app lock and cover apps. Treat that as a stopgap: the code is still on the system partition, and a factory reset turns it back on. Reflash only with an image the vendor confirms is clean, or retire the device.
Fix procurement. Buy fleet phones from Android Enterprise Recommended models, which are checked against Google's requirements for security updates and management. For BYOD, set a minimum device policy in MDM that blocks enrolment of unknown manufacturers, and tell staff that a heavily discounted "flagship" from a marketplace is exactly the kind of counterfeit Bitdefender found infected. Verified Boot and attestation checks only prove the firmware is the one the vendor signed, and here the implant is part of the signed image.
If you want to know whether your Android estate includes affected models, or want a test of how your MDM and network controls would handle a compromised handset, our mobile penetration testing and security operations teams can help. Open the chat and Yaali, our AI agent, will pass your question to an engineer.
Sources: Bitdefender Labs, BleepingComputer, Hackread, Android Authority, Android Headlines.