The Supply Chain That Shipped the Malware

Abstract

On October 8, 2026, Bitdefender reported Midnight Mimosa, malware found preinstalled on low-cost Android phones across multiple brands, primarily on MediaTek platforms. Over approximately two years, it observed thousands of affected devices in more than 150 countries and territories. The principal component did not need to exploit a privilege-escalation vulnerability after installation: it was already a privileged system application capable of retrieving executable modules and silently installing other applications after the customer had bought the device.

The unresolved question is where the malicious code became trusted firmware. The brands, signing certificates, and malware packages vary; none identifies the company or production step that first introduced the code.

That gap has a history. Specialized firms made inexpensive Android phones possible by sharing designs and dividing chipset integration, firmware development, signing, updates, and sales among different parties. Earlier documented incidents show how legitimate handoffs in that process carried unwanted or malicious code. They establish possible failure points, not Midnight Mimosa’s missing insertion point.

Bitdefender also found advertising fraud and proxy-capable software in the campaign. The proxy component contained domains independently associated with IPIDEA, a residential proxy network used by many threat groups according to Google. Neither investigation established that the affected phones actually relayed IPIDEA customer traffic.

The case’s central failure mode is therefore more precise than a suspected factory compromise: authority granted to software in a product build could later be exercised by whoever controlled its remote modules. This article follows how that authority became possible, what Midnight Mimosa did with it, and which links remain unproved.

1. Incident Overview — Malware in Trusted Device Software

Bitdefender’s investigation began with suspicious behavior originating from an Android package named com.android.system.lite.

The application presented itself as a system component, had no launcher icon, and was installed as part of the device firmware. Its manifest specified the system shared UID, and the application was signed with a platform certificate. It also requested powerful permissions, including INSTALL_PACKAGES, DELETE_PACKAGES, and GRANT_RUNTIME_PERMISSIONS. Bitdefender observed the malware exercising package-management capabilities that ordinary applications would not possess.

The main application was not a self-contained advertising fraud program. Its native library, libeasy.so, concealed an encrypted executable payload that was decrypted at runtime. The resulting framework retrieved additional modules and configuration from remote infrastructure, allowing the operators to change which software ran on an infected device without rebuilding its firmware.

As the investigation expanded, Bitdefender identified related components under names including com.android.sys.prot, com.android.sys.gmsprot, and com.android.sys.bcprot. Their names and signing certificates differed, but they shared distinctive elements of the loader, encrypted framework, and control infrastructure.

The malware could install applications masquerading as weather utilities, app lockers, note-taking tools, OCR software, and audio editors. Some used legitimate advertising SDKs while background modules generated impressions and interactions unrelated to genuine user activity. Other components implemented functionality for registering a device with a proxy service and relaying TCP connections.

The affected devices were not confined to one manufacturer. Bitdefender’s telemetry included the Doogee S200 X and Cubot KINGKONG X, alongside devices using counterfeit flagship names or internal MediaTek board identifiers. Mexico, France, Italy, the United States, Germany, Brazil, and Spain were among the countries with the most detections. The international spread does not identify the distributors or retailers that handled particular phones.

Related code appeared under different package names and signing certificates. That distribution could reflect a common firmware integrator, a reusable third-party package, or independent manufacturers adopting similar code. The available evidence does not identify which explanation applies or establish one compromised manufacturing line.

The established fact is that malicious code reached devices with privileges reserved for trusted system software. The next question is how it acquired that authority.

Source: Bitdefender, The phone was compromised before the user turned it on: the rise of Midnight Mimosa, October 8, 2026

2. Attack Timeline — Integration, Operation, and Discovery

The precise date when Midnight Mimosa first entered a production firmware image is unknown. Available records instead establish several overlapping timelines: the development and release of affected device families, the evolution of the malware, remote infrastructure activity, user reports, and subsequent remediation.

