When Malware Comes with the Phone

Most people associate mobile malware with downloading a suspicious application, clicking a malicious link, or installing software from an untrusted website.

Midnight Mimosa presents a different problem: the malware may already be present when a customer first switches on their smartphone.

The campaign, investigated by Bitdefender, involves low-cost Android devices whose firmware contains malicious components with elevated system privileges. These components can install additional applications, grant sensitive permissions, and execute remotely downloaded code without requiring the user to approve each action.

The concern extends beyond a single malicious application. Because the malware is embedded in the device's firmware, it can behave like part of the operating system and resist ordinary removal methods.

The campaign also demonstrates how an infected smartphone can become a resource for criminal operations, generating fraudulent advertising activity or potentially relaying network traffic through the owner's internet connection.

How the Campaign Was Discovered

Bitdefender researchers identified Midnight Mimosa after their App Anomaly Detection technology flagged a suspicious system application named com.android.system.lite.

The application was silently installing and removing other applications, prompting researchers to investigate its behaviour.

Further analysis revealed that it was part of a broader malware framework capable of downloading additional modules from command-and-control (C2) servers. Different modules supported different activities, including advertising fraud and residential proxy functionality.

According to Bitdefender, the campaign affected thousands of devices across more than 150 countries over approximately two years.

The countries with the highest reported victim counts included:

• Mexico

• France

• Italy

• United States

• Germany

• Brazil

• Spain

These figures describe the geographic distribution reported by the researchers; they do not establish that every device in those countries, or every phone sold under the affected brands, is infected.

The Supply-Chain Problem

The malware was found on devices using MediaTek chipsets, with model names associated with legitimate manufacturers such as the Doogee S200 X and Cubot KINGKONG X. Researchers also identified phones impersonating Samsung and Apple products.

The exact point at which the malicious firmware was introduced remains unclear. The available report does not establish who modified the firmware or whether the tampering occurred during manufacturing, distribution, or another stage of the supply chain.

This uncertainty is important. Finding malware in firmware does not, by itself, prove that a device manufacturer deliberately included it.

Reports from users on the XDA Developers forums added further evidence of the problem. Some Cubot and Doogee owners reported suspicious applications that repeatedly reappeared after removal.

One Doogee Fire 3 Max owner reported that an official firmware update introduced the malware. Restoring an older firmware version removed it, but installing the update again caused the infection to return.

Some users later reported receiving firmware updates that resolved their infections. However, the manufacturers had not publicly explained how the malicious software entered the affected firmware, according to the supplied report.

For investigators, the pattern highlights why firmware provenance and update integrity are critical parts of mobile-device security.

Why the Malware Is Difficult to Remove

Midnight Mimosa differs from a typical malicious Android application because its components are installed directly into the device's system partition.

The malware impersonates legitimate Android system packages, using names such as:

• com.android.system.lite

• com.android.sys.prot

• com.android.sys.gmsprot

The names are designed to resemble ordinary system components, making suspicious applications less obvious to users.

Because the components run with elevated system privileges, Android's normal application-uninstall process may not remove them.

This creates a persistence problem: a user may attempt to uninstall a suspicious application, only for the malware to reinstall it or restore the malicious component through its privileged framework.

The malware also reportedly uses multiple modules rather than relying on one application to perform every malicious action. Bitdefender identified approximately 32 applications distributed through the framework, including applications disguised as weather utilities, file managers, app lockers, OCR tools, and audio editors.

Some applications serve as cover for advertising fraud, while other components handle installation, control, or network relay functions.

Inside the Advertising-Fraud Operation

One of Midnight Mimosa's reported objectives is advertising fraud.

The system component does not necessarily generate fraudulent advertising activity directly. Instead, it installs additional applications that look like legitimate utilities and use real advertising software development kits (SDKs).

These applications can load advertisements in hidden windows or interact with advertisements without the phone owner's knowledge.

