Malware
Midnight Mimosa: who installs apps on your new phone?
Bitdefender's newly published Midnight Mimosa research traces preinstalled Android components that install apps and grant permissions, feeding advertising fraud or residential proxies. The components already hold system trust. Ordinary removal and factory reset can leave them intact, making the firmware's origin central to recovery.
In this article
The owner has installed no untrusted apps, yet a program inside the new phone can install the next batch for them. Bitdefender's Midnight Mimosa investigation, published on October 8 and updated the following day, traces such a distribution chain in a set of low-cost, multibrand Android devices. A malicious component arrives in firmware, and downloaded modules later use its privileges. The activity spans a much longer period than this recent technical disclosure.
Where did the installation prompt go? Android normally prevents an ordinary app from quietly installing another application for its owner. This component already occupies a position to which the system grants that authority. Understanding the missing prompt starts with identifying who the phone trusts to make the installation decision.
1 An app called System already holds installation authority
One component Bitdefender examined is com.android.system.lite, labelled System. The reported manifest and signing information include a platform signature, the shared identity android.uid.system and persistent execution. Its native library releases a hidden framework that loads further modules. The name provides a disguise. Installation location, signature, process identity and granted permissions determine its capabilities.
The platform signature belongs to the device's system-signing arrangement. Android's documentation defines a platform-signed app as sharing the same or a compatible signing certificate with the platform package, android. Platform signing refers to the system on that device. It supplies no assurance that Google reviewed all of the application's behavior.
An ordinary app usually has its own Linux UID. Sharing android.uid.system runs a component under a system identity, changing the branches taken by Android's permission checks. This identity is separate from Linux root and remains subject to applicable system policies. The reported system identity and privileges give it installation and permission-grant capabilities.
Android classifies those permissions explicitly. In pinned Android 13 commit 0d3ff311e6e8, core/res/AndroidManifest.xml, lines 4570–4573, defines INSTALL_PACKAGES as a signature-or-privileged permission. It differs from the permission an ordinary app uses to request an installation. Once the device ships with this authority assigned to a component, the owner's later decision to download only from a store leaves that existing grant in place.
2 The branch that removes the installation prompt
Android 13's reference implementation makes this concrete. For a new installation session that has not received user approval, computeUserActionRequirement() in PackageInstallerSession.java, lines 809–889, checks whether confirmation is explicitly required. If so, it returns a requirement for user action. Otherwise, it examines the installer's permissions and identity. A session already approved manually returns at the start of the function without asking again.
An installer holding INSTALL_PACKAGES, or running under a trusted system or root identity, can reach the branch requiring no user action. System updates, device management and application distribution need such capabilities. A malicious preinstalled component can use the same mechanisms. The subsequent installation flow uses the return value to decide whether to request confirmation, in lines 2073–2114 of the same file. A result requiring no user action lets installation continue without displaying a prompt to the owner.
Permission grants come after installation. A system component can invoke the grant API, giving a newly installed app capabilities beyond an ordinary interactive installation. PermissionManagerServiceImpl.java, lines 1313–1465, first requires GRANT_RUNTIME_PERMISSIONS, then checks the target package, its declared permissions, permission types and restriction flags. Runtime and development permissions, plus eligible role permissions, still have to satisfy those checks before they can be granted.
WRITE_SECURE_SETTINGS allows an application to write protected system settings. Its definition at lines 3751–3754 includes the development flag, which the grant function handles through a dedicated branch. The weather app com.dmstudio.weather in the report uses this permission. Explaining how it can write those settings requires following its installation and the authority granting access. Its icon or store description cannot reveal that history.
3 Payloads rotate while their installer remains
The preinstalled component also buries the installation logic under several loading stages. Bitdefender records libeasy.so decrypting and releasing the cn.kw.lib.hex framework, which reads remote configuration to select later plugins. A plugin passes its bundled assets/mediaapp-release.apk to the installer, deploying an advertising-fraud or residential-proxy program. Examining only the outer APK's Java code misses the parts later decrypted or downloaded. Serving a different plugin version can change the application delivered to the same device.
Rotating applications also supports the revenue scheme. An advertising plugin in the system process schedules impressions, triggers clicks automatically and reports events. Cover apps presenting themselves as weather, note or OCR tools carry legitimate advertising SDKs and ad-unit identifiers, so the advertising network attributes those impressions and clicks to them. The code manipulating interactions stays inside the system, while an ordinary-looking utility receives the advertising revenue. Replacing the plugins and cover apps can keep that revenue path operating.
A residential proxy carries someone else's traffic through the phone's connection, making that phone the source seen by the destination service. This capability is separate from system installation authority. Ordinary network permissions can support a proxy program. Investigators therefore need to distinguish who placed the program on the device from what it does on the network, even when the downloaded program lacks the system UID.
This division of work complicates cleanup. The visible applications can change while their installer remains in the system, able to deliver another program. Removing one downloaded application addresses the layer visible at that moment.
Infrastructure labels also need the latest evidence. The original report describes 85.17.70.38:6000 as a live controller, then adds an erratum identifying it as a sinkhole, a controlled collection point for malware connections. The final indicator table retains the older label. A connection to this address needs its time and sample relationship preserved, with the corrected infrastructure role used in the assessment. Research infrastructure should not be reclassified as an active attack controller.
The installer-source field can likewise mislead. PackageInstallerService.java, lines 642–665, allows a caller with installation privilege to specify another installer name. Bitdefender also records this provenance spoofing. A field containing com.android.vending needs comparison with actual installation events, the caller and package signatures to establish how the APK was distributed.
4 Why factory reset can leave the component intact
Factory reset sounds like a return to a clean phone. It normally erases user data while retaining the currently installed system. A phone that received operating-system updates does not automatically revert to its original purchase-time firmware. If the malicious component remains in the current system image, clearing data leaves it there.
Android 13's reference recovery code shows the distinction. In pinned commit d0ab6ef7da71, WipeData() in install/wipe_data.cpp, lines 81–108, erases /data and, where present, /cache and /metadata. It also calls device hooks before and after the wipe. This common flow does not reinstall /system. Vendors can customize recovery, so treating a particular affected device still requires trustworthy firmware and a cleanup procedure for that model.
Boot verification has a defined job as well. Verified Boot follows a hardware root of trust to authenticate and check the integrity of boot and system partitions. A device can accept an image containing a harmful component when the image has been approved by a signing identity it trusts. Successful verification establishes conformity with that trusted source. The software's behavior still needs examination.
Newer Android versions add restrictions for some platform-signed applications, with a specific scope. Starting in Android 15, the official shared-UID allowlist restricts platform-signed nonsystem apps joining shared identities on nondebuggable production builds. Preinstalled system apps are exempt from that change. The signature-permission allowlist also primarily constrains those nonsystem apps, but newly requested permissions in a system-app update still require allowlisting. Existing preinstalled components and their original permission requests retain their respective rules. A higher operating-system version alone leaves installation location and firmware contents unanswered.
5 Recovery needs trustworthy firmware
For a confirmed preinstalled infection, an ordinary owner needs the vendor or seller to supply verifiable clean firmware and a treatment plan. Bitdefender's October 12 statement also recommends avoiding sensitive accounts on suspect devices, contacting the seller and considering replacement or a refund when conventional removal cannot clear the infection. An arbitrary third-party firmware download simply introduces another unresolved software source.
Organizations can preserve the firmware version, package paths, signing certificates, UID, installation records and network events, distinguishing the preinstalled component from its later payloads. Package names, model strings and company names in certificates provide leads. The report leaves supply-chain responsibility unresolved: a certificate label does not identify the stage at which someone inserted the component into firmware. Investigation has to follow actual devices and images, keeping chip brands, imitated flagship model names and certificate subjects separate from responsibility.
The incident changes a practical assumption about ownership. A person may expect to decide which apps get installed, while the phone already delegated that decision to malicious code before delivery. Cleanup needs to remove that component and stop its continuing ability to install payloads, while retaining the legitimate system installer.