Period	Documented event	Significance
2021	Dr.Web later identifies zhuifengzhe.top in Android.Joker.310.origin	Earlier use of a domain subsequently linked to a related click-fraud chain, not a Midnight Mimosa infection date
2024	Early firmware versions for the Doogee S200 series and Cubot KINGKONG X appear in regulatory certification records	Establishes product and firmware baselines, not infection dates
September–October 2025	Dr.Web traces Android.Phantom.5 and its click-fraud payload through domains later identified in Midnight Mimosa	Shared infrastructure history; neither source identifies the firmware integrator
December 2, 2025	Cubot publishes KINGKONG X firmware V28	Provides a potential comparison image
January 29, 2026	Google reports its disruption of IPIDEA	Disruption of infrastructure associated with the proxy component
July 2–8, 2026	Cubot KINGKONG X owners report com.android.sys.extplv; one names the older V28 build	Public reports show symptoms on more than one build, not when a loader entered firmware
July 7, 2026	Cubot publishes KINGKONG X V34 with a release note stating “Eliminate the virus”	Manufacturer acknowledgment of a malware-removal update
July 19–August 6, 2026	A Doogee Fire 3 Max owner reports recurrence after an OTA update and later reports removal after another update	The owner names a package in Bitdefender’s corpus; OTA provenance remains unverified
October 8, 2026	Bitdefender publishes the Midnight Mimosa investigation	Detailed analysis of the privileged loader and its modules
October 9, 2026	Bitdefender corrects its identification of a proxy endpoint	The observed endpoint was a sinkhole, not an active command-and-control server

The loader contained an internal string resembling a build date, 20240425, while module distribution paths included date-like identifiers from late 2025 and several points in 2026. These are useful indicators for reconstructing software versions, but neither a hardcoded date nor a directory name independently proves when code was compiled or deployed.

The distinction matters because installing the initial loader and activating its malicious functions are separate operations.

A loader embedded in a firmware image in 2025 could begin installing different applications in July 2026 after receiving updated remote instructions. Conversely, a firmware update in 2026 could introduce a component that was absent from the original factory image. Both possibilities can produce similar symptoms on a user’s phone.

The Cubot records offer a potential way to distinguish them.

The KINGKONG X’s 2024 EU type-examination certificate names software version V01; a later FCC test report names V21 for its test unit. Cubot subsequently released V28 in December 2025 and V34 in July 2026. The V34 release notes explicitly included virus removal, and a similar description appeared in updates for the KINGKONG 9. These records are version baselines, not comparisons of affected firmware images.

The first Cubot KINGKONG X post, dated July 2 describes com.android.sys.extplv under /data/app, with Google Play shown as the installer. A July 8 report describes repeated detections on Android 14 build CUBOT_KINGKONG_X_E021C_V28_20250918. Another owner reported that the applications stopped reappearing after installing Cubot’s July 7 update.

In the same thread, a Doogee Fire 3 Max owner reported on July 19 that symptoms appeared after an OTA update and stopped after reinstalling an older firmware while preventing that update. The owner identified the affected update as DOOGEE-Fire 3 Max-EEA-Android15.0-20260616 and reported on August 6 that the later 20260731 update removed the suspect software. The owner’s July 28 post names com.android.non.szcz, which Bitdefender includes in its enabler-family sample list. That package match is stronger evidence of a connection than the shared symptoms alone, but the OTA sequence remains the owner’s account, without an independent comparison of the signed update packages. The Fire 3 Max is also a different model from the S200 X in Bitdefender’s telemetry.

The XDA posts also describe a repeatedly installed com.android.sys.extplv application. Bitdefender does not identify that package in its published sample list; the reported Play installer and /data/app location do not make it the platform-signed enabler. The component responsible for reinstalling it remains unidentified.

These observations are suggestive, but they do not establish a single infection path. User reports have not been independently reconciled with complete binary comparisons of the relevant firmware images.

The distinction between integration and operation also explains why Google’s January disruption of IPIDEA did not necessarily eliminate Midnight Mimosa. Disabling infrastructure used by a proxy module does not remove a privileged loader already embedded in a device. Midnight Mimosa also maintained separate infrastructure for retrieving configuration and executable modules.