The result is artificial advertising impressions and clicks that may generate revenue for the operators.

The activity can remain difficult for the user to notice because the advertisements may appear outside the application's normal interface or while the device is not actively being used.

How the malware evades protections

Bitdefender reported that the malware temporarily disables the Google Play Store application, identified by the package name com.android.vending, before silently installing additional applications.

The researchers said this behaviour is intended to prevent Google Play Protect from detecting the installation.

After the installation completes, the malware re-enables the Play Store to avoid attracting attention.

Some variants also manipulate Android's recorded installer information so that malicious applications appear to have been installed through Google Play, even though the malware deployed them directly.

This illustrates why application provenance matters. A package's reported installer is one useful signal, but it should not be treated as conclusive proof that an application was obtained through a trusted distribution process.

Turning Smartphones into Residential Proxies

The second major capability is the use of infected phones as residential proxies.

A residential proxy routes network traffic through an ordinary residential internet connection rather than directly through the attacker's own infrastructure.

This can make traffic appear to originate from the network associated with the infected device. It may also allow an operator to reach systems accessible from that device, depending on the relay configuration and network environment.

Bitdefender identified a malicious application disguised as an app locker:

com.mobile.applock.en

The application contains a TCP proxy component that registers infected devices with a remote command server.

Once a device is registered, the malware can receive instructions to connect to specified hosts and forward network traffic through the phone.

Potential consequences include concealing the original source of malicious activity, abusing the device owner's internet connection, or routing traffic through networks that would not otherwise be associated with the attacker.

However, an important limitation remains: Bitdefender confirmed that the proxy command-and-control infrastructure was operational and accepting device registrations, but researchers said their newly registered test device did not receive any relay targets during testing.

Therefore, the researchers could not confirm whether attackers were actively forwarding traffic through that device during the test. The proxy capability was identified, but active relaying was not demonstrated in that observation.

Additional Applications Found on Google Play

The investigation also identified 13 Android applications distributed through the Google Play Store that contained the same advertising-fraud code and communicated with known Midnight Mimosa infrastructure.

Unlike the firmware-installed components, these applications did not have the elevated privileges required to silently install other software.

They could still display advertisements outside their normal interface, including when users were not actively using the phone.

The applications were distributed using 13 different signing certificates and at least two developer accounts:

• fivedev

• CPS Developer

Bitdefender also identified firmware signed with certificates associated with Chinese device manufacturer Shenzhen Zediel. However, the researchers said it remained unclear whether the company was involved in the campaign.

The presence of a signing certificate associated with a manufacturer is not, on its own, sufficient evidence to establish responsibility for the malware.

SOC Investigation: What Should Analysts Look For?

The following checks are defensive recommendations based on the behaviours described in the supplied report. They are not claims that every infected device will exhibit every indicator.

1. Identify Suspicious System Applications

Review Android package inventories and mobile threat-defense alerts for the reported package names:

• com.android.system.lite

• com.android.sys.prot

• com.android.sys.gmsprot

• com.android.non.szcz

• com.mobile.applock.en

Investigate whether these applications are present in the system partition, have unexpected privileges, or repeatedly reinstall themselves.

Package names can be imitated, and a name match should be validated against package metadata, signing information, installation location, and observed behaviour.

2. Investigate Unexpected Application Installation

Look for suspicious sequences in which an unfamiliar privileged component installs or removes other applications without a corresponding user action.

Where telemetry is available, correlate package installation events with changes to the Google Play Store's enabled state and unexpected modifications to installer information.

3. Examine Network Connections

Review DNS, proxy, firewall, and endpoint network telemetry for connections from suspicious applications to known campaign infrastructure.

Investigate unexplained outbound connections, especially when they coincide with the registration of a device as a proxy or the appearance of a TCP relay component.

The supplied report does not provide a complete list of C2 IP addresses and domains, so additional verified threat intelligence may be needed for infrastructure-based detection.

