Midnight Mimosa: Malware Preinstalled in Android Firmware for Ad Fraud and Residential Proxying

1. Basic Information

• Article Title: The phone was compromised before the user turned it on: the rise of Midnight Mimosa
• Publisher: Bitdefender Labs
• Publication Date: 2026-10-08
• Original: Bitdefender Labs
• Related Source: BleepingComputer
• Related Malware and Threat Groups: Midnight Mimosa
• Related CVE: None specified
• Related Products: MediaTek Android devices, Google Play
• Severity: Critical

2. Executive Summary

Midnight Mimosa is embedded in the firmware of low-cost MediaTek Android devices as a platform-signed system app, enabling unauthorized payload installation, privilege grants, ad fraud, and residential proxying.

3. Attack Flow

From Firmware to Ad Fraud and Proxying

1. A malicious enabler is integrated into the device firmware as a platform-signed system app.
2. After the initial boot, a native library decrypts and loads an embedded framework, which retrieves remote configuration from a C2 server disguised as a weather API and downloads additional modules.
3. The Google Play Store is temporarily disabled to silently install a disguised payload app and grant dangerous permissions.
4. A cover app performs ad fraud, or a no-icon app registers the device for a residential proxy service.
5. Payloads are rotated frequently, updating hashes and visual artifacts.

4. Attacker Positioning and Execution Locations

• The threat actors utilize a system app embedded in the factory firmware alongside a remote C2 server. The specific injection phase and involved entities remain unconfirmed.

5. Visibility for Victims and Administrators

• Users: The firmware-resident enabler masquerades as a system component, has no launcher icon, and cannot be uninstalled through standard methods. Payload apps may resemble weather or AppLock apps; some also hide their launcher icons.
• Administrators: Indicators include unauthorized permission modifications by system apps, disabled Google Play Stores, silent package installations, and anomalous ad or proxy traffic.

6. Conditions for Success and Failure

Conditions for Success

• Devices preloaded with the malicious firmware are distributed and powered on.
• The system app successfully communicates with the C2 server and module CDN.

Conditions for Failure and Countermeasures

• Apply firmware updates if the vendor provides a clean version confirming malware removal; otherwise, replace the device. Secure Boot and attestation serve as auxiliary integrity checks and do not guarantee the absence of malware within a trusted signed image.
• Use mobile device management (MDM) and network controls to block unknown system apps and C2 communications, and replace affected devices.

7. Impact of Successful Exploitation

• Hidden ad and click fraud.
• Conversion into a residential proxy node and third-party traffic relay.
• Arbitrary code and app deployment capabilities via system privileges.
• Potential abuse of accessibility, notification, and SMS access.

8. Observable Logs

The following items are candidates for internal investigation and do not necessarily indicate all events observed in this specific incident.

• Email: No email-based initial access vector is reported. The enabler is already present in the device firmware before purchase.
• Proxy / SWG / DNS: Check for api.weatherlive[.]world, oss.showtimetool[.]com, wildcard control domains, and TCP/6000.
• Endpoint / EDR: Look for com.android.system.lite variants, libeasy.so, silent package installations, disabled Google Play Stores, and self-granted permissions.
• Identity / IdP: Check for logins from unusual locations, token and credential utilization, permission changes, and service account manipulations.
• SaaS / Cloud: Monitor management APIs, audit logs, repository and cloud resource access, and large-scale downloads.
• Network: Verify weather-disguised C2 traffic, module CDN connections, proxy enrollments, and continuous ad traffic.

9. Determining Successful Attacks

Findings Confirmed in Public Intelligence

• Bitdefender confirmed payload app installations by the enabler via real-device telemetry and verified ad-fraud and proxy capabilities through sample analysis.
• Dynamic proxy testing confirmed C2 connection and node registration, but because no relay targets were returned to the fresh node, traffic relay was not observed during that test.

Internal Criteria for Determination

• Confirm Malware Execution or Authentication Success: Verify enabler activity and unauthorized permission grants within your environment.
• Confirm Subsequent Compromise: Evaluate payload execution, proxy registration, and third-party traffic relay independently. Do not infer successful relay based solely on proxy functionality or registration traffic.
• Correlate requests, processes, authentication events, data access, and outbound transmissions to distinguish between attack attempts and successes.
• Do not conclude that an attack succeeded based solely on HTTP status codes or isolated alerts not supported by public intelligence.

10. Investigation Playbook