The resulting chronology is not a conventional sequence in which an attacker compromises a device on one date and executes a payload immediately afterward. It describes software capabilities introduced through a trusted product environment, potentially exercised much later, and remediated through another firmware release.

Determining when each capability first appeared requires comparing the actual firmware artifacts, not merely their publication dates.

Sources: Cubot, KINGKONG X Firmware Download Center; XDA user discussion, July–August 2026; Dr.Web, Android.Phantom.5; Bitdefender, 2026; Google Threat Intelligence Group, January 2026

3. How the Supply Chain Was Built — Who Actually Makes an Android Phone?

3.1 From Integrated Manufacturers to Shared Designs

The structure of contemporary low-cost smartphone manufacturing emerged from a longer transformation of the Chinese mobile phone industry.

During the 2000s, Shenzhen developed a network of specialized businesses handling chipset integration, circuit-board design, components, software, assembly, wholesale distribution, and retail sales. Companies no longer needed to develop every part of a handset independently or maintain their own manufacturing facilities to enter the market.

MediaTek played an important role in this transition by supplying turnkey chipset solutions and reference designs. Independent design houses could build products using established communications technology and supporting components, while other businesses handled customization, production, branding, and sales.

Research into Shenzhen’s shanzhai handset industry describes the interaction between these technical platforms and markets such as Huaqiangbei, where components, manufacturing services, and commercial relationships could be assembled into new products.

This was an economic and technological innovation, not inherently a security failure. Shared designs reduced development costs, shortened production cycles, and enabled smaller companies to compete in markets previously dominated by vertically integrated manufacturers.

Android introduced further layers of software integration into that industrial model.

A finished smartphone requires more than a chipset and a generic operating system. Its firmware combines Android platform code, a chipset-specific board support package, device drivers, vendor services, hardware configurations, permission rules, and additional applications.

Some of those components originate with the platform vendor; others may come from an ODM, an independent firmware developer, or a third-party software provider.

A commercial brand can specify the product and sell it internationally without having written every system component. Likewise, firms capable of building or modifying firmware may never appear on the finished device’s packaging.

This arrangement creates a crucial distinction between the company responsible for selling a phone and the entities capable of changing its operating system.

A component reused across multiple product builds can propagate far beyond the original development environment. If that component is malicious, its distribution can follow the same legitimate mechanisms that normally make manufacturing efficient.

Sources: Ding and Pan, Platforms, Network Effects and Small Business Dynamics in China, 2011 (abstract mirror); Social Trust and Open Innovation in an Informal Economy, 2020

3.2 How Legitimate Handoffs Became Malware Entry Points

The risk did not appear suddenly with Midnight Mimosa. Earlier investigations document different ways unwanted code crossed from an outside supplier into software delivered as part of an Android phone.

Since at least 2015, BLU Products had instructed its manufacturers to preinstall ADUPS software for firmware-over-the-air updates. In a 2018 complaint, the U.S. Federal Trade Commission said that the service also collected texts, location data, and other information it did not need for the contracted update function. The FTC identified the brand’s selection of the service, its instruction to the manufacturers, and the software’s behavior. This was an authorized installation with authority extending beyond its stated purpose, not evidence of an attacker replacing a build.

In 2017, Google observed a different transition in Triada: from exploiting devices after installation to arriving as a backdoor in the system image. Google’s later reconstruction described an OEM sending an image to a third party for an added feature and receiving a modified image containing Triada. That case located the dangerous handoff in the development process, before the device reached its owner.

Google’s Android Security 2018 Year in Review identified two recurring entry surfaces: preinstalled applications on new devices and malicious software bundled with over-the-air updates. Its build-scanning program prevented 242 submitted builds containing potentially harmful applications from entering the certified ecosystem during 2018. That figure establishes that contaminated builds were a measurable problem; it does not measure all Android manufacturing or identify the cause of each build’s contamination.