4. Look for Advertising-Fraud Behaviour

Examine suspicious applications for advertising activity that occurs when the user is not interacting with them.

Potential investigation leads include hidden windows, unexplained ad requests, and repeated advertising interactions that do not correspond to normal user activity.

These behaviours are not conclusive by themselves, as legitimate applications may also use background processes and advertising SDKs.

5. Validate Firmware and Update History

For affected or suspected devices, record the exact model, firmware version, build identifier, and update history.

Compare suspicious behaviour before and after firmware updates. If the malware disappears after restoring an older version but returns after a particular update, preserve that timeline for further analysis.

Use trusted vendor or mobile-forensics guidance to assess the firmware's integrity rather than assuming a factory reset will remove a system-partition infection.

Indicators of Compromise (IOCs) and Technical Indicators

The following indicators were explicitly identified in the supplied report.

Android Package Names

IndicatorReported contextcom.android.system.liteSuspicious privileged system application that triggered the investigationcom.android.sys.protPackage name used to impersonate an Android system componentcom.android.sys.gmsprotPackage name used to impersonate an Android system componentcom.android.non.szczPackage associated by Bitdefender with the same malware familycom.mobile.applock.enApp-locker disguise containing the reported TCP proxy componentcom.android.vendingGoogle Play Store package; reportedly disabled temporarily by the malware

Other Technical Indicators

• MediaTek-based, low-cost Android devices with affected firmware.

• Suspicious applications installed in the system partition.

• Repeated application installation or removal without user interaction.

• Temporary disabling and subsequent re-enabling of Google Play Store.

• Manipulated Android installer metadata.

• Unexpected TCP proxy registration and traffic-relay behaviour.

• Hidden advertising activity outside normal application interfaces.

Reported Developer Accounts

• fivedev

• CPS Developer

These account names were associated with the distribution of the 13 applications identified in the report. They should be treated as contextual indicators, not proof that every application associated with an account is malicious.

Detection caution: A package name, device model, developer account, or MediaTek chipset alone does not establish infection. Correlate these indicators with firmware provenance, package privileges, installation behaviour, and network activity.

The supplied article does not provide specific file hashes or a complete C2 indicator list, so none are fabricated here.

What Should Affected Users Do?

Because Midnight Mimosa may reside in the firmware, ordinary app removal may not be enough.

1. Identify the device and firmware: Record the exact model and build version and check for verified vendor guidance.

2. Install a trusted remediation update: If the manufacturer has released a firmware update specifically addressing the issue, confirm its authenticity and follow the vendor's instructions.

3. Seek expert help if the infection persists: Firmware-level cleanup or disabling the malicious component through Android Debug Bridge (ADB) may be necessary, but these procedures can be complicated and may affect device functionality.

4. Review account security: If the device may have been compromised, change exposed passwords from a clean device and review important account sessions.

5. Avoid unverified firmware downloads: Installing unofficial firmware can introduce additional security risks or render a device unusable.

6. Monitor for recurrence: Check whether suspicious packages return after an update or cleanup.

A factory reset should not be assumed to remove malware embedded in a system partition. Users should follow trusted, model-specific remediation guidance.

Conclusion

Midnight Mimosa demonstrates the risks posed by malicious software embedded in device firmware. Unlike conventional mobile malware that depends on a user installing a suspicious app, this campaign can begin with a compromised device before the customer even starts using it.

The malware combines privileged application installation, advertising fraud, and residential proxy capabilities within a broader framework. Its reported persistence mechanisms also make recovery more complicated than uninstalling an ordinary application.

For defenders, the most important lesson is to look beyond individual apps. Firmware integrity, package privileges, unexpected installation activity, network behaviour, and update history all contribute to understanding whether a device is compromised.

For consumers, the campaign is a reminder that a new phone is not automatically a clean phone. Device provenance, trustworthy firmware updates, and continued monitoring remain important parts of mobile security.