• Starting Point: Begin investigations using unauthorized system apps, temporary disabling of the Google Play Store, silent installations, and known C2 communications.
• Initial Verification: Confirm target products, versions, configurations, external reachability, exposure windows, and update or containment timestamps.
• Device and Server Investigation: Inspect firmware builds, platform certificates, system partitions, package histories, and accessibility or notification settings.
• Authentication and Cloud Investigation: Trace suspicious accounts, tokens, API usage, permission modifications, unusual connection sources, and resource access.
• Subsequent Operations: Track post-initial events such as credential access, lateral movement, additional downloads, outbound transmissions, and account creations.
• Containment: Isolate the device from the network and rotate associated credentials. If the device cannot be reflashed with clean firmware that confirms malware removal, replace the hardware.
• Classification Categories: Differentiate between reconnaissance/attack attempts, initial execution, authentication success, data theft, and subsequent compromise.

11. Defense and Detection Ideas

• Single Events: Detect package installations originating from platform-signed apps, disabling of the Google Play Store, and traffic on TCP/6000.
• Sequential Correlation: Correlate C2 configuration fetches, Google Play Store disabling, payload installations, permission grants, and ad/proxy traffic.
• Threat Hunting: Search for listed packages, libraries, domains, certificates, and model strings across MDM, DNS, and mobile telemetry.
• Log Limitations: User-space antivirus solutions and factory resets may fail to remove or detect enablers located within the system partition.
• Prioritized Countermeasures: Prioritize trusted procurement, firmware attestation, MDM controls, egress filtering, and device replacement.

12. Facts, Inferences, and Hypotheses

Facts

• The root of the infection chain is a platform-signed, persistent system app preinstalled in the device firmware, which cannot be uninstalled via standard methods.
• The enabler decrypts and loads an embedded framework from libeasy.so, fetches remote configurations and stage-2/stage-3 DEX payloads, and silently installs or removes at least 32 distinct disguised apps.
• The enabler holds system privileges such as INSTALL_PACKAGES and GRANT_RUNTIME_PERMISSIONS, and can self-grant Accessibility, Notification Access, and SMS permissions, though abuse of Accessibility, Notification Access, and SMS access was not observed.
• Payload analysis identified hidden ad/click fraud and TCP back-connect proxy capabilities. Dynamic testing confirmed C2 connection and node registration, but no relay targets were returned to the newly registered node, and no traffic relay was observed during that test.
• Bitdefender observed the activity for approximately two years across thousands of devices in over 150 countries and identified 13 Google Play apps utilizing the same ad-fraud code and infrastructure.
• Certificates under the name Shenzhen Zediel serve as a technical clue, but do not provide proof that the company created, distributed, or was aware of the malware.

Inferences

• Because MDM installed-app inventories alone may miss enablers residing within the system partition, administrators must verify firmware provenance, platform certificates, and system app behaviors.
• A factory reset may leave the firmware-resident enabler intact. Remediation therefore requires firmware verified to be free of the malware or device replacement.

Hypotheses

No additional hypotheses. Unconfirmed items are noted in section 14.

13. MITRE ATT&CK Mappings

ID	Technique	Confidence	Basis
T1474.002	Supply Chain Compromise: Compromise Hardware Supply Chain	medium	Mapped to the integration of malicious system apps into factory firmware. The injection phase and actor remain unconfirmed.
T1407	Download New Code at Runtime	high	Based on the capability to download and execute additional DEX files and plugins according to remote configurations.

14. Unknowns and Additional Investigations

• The exact supply chain stage at which the malware was introduced into the firmware.
• The full set of affected brands, models, firmware builds, and unit counts per distribution channel.
• The extent to which accessibility, notification, SMS, and DDoS capabilities were utilized in operational environments.

15. Impact on SOCs and Organizations

Organizations deploying low-cost Android or white-label devices for business use should account for the possibility that devices may be compromised at the time of purchase. Inspect firmware, platform certificates, system apps, and egress traffic prior to MDM enrollment, and isolate or replace affected devices before entering any credentials.

16. Target-Specific Summaries

• For SOCs: Monitor for system apps self-granting permissions, disabled Google Play Stores, silent installations, weather-disguised C2 traffic, and TCP/6000.
• For Administrators: Isolate unauthorized devices, perform firmware updates or device replacements, enforce MDM allowlists, and execute credential rotations.
• For Users: Avoid counterfeit devices marketed as premium models and report unremovable system apps or disabled Google Play Stores to administrators.