Kaspersky’s 2026 Keenadu investigation supplied a further example at the source-code stage. It found a malicious static library in a MediaTek-related firmware tree and valid signatures on affected images. The researchers judged integration during the build more likely than compromise of an update server alone, because server access would not ordinarily provide the production signing keys.

BLU/ADUPS, Triada, and Keenadu involved different software, firms, and mechanisms. Together they show how third-party selection, outsourced image modification, and source dependencies can become trusted product code. They do not form a single historical chain leading to Midnight Mimosa. For that case, the corresponding handoff remains to be found.

Sources: FTC, BLU Products Complaint, September 2018, paragraphs 5–22; Google, PHA Family Highlights: Triada, 2019; Google, Android Security & Privacy 2018 Year in Review, pp. 11–14; Kaspersky, Keenadu, 2026

3.3 The Authority to Integrate, Sign, and Update

The manufacturing process distributes several kinds of authority that are easy to confuse.

A firmware integrator may decide which system applications and configuration files enter a product image. A signing authority can make the resulting application or image acceptable to the device. An update provider may host and deliver new firmware without necessarily having created its contents or holding the signing keys.

These functions can be performed by the same organization, but they do not have to be.

Android’s release process explicitly permits a separation between building a software image and applying production signatures. For example, the AOSP release-signing workflow generates target files and can subsequently replace development keys with production keys using sign_target_files_apks.

This means that a system application can enter an image during integration and receive its production signature at a later stage. A successful signature check does not establish that every preceding contribution was safe.

The difference is particularly important for privileged applications, because merely placing an APK in a firmware image does not automatically grant every permission it requests. Its effective privileges depend on the signing relationship, installation location, applicable permission rules, Android version, and other platform conditions.

Thus, two decisions must be distinguished: who introduced the code, and how the resulting product build made that code eligible to exercise system authority. The BLU, Triada, and Keenadu records locate different earlier decisions of this kind. Midnight Mimosa’s production records do not yet locate either decision.

Source: Android Open Source Project, Sign builds for release

3.4 Mapping the Companies in Midnight Mimosa

For Midnight Mimosa, comparable contractual records have not been established.

The available evidence instead consists of product certifications, company disclosures, firmware histories, and malware signing information.

FCC documents for the Doogee S200 series identify Shenzhen DOOGEE Hengtong Technology as the applicant and manufacturer. That record identifies a responsible company for this certification; it does not identify who integrated or signed the affected firmware.

The Cubot KINGKONG X is associated with Shenzhen Huafurui Technology in its product certification and manufacturer materials. Cubot also publishes firmware releases for the device, providing a documented software version history.

The published specifications for the Doogee S200 X and Cubot KINGKONG X both list the MediaTek Dimensity 7050. Their published hardware identifiers and firmware version schemes, however, differ. A common chipset establishes a shared technology platform, not a common firmware developer or a single compromised manufacturing line.

A separate clue appears in the malware’s signing certificates.

Bitdefender identified one platform certificate containing CN=ZED, O=ZED, and ZED@Zediel.com. Shenzhen Zediel is a company offering Android hardware and software integration services, making the certificate relevant to an investigation of firmware provenance.

But the subject name in a certificate is not proof of who controlled its private key, who requested a signature, or who inserted the malicious code. Bitdefender also encountered related malware using different certificates.

Consequently, the public evidence cannot establish that Zediel built the affected Doogee or Cubot firmware, much less that it knowingly introduced malware.

The contrast with the earlier cases is revealing. Their records locate a handoff into a product build. In Midnight Mimosa, the privileged software can be examined directly, but the manufacturing and contractual chain that produced it remains incomplete.

That gap is the starting point for reconstructing where the malware acquired authority.

Sources: Bitdefender, 2026; Doogee S200 FCC report; Cubot KINGKONG X FCC report; Shenzhen Zediel

4. Where the Malware Became Trusted — Known Privileges, Unknown Integration

The product and certification records identify devices and named companies, while the malware analysis identifies components and execution paths on affected devices. The public sources do not connect those ends through a particular firmware integrator, signing decision, or update artifact. Figure 1 separates that missing handoff from the code path Bitdefender reconstructed.

4.1 The Missing Production Handoff

The historical cases show why a valid signature is compatible with an earlier contaminated build. They do not identify Midnight Mimosa’s insertion point. Here, product records, firmware version names, and malware certificates have not been joined by an authenticated comparison of the affected images or by integration and signing records.

The consequence of that gap is specific. We cannot tell whether the initial loader arrived in a factory image, in a later signed update, or through another authorized integration step. Nor can we assign its insertion to a named brand, integrator, certificate holder, or update provider.

One possibility is that an integrator accepted a malicious application and the normal release process subsequently signed it. Another is that a third-party component entered an already privileged software arrangement. Unauthorized access to signing assets is also technically possible, although no public evidence establishes it here. These paths would leave different traces in firmware versions, APK signatures, permission configurations, and build records.

The operational chain begins at the next boundary: affected devices treated the loader as privileged system software. From that position, the loader could accept code supplied after sale. Establishing who made the original build decision would require matching the affected images and their signatures to the build and approval records for each device version.

4.2 The Critical Boundary: Becoming a Privileged System Application

The decisive technical fact in Midnight Mimosa is not simply that an APK was present in the firmware. It is that the resulting device treated malicious code as privileged system software.

Android distinguishes between application identity, signing relationships, installation location, and permission grants.

A platform-signed application may qualify for permissions associated with the operating system, while membership in the system shared UID and access to privileged permissions are subject to additional platform rules. These requirements vary across Android versions and should not be reduced to a certificate name alone.

Bitdefender identified platform signing and system-UID configuration in the malicious component, and observed privileged package-management operations on affected devices.

This establishes that the relevant capabilities were not merely requested in a manifest. Important parts of the privilege chain were operational. The certificate containing Zediel’s name helps identify an artifact to compare with product keys; it does not locate the insertion step or identify who exercised the signing authority.

What happened after the device granted that authority is considerably clearer.

4.3 From Firmware Privilege to Remote Execution

Bitdefender reconstructed a multi-stage execution chain in which the initial privileged application served as a gateway for additional code.

The first stage loaded libeasy.so, which decrypted an embedded Java payload of approximately 142 KB. This established a framework capable of handling privileged operations and loading further executable modules.

The framework subsequently loaded kwlib.jar, used DexClassLoader, and obtained module configuration from api.weatherlive.world. Additional code was retrieved from infrastructure including oss.showtimetool.com, sometimes disguised as image files.

Among the modules Bitdefender identified were wz, responsible for advertising automation; earn, which supported additional APK installation; and gogo.third, which provided application-management and WebView-related functionality.

This design mattered because externally supplied DEX/JAR code could execute within an existing privileged process and make use of its capabilities. The package-installation modules could then invoke PackageInstaller.Session to install applications without the ordinary user confirmation flow.

Those newly installed applications did not automatically inherit the loader’s system identity; the loader’s privilege enabled their installation, while each application retained its own signing and permission conditions.

Bitdefender also observed logic that temporarily disabled the Google Play Store package during certain installation operations. The observation is consistent with an attempt to interfere with normal installation-related protections, although it does not establish that every Google security mechanism was disabled.

The important boundary was crossed earlier, when the firmware made the loader privileged.

Once that happened, the remote infrastructure could influence software execution on the device without producing a new signed firmware image.

Authority granted in a trusted product build or signed update had become an operational capability available to whoever controlled the subsequent module distribution.

The organizations involved in those two stages did not have to be the same. Their actual relationship, however, remains unknown.

4.4 A Second Distribution Route: Google Play

Bitdefender also found 13 genuine Google Play applications containing related advertising fraud code. Unlike APKs that merely claimed Play as their installer, these were distributed through the store. They carried 13 different signing certificates and were associated with at least two developer accounts, fivedev and CPS Developer. Examples included com.dmstudio.weather, com.dl.guard.lock, and picturetranslate.extractor.text.lite.

The distinction is one of authority. The preinstalled loader could execute privileged code and silently install applications; the Play applications distributed related code without automatically inheriting those system privileges. This shows that related software circulated through more than one channel. It does not identify the original firmware integrator or establish common ownership of every application.

The Play route adds a separate distribution channel without identifying who developed its components. A shared ROM integrator, a third-party software kit adopted by several manufacturers, or misuse of privileged update infrastructure remain competing explanations for the firmware distribution. The Play applications do not distinguish among those firmware scenarios.

5. From Hardware Supply to Proxy Supply — Selling the Device’s Capabilities

5.1 Monetization Without Manufacturing the Phone

The firmware loader and advertising applications performed different roles.

The privileged component could deploy and manage software. The advertising applications used legitimate SDKs to request advertisements. Separate modules automated impressions and interactions that did not reflect genuine user behavior.

This arrangement allowed the party controlling the device to be distinct from the application publisher associated with advertising revenue.

It also meant that the operator did not need to manufacture a smartphone or control a conventional app store to distribute every component. Privileged firmware could supply the installation capability, while ordinary-looking applications handled the advertising transactions.

Bitdefender confirmed fraudulent advertising behavior, but the published evidence does not identify the ultimate payment recipients or establish how much revenue was successfully collected. Advertising networks may also detect and invalidate fraudulent traffic.

There is a limited history of the advertising infrastructure. Dr.Web’s analysis traces zhuifengzhe.top from a 2021 Joker variant to a 2025 Phantom clicker chain; that chain also used cgb.jingongbuxiao.com and a download path under 5.ahd187.com. Bitdefender found the latter two indicators in Midnight Mimosa. This links infrastructure used for remote code and click fraud across reports. It does not prove continuous control by one operator or show when the privileged firmware loader was inserted.

The significant change in Midnight Mimosa is where that distribution capability sat. A company could sell a handset once, while whoever controlled the privileged loader’s remote modules could attempt to extract value from it after purchase.

Residential proxy services provide another, more infrastructure-oriented version of that model.

5.2 IPIDEA and the Market for Residential Connections

Residential proxy services aggregate access to IP addresses associated with consumer and small-business internet connections and make that access available to third parties.

Such services have legitimate applications, but their security implications change when devices are enrolled without meaningful user consent or when the resulting connections are used for malicious activity.

Google’s January 2026 investigation of IPIDEA documented a large ecosystem built around software distribution and the resale of network connectivity.

According to Google, the operation was associated with multiple proxy and VPN brands and SDKs including EarnSDK, PacketSDK, CastarSDK, and HexSDK.

Application developers could incorporate those SDKs into their software, typically receiving compensation linked to app downloads. Installed devices could then contribute network access to a proxy service, while the infrastructure operator managed connectivity and sold access to customers.

Google identified shared infrastructure behind apparently separate brands, including approximately 7,400 Tier Two servers involved in managing proxy connections at the time of its investigation.

The resulting supply chain differed fundamentally from smartphone manufacturing.

The manufacturing business assembled components and software into physical devices for sale. The proxy business aggregated a capability belonging to devices already in circulation: the ability to originate network traffic from a particular internet connection and geographic location.

A proxy provider did not need to own the hardware. It needed software capable of enrolling and controlling enough endpoints.

Source: Google Threat Intelligence Group, No Place Like Home Network: Disrupting the World’s Largest Residential Proxy Network, January 29, 2026

5.3 The Four Domains Connecting Midnight Mimosa to IPIDEA

Bitdefender found a proxy-related Android package, com.mobile.applock.en, containing EnLoaderLib version 1.0.6.

Despite presenting itself as an application-locking utility, the code implemented device registration, command handling, TCP tunneling, and bidirectional traffic forwarding.

Four domains embedded in the component also appeared in Google’s earlier investigation as control infrastructure associated with IPIDEA-related EarnSDK software:

Domain	Correspondence
0aa0cf0637d66c0d.com	Identified in both investigations
aa86a52a98162b7d.com	Identified in both investigations
442fe7151fb1e9b5.com	Identified in both investigations
v46wd6uramzkmeeo.in	Identified in both investigations

The four-domain overlap is a concrete infrastructure connection, but it does not establish the contractual relationship between IPIDEA and the firmware loader’s operators. The installer module named com.earnsdk.lib should not be equated with Google’s EarnSDK merely because their names resemble each other.

Relaying network traffic would require ordinary network access, not the loader’s system privilege. That privilege mattered to how the proxy-capable application could be installed and managed without the owner’s ordinary approval.

The researchers initially interpreted a proxy registration endpoint as an active command-and-control server. In an October 9 correction, they explained that the endpoint was actually a sinkhole. They did not independently confirm third-party traffic being relayed through the analyzed devices, and the associated revenue remains unknown.

The supported finding is that software installed within the Midnight Mimosa ecosystem contained functional proxy code configured for infrastructure independently associated with IPIDEA.

The same device that received privileged code through its firmware could be provisioned with software designed to turn its network connection into a service for an external market.

The consumer purchased the hardware and ordinarily pays for its connectivity. The proxy operator’s potential product was neither the phone nor its operating system, but the use of that connectivity as a network exit.

5.4 Why This Matters for National Security

Google reported that, during one seven-day period in January 2026, more than 550 tracked threat groups used IP addresses it associated with IPIDEA’s residential proxy network. Those observations included activity attributed to groups linked with China, North Korea, Iran, and Russia.

Residential proxies allow traffic to emerge from a network and location different from the operator’s own. They can serve ordinary commercial tasks, but can also conceal the origin of malicious activity. Google described how proxy resale and overlapping networks complicate attribution from any one exit IP.

The observation does not establish that Midnight Mimosa devices were used by the groups Google tracked. The national-security implication is structural: consumer devices can become infrastructure purchased and used by parties with no relationship to their owners or manufacturers. A proxy customer need not know which factory built the device or which integrator originally enabled its enrollment.

This problem intersects with an older concern about the integrity of global technology supply chains. The Trusted Foundry Program, initiated by the U.S. Department of Defense in 2004, addressed semiconductor production. It is an analogy, not evidence about these Android builds: Midnight Mimosa concerns software integration and authority granted after hardware design.

Here the case-specific question is whether an affected build can be traced through installation and enrollment to actual proxy traffic. The four domains establish an infrastructure overlap with IPIDEA, while Google’s observations establish that many threat groups used IPIDEA exits. Until a device-level link is shown, neither finding establishes national-security use of a Midnight Mimosa phone.

Sources: Google GTIG, IPIDEA Investigation, 2026; U.S. Government Accountability Office, Trusted Defense Microelectronics, 2015

6. Conclusion — Where Did the Malware Become Trusted?

Midnight Mimosa leaves one critical part of its history unresolved: the point at which malicious code became an authorized component of the devices’ operating systems. Bitdefender established what the code could do after receiving privileged status. It could retrieve executable modules, install applications without ordinary user approval, manipulate advertising activity, and deploy software designed to enroll devices in a proxy network.

What remains unknown is which company, software artifact, or approval process first made those capabilities part of trusted firmware. The consumer brand, chipset vendor, and subject name in an application certificate describe different relationships to the finished device; none supplies the missing integration record.

The history of Android manufacturing explains why these relationships have become separated. Shared technical platforms and specialized firms made inexpensive smartphones practical at global scale, while integration, signing, and updates distributed authority across organizations. BLU/ADUPS showed how a selected third-party service could receive more effective access than its contracted purpose required. Triada and Keenadu showed how system-image construction could itself carry malicious code. These are documented precedents, not a reconstructed Midnight Mimosa supply chain.

Midnight Mimosa adds an important downstream consequence. The privileged component did not merely preserve one malicious function inside a finished product. It enabled subsequent code distribution, allowing software operators to change what the device did after purchase without issuing another firmware image. Related advertising fraud code also appeared in Google Play. Older indicators documented by Dr.Web connect some advertising infrastructure across campaigns, but do not identify the original firmware integrator or prove continuous control by one operator.

The proxy component’s domain overlap with IPIDEA raises a further possibility: using a customer’s phone and network connection as a service for others. The available evidence does not establish who profited from that function or whether affected phones carried IPIDEA customers’ traffic. The integrator, signing authority, module operator, app publisher, and proxy customer may have been different parties; their exact relationships remain unknown.

The technical chain from trusted system software to remotely delivered applications is sufficiently documented to establish the central failure mode.

A manufacturing process can create software authority that survives the sale of a product, while the practical ability to exercise that authority passes to operators outside the manufacturer’s visible business relationship with the customer.

In a global supply chain, the security of the finished device depends on more than whether it was built, signed, and distributed through authorized channels. It also depends on what those channels authorized, how that authority can be extended after delivery, and whether the organizations responsible for each stage can account for the code that ultimately runs.

To establish where Midnight Mimosa’s authority began, researchers would need the affected firmware images and updates, their signatures and permission configurations, and the integration records behind them. Until then, the product reveals the after-sale execution path but not the production decision that made it trusted.

---

References

Incident Investigation

1. Bitdefender. The phone was compromised before the user turned it on: the rise of Midnight Mimosa. October 8, 2026; updated October 9.
2. BleepingComputer. Low-cost Android phones ship with residential proxy malware. October 2026.
3. Cubot. KINGKONG X Firmware Download Center. V28 and V34 release records.
4. XDA Forums. Need help identifying com.android.sys.extplv. Owner reports, July–August 2026.

Manufacturing and Industrial History

5. Ding, K., and Pan, J. Platforms, Network Effects and Small Business Dynamics in China: The Shanzhai Cell Phone Industry. IDE Discussion Paper No. 302, 2011. Abstract mirror.
6. Social Trust and Open Innovation in an Informal Economy: The Emergence of Shenzhen Mobile Phone Industry. Sustainability, 2020.
7. Federal Trade Commission. In the Matter of BLU Products, Inc. — Complaint. Docket C-4657, September 2018.
8. FCC. Doogee S200 Series RF Test Report. 2024.
9. PHOENIX TESTLAB. Cubot KINGKONG X EU-Type Examination Certificate (readable mirror). June 2024 (V01); FCC. Cubot KINGKONG X Test Report. October 2024 (V21).
10. Doogee. S200 X product specifications.
11. Cubot. KINGKONG X product specifications.
12. Shenzhen Zediel. Company Profile.

Android Security and Supply-Chain Compromise

13. Google. Android Security & Privacy 2018 Year in Review. 2019.
14. Google Security Blog. PHA Family Highlights: Triada. June 2019.
15. Kaspersky Securelist. Keenadu. February 2026.
16. Dr.Web. Android.Phantom.5. Virus database, description added January 2026.
17. Android Open Source Project. Sign builds for release.
18. Android Open Source Project. Privileged permission allowlist.
19. Android Open Source Project. Platform-signed shared UID allowlist.
20. Android Open Source Project. Verified Boot.

Proxy Infrastructure and National Security

21. Google Threat Intelligence Group. No Place Like Home Network: Disrupting the World’s Largest Residential Proxy Network. January 29, 2026.
22. HUMAN Security. Satori Threat Intelligence Disruption: BADBOX 2.0. March 2025.
23. U.S. Department of Defense. DOD Adopts Zero Trust Approach to Buying Microelectronics. May 19, 2020.
24. U.S. Government Accountability Office. Trusted Defense Microelectronics: Future Access and Capabilities Are Uncertain. October 2015.
25. U.S. Government Accountability Office. DOD Needs to Fully Implement Foundational Practices to Manage Supply Chain Risks. May 